Since I am not a front end developer I have a limited opinion on most things regarding front end. But I do value and respect front end in Drupal. I love the creative side of content presentation. I respect the amount of pixel perfect care that goes into all of it. I'm quite proud that Drupal has taken a very positive and leading role in accessibility out of the box. But in my eyes, the presentation of Drupal content is about design, layout, accessibility and interaction. Where I differ from mainstream is this: the front end should never be tasked with manipulating back end data. If the front end has to take content and change its original form in any way, wouldn't that indicate that the content editor did not have the options necessary to display the content correctly? Or that the back end wasn't advanced enough to manipulate the content based on conditions? The back end should serve as the delivery method to the front end. The power of Views and Twig inside Views is a world of cool to say the least.
The Front End of the Admin Back End
I think there are huge improvements that can be accomplished if the administrative design of the Drupal back end went through a visual face lift and also a dimensional face lift. AKA the "admin theme". I recently read that Drupal is doing just that! I applaud any effort and improvements in this realm. Claro appears to be what the Drupal community has been waiting for. But I also think it's just one small piece. Feel free to keep up on this... I know I surely will be watching this closely. If Claro does succeed in improving the Drupal back end authoring experience, then what about the rest? For some, there isn't anything more, for me, there's a lot more to imagine. What about custom dashboards? Dashboards are almost impossible as a building tool as every site will surely have their own requirements. But I used the word "dimensional" in the first sentence. I'll write more on this as time passes, but my main message here is that a dashboard is not single dimensional. There's many dimensions to what a logged in user should see, might see and should not see. Here's one example: If we have a content editor permission role, wouldn't it be interesting if we had "sub-roles" for that one role? Something like Content Editor/Basic, Content Editor/Advanced and Content Editor/Unlimited.
The Real Front End
No matter how you look at it, the front end of a Drupal site is html and css. Both have come a long way in a short number of years. But css is the one that has evolved the most and in the right direction in my opinion. Our days of complex media queries might soon be a thing of the past. Device specific targeting might be a thing of the past. I can go on and on, but the real message here is that css is evolving to remove specific complexities in favor of simplicty for the masses. CSS is not technically a programming language but as it evolves it appears that its getting far smarter in what it can do. Just the combo of CSS3 and CSS Grid together offer mind blowing options compared to just a few years ago.
My thoughts and opinions all directly relate to how back end Drupal content is laid out, designed and displayed, more directly, how Relativity structured data is displayed. Should a site builder have more direct control on display logic and conditional reactions? In my opinion absolutely yes!
I have worked with many talented front end devs over the years that have adopted Relativity into their own work and how they handle front end Drupal. Where we were able to collaborate and do some very simple and cool stuff is with the concept of components. So what's a component? To be vague, it's small parts of a container that coexist and work together. Together they form a larger single container. But each component can become part of another container at any point. So as a back end dev, if I use the power of Views and Twig inside Views, name spaced fields, preset classes on rows and displays, the back end can serve as a very powerful component based "pre-front-end". This a pretty in-depth concept and one that I will continue to elaborate on over time. My main point with this is: rendered entities and view modes are just one way to grab back end Drupal content. With more power in the back end devs arsenal, we can innovate traditional Drupal theming.