6 ms·

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while t

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users. HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user. A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.

crimsonalucard 7y ago
It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.
- danShumway 7y ago
  95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
  - crimsonalucard 7y ago
    >95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic. >HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target. Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML. This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library. >This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible. while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
    - danShumway 7y ago
      This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that. > It would be better if the web browser world had pixel level render targets We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does. Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them. To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users. In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.
- int_19h 7y ago
  I wonder if perhaps we need to revive FOP...
lsalvatore 7y ago
Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.
- worldsayshi 7y ago
  As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it. Perhaps webassembly doesn't change this either?
  - beaker52 7y ago
    If anything I'd prefer it if styles, logic and dom lived together in the same file. I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
    - bitwize 7y ago
      So, .vue files then?
      - beaker52 7y ago
        That is one of the thing I like about vue.
- deleted 7y ago
  [deleted]
- 7y ago
bobajeff 7y ago
>HTML is the interface you write to. It's not a document layout language for authoring I'm with you on speration of concerns but HTML is not for rendering; it's for structuring and adding semantics to your documents. (CSS is for presentation control and JavaScript is for behavior.)
oaiey 7y ago
Well QT can easily render on any device context (like Canvas) or Xamarin could also easily ship their own controls to render on a Canvas (Microsoft owns more that enough code to do that). It is a matter of time till we see desktop application hosted in a wasm enabled browser.
- danShumway 7y ago
  QT is already experimenting with rendering to Canvas using WASM in the browser, I've tried to call them out on it as bad practice a couple of times in the past. Rust on the other hand is doing some genuinely exciting, powerful stuff with allowing WASM to talk to the DOM and allowing native developers to target HTML directly within their apps. Rust's approach is to treat the language like a minimal, drop-in replacement for Javascript that doesn't require you to ship an entire rendering engine alongside it. It is yet to be seen which approach to web portability is going to win. Obviously I'm rooting for Rust, and I personally think apps that are written using Rust's strategy will nearly always be higher quality than apps written using QT's strategy. But that doesn't necessarily mean that Rust will win, there are a lot of factors at play here. It'll be interesting to see. But agreed, native apps are definitely coming to the web in some form or another. Funnily, the opposite is also true, since there's been a lot of buzz about using WASM for native sandboxing. I like to think that Gary Bernhardt[0] is pleased about that. [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

crimsonalucard 7y ago

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.

danShumway 7y ago
95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
- crimsonalucard 7y ago
  >95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic. >HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target. Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML. This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library. >This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible. while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
  - danShumway 7y ago
    This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that. > It would be better if the web browser world had pixel level render targets We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does. Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them. To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users. In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.
int_19h 7y ago
I wonder if perhaps we need to revive FOP...

lsalvatore 7y ago

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.

worldsayshi 7y ago
As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it. Perhaps webassembly doesn't change this either?
- beaker52 7y ago
  If anything I'd prefer it if styles, logic and dom lived together in the same file. I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
  - bitwize 7y ago
    So, .vue files then?
    - beaker52 7y ago
      That is one of the thing I like about vue.
deleted 7y ago
[deleted]
7y ago

bobajeff 7y ago

>HTML is the interface you write to. It's not a document layout language for authoring I'm with you on speration of concerns but HTML is not for rendering; it's for structuring and adding semantics to your documents. (CSS is for presentation control and JavaScript is for behavior.)

oaiey 7y ago

Well QT can easily render on any device context (like Canvas) or Xamarin could also easily ship their own controls to render on a Canvas (Microsoft owns more that enough code to do that). It is a matter of time till we see desktop application hosted in a wasm enabled browser.

danShumway 7y ago
QT is already experimenting with rendering to Canvas using WASM in the browser, I've tried to call them out on it as bad practice a couple of times in the past. Rust on the other hand is doing some genuinely exciting, powerful stuff with allowing WASM to talk to the DOM and allowing native developers to target HTML directly within their apps. Rust's approach is to treat the language like a minimal, drop-in replacement for Javascript that doesn't require you to ship an entire rendering engine alongside it. It is yet to be seen which approach to web portability is going to win. Obviously I'm rooting for Rust, and I personally think apps that are written using Rust's strategy will nearly always be higher quality than apps written using QT's strategy. But that doesn't necessarily mean that Rust will win, there are a lot of factors at play here. It'll be interesting to see. But agreed, native apps are definitely coming to the web in some form or another. Funnily, the opposite is also true, since there's been a lot of buzz about using WASM for native sandboxing. I like to think that Gary Bernhardt[0] is pleased about that. [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...