7 ms·

Now I know why I dislike Svelte so much, I don't believe in its principles. Which is perfectly fine, a framework can't please everyone. HTML is not the mother

Now I know why I dislike Svelte so much, I don't believe in its principles. Which is perfectly fine, a framework can't please everyone. HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. This is why JS solutions are so appealing. If HTML is so magical why do they need a fancy template language? Magical, not magic - I really don't want it to feel magical either. I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical. No one cares - The countless blogs, posts, and communication around frameworks implies that yes, developers do indeed care. Details are important. You can't waive away concepts like memoization because they need to be used in the right context. There's no one size fits all solution to caching.

deleted 3y ago
[deleted]
ramesh31 3y ago
>HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. Compared to... what? XML? QML? XIB? There's literally nothing better than HTML for UI. Anything else is either buried in a mountain of proprietary nonsense, is platform specific, or is far inferior technically.
- bbkane 3y ago
  Flutter has been a lot of fun in my few experiments with it, but it's not nearly as proven as HTML
- troupo 3y ago
  > There's literally nothing better than HTML for UI. Except... Literally everything else. Imperative Delphi code from early 2000s or indeed Turbo Pascal code from 1995 will run circles around HTML any day of the week and twice on Sundays.
  - hpeter 3y ago
    My browser can't run Delphi or Turbo Pascal.
    - troupo 3y ago
      I was responding to this: "There's literally nothing better than HTML for UI." In general that is false statement. In particular, when it relates to browsers, HTML is the local minimum of what can be done to describe the "UI". Because HTML (well, DOM) is the only thing to describe the UI in the browser, and it's abhorrently awful. It can barely describe a page with static text and some images (and even then tools like Lighthouse will warn you that "you have too many elements on the page" if you dare go beyond 100 or so paragraphs). For the actual UI (yes, UI: complex layouts, interactions, dynamic parts, states, hundreds of complex interactable objects) HTML is unbelievably incredibly bad. Unfortunately that's the only thing you have running in the browser [1] [1] Well, there's canvas (Google Docs switched to canvas because of limitations of the DOM etc.) and WebGL (pretty much every in-browser graphics program out there). But they suffer from having to implement literally everything from scratch. Edit. Just to show how inane "HTML is superior to everything is", here it is barfing at my static web site that only contains text and images (and a total of 9 Youtube and maps embeds): https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=medium https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=... Yes. It chokes on the insane number of .... 943 elements with a maximum depth of 8. Apropos of nothing, here's a screenshot of a highly dynamic interface like Ableton Live with hundreds of dynamic elements https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at-01.18.07.png https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at... that the "technical superior" HTML would not even be able to represent, much less render. In reality it's very hard to find anything that is inferior to HTML when it comes to representing and rendering UIs.
      - PaulDavisThe1st 3y ago
        Even after all that, you still haven't made explicit the thing that needs to be explicit for any of this to make any sense: ".... for UI *IN A BROWSER*" I know it's convenient to forget the millions of us who spent years and continue to spend hours implementing UIs outside of a browser context, but it certainly doesn't feel very polite.
- scotty79 3y ago
  HTML was designed to describe single A4 page of single column text. The fact that people started building apps with is was miraculous persistence. HTML acquire some functionalities that supported such advanced things as multiple columns or fairly recently some automatic layouts not directly stemming from its text displaying roots. But in terms of flexibility and ease of use they are still behind layouts of Delphi from 20 years ago.
- immibis 3y ago
  Even some of the "proprietary nonsense" is better than HTML. Visual Basic let you just drag-and-drop controls onto a page, arranged in any way you liked! Now, it wasn't responsive, but we didn't have smartphones back then so nobody cared.
  - mixmastamyk 3y ago
    There were layout managers in the 90s which were responsive, though they wouldn’t reflow widgets vertically. Similar to horizontal flexbox. I bet someone could have added the functionality but it just didn’t matter when all screens were squareish.
patcon 3y ago
I am not a svelte user, but I really like these principles. I feel very different than you, but I am sincerely glad you have clarity and that you better understand what YOU are looking for :) having said that, we'll likely end up happily working on different things in different pastures
jmull 3y ago
I'm not a big fan of HTML itself, but I do think svelte is right to focus on it for specifying UI. That's because HTML is the native language for describing UI in the browser. No matter what you use to specify UI, you have to understand how it translates to HTML to use it in the browser (and how HTML translates back, for debugging). The further your UI specification language deviates from HTML the harder that it. Of course, there are plenty of people using various frameworks that don't really understand HTML or how the code they write translates to it. But they end up with crappy web sites and bugs they don't know how to fix and various other compromises and frustrations.
- blowski 3y ago
  > HTML is the native language for describing UI in the browser In the same way that assembler is the native language for giving instructions to the CPU. In practice, it is of zero importance, because there are powerful abstractions built on top of it, with wonderful benefits once you’re building anything more complicated than one-page documents.
  - bl4kers 3y ago
    It's quite important for accessibility.
    - threatofrain 3y ago
      I've found that web accessibility often calls for nice templates and abstraction, not less, because you often need to do some dynamic rewriting. For example, in a world where components are embedded into different places on a website and where users might submit rich text content, you have to rewrite their headers (h1...h6) to fit with accessibility guidelines.
  - jmull 3y ago
    That's not the same because the abstraction a mature computer language provides is nearly complete (not totally complete, of course, but the situations where you ought to go digging through machine code or lower are pretty rare). Outside of games, almost all the frameworks people use don't try to do that -- you are essentially trying to write HTML, but using the syntax of a different language, or each HTML thing in a thing from a different language. (Flutter is the exception -- it really does try to provide a complete abstraction, though it's certainly not without its tradeoffs.)
ForHackernews 3y ago
No accounting for taste, I suppose. Writing JSX is a nightmare to me. It's like we've forgotten 20 years worth of hard-earned knowledge about the value of separation of concerns.
- notpachet 3y ago
  I agree with you about separation of concerns, but I don't think JSX is the guilty party there, so much as the overarching frontend ethos that pushes the idea of "single file components" to extremes.
- satvikpendem 3y ago
  What is the value of separation of concerns when it comes to UI? Because I find not colocating the logic and styling for a component to be very annoying when it comes to looking for the right files.
  - vagrantJin 3y ago
    The component DIR should have css, logic/js and template/markup. Seperation of concerns right down to component level. It really comes down to how organised the devs and their tools are.
    - satvikpendem 3y ago
      Or you could put all that stuff in a single-file component or use JSX with atomic CSS or CSS in JS.
- troupo 3y ago
  > It's like we've forgotten 20 years worth of hard-earned knowledge about the value of separation of concerns. No. We haven't. Because there's a different separation of concerns: https://twitter.com/simonswiss/status/1664736786671869952 https://twitter.com/simonswiss/status/1664736786671869952
- shdh 3y ago
  JSX is an anti-pattern IMO. People just don’t wana see it as such.
amelius 3y ago
> Magical, not magic The problem with magical is that bugs and performance issues will make you feel like you're dealing with a bad spell and there's no logical solution.
- furyofantares 3y ago
  I feel like this phrase is causing confusion and the distinction the author is trying to make is clear in their mind but very unclear to read. I'm not sure but I think the distinction being made is "not magic" means you're expected to be able to understand how and why something works. And "magical" means it should be surprisingly easy to do what you want.
satvikpendem 3y ago
I agree, I'm not going to learn yet another DSL for describing basic programming constructs when I can just...use a programming language itself. The lack of TypeScript and LSP support for quite a few of these DSLs is also very annoying, you're basically reinventing new tooling for every new framework.
spankalee 3y ago
> HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree, so much so that people are embedding HTML-like syntax in programming languages because the syntax is better than what the language already has to offer. To paraphrase something I've heard: JSX proves that HTML actually won. And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular. But markup is king, whether it's in JS like JSX or Lit-like tagged template literals, or in an HTML-like file like Angular, Vue, or Svelte. They all share a markup-based syntax. > If HTML is so magical why do they need a fancy template language? Note that Rich doesn't say that HTML is magical. He says it's good, which it undeniably is. It describes elements with attributes and children, which happens to be exactly the structure you need for the vast majority of UI widget concepts. The reason you need a fancier template syntax is that while HTML is good it isn't perfect. HTML doesn't have a dynamic binding syntax (though standards is working on that with Template Instantiation) or conditionals, and attributes are underpowered. So template systems generally add those things. Whether it's JSX, Svelte, lit-html, Angular, etc... they share those common enhancements. The only real big disagreement is whether you embed the logic in HTML or the HTML in JS. It's not even that fundamental of a difference. I prefer HTML-in-JS myself (note: I'm on the Lit team) because JS already has binding syntax, expressions, control flow; because the data is already available in JS; and because JS has a module system and you can do all the things without forking a language or a build step. But having been on the Polymer side too, which is logic-in-HTML, I know that a lot of people prefer HTML syntax and that to some it's more clear how it maps to the DOM created on the page, simply due to syntax similarity. That's fine. But it's really all variants of HTML in the end.
- spankalee 3y ago
  Also, these differences in syntax and opinion are why I vehemently support and work on web components. You shouldn't have to have two incompatible silos of UI building just because of some frankly minor differences in preferences. Component authors and component users should be able to seamlessly interoperate which disagreeing about such trivial things.
hpeter 3y ago
"HTML is not the mother language" You don't need js to create a website, you only need HTML. For dynamic UI you need a server, not javascript. Your server can render html, it doesn't have to serve json.
deleted 3y ago
[deleted]
shdh 3y ago
Have used: Angular, Vue, Polymer 1 and 2, React Svelte is by far my favorite framework of the lot. It’s also the most productive for me.
pier25 3y ago
> describing dynamic user interfaces GUIs are essentially 2d scene graphs. Basically you need to describe a tree of hierarchical relationships. I agree HTML is not great for the dynamic part and the reacitivity but it's the lingua franca of the web. Why reinvent some new DSL when you already have one that was already designed to represent a scene graph.
scotty79 3y ago
> HTML is not the mother language Personally I just don't like when people go too much into "<lang> in <lang>" mentality. HTML is decent at describing what's there. CSS is sort of fine at describing how it looks. And JS is ok for describing what should happen. My second guiding principle is that everything should be split into composable components, without anything being privileged. So I don't like page components being special in any way. I can excuse some violations of the first principle in the service of the second one like putting a bit of HTML into JS file instead of keeping separate HTML template file for each component. But I don't really like any CSS in JS. The only connection surface between CSS and JS (and HTML) should be selectors that say what is addressed. CSS classes should identify elements. If you want some classes that describe groups of styles (like tailwind) you can have them but don't cram them directly into HTML. Include them in styles for given element using SASS (or LESS) include functionality. HTML (or JS) shouldn't describe how things look. Also all the frameworks that claim to be almost pure HTML but they cram the adhoc behavior description into fake HTML attributes rub me the wrong way. They remind me of what was there 20 years ago. And any reactive bindings between arbitrary stuff is just ordering whole bowl of old time spaghetti, after Redux (and React) shown that it doesn't have to be like that anymore. I agree that additional challenge of keeping the flow of state centralized and unidirectional might feel unnecessary for simple projects, but it's worth it if the project survives more than few years and grows.
davedx 3y ago
> Magical, not magic - I really don't want it to feel magical either. I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical. Don't worry - they hint that they're gonna change it again in Svelte 5 anyway, so the suckers using it can throw away their code and start again with slightly less magic ...but hey, vibes!
blackoil 3y ago
Yes, I also don't see the charm. JS/TS are more expressive, you can have composition and modular code natively. Also JSX is 99% HTML. With HTML first solutions, we sprinkle it with some # language which is neither simpler nor as expressive. It looks simple in toy examples, but for large projects you end up with worse structure.

deleted 3y ago

[deleted]

ramesh31 3y ago

>HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. Compared to... what? XML? QML? XIB? There's literally nothing better than HTML for UI. Anything else is either buried in a mountain of proprietary nonsense, is platform specific, or is far inferior technically.

bbkane 3y ago
Flutter has been a lot of fun in my few experiments with it, but it's not nearly as proven as HTML
troupo 3y ago
> There's literally nothing better than HTML for UI. Except... Literally everything else. Imperative Delphi code from early 2000s or indeed Turbo Pascal code from 1995 will run circles around HTML any day of the week and twice on Sundays.
- hpeter 3y ago
  My browser can't run Delphi or Turbo Pascal.
  - troupo 3y ago
    I was responding to this: "There's literally nothing better than HTML for UI." In general that is false statement. In particular, when it relates to browsers, HTML is the local minimum of what can be done to describe the "UI". Because HTML (well, DOM) is the only thing to describe the UI in the browser, and it's abhorrently awful. It can barely describe a page with static text and some images (and even then tools like Lighthouse will warn you that "you have too many elements on the page" if you dare go beyond 100 or so paragraphs). For the actual UI (yes, UI: complex layouts, interactions, dynamic parts, states, hundreds of complex interactable objects) HTML is unbelievably incredibly bad. Unfortunately that's the only thing you have running in the browser [1] [1] Well, there's canvas (Google Docs switched to canvas because of limitations of the DOM etc.) and WebGL (pretty much every in-browser graphics program out there). But they suffer from having to implement literally everything from scratch. Edit. Just to show how inane "HTML is superior to everything is", here it is barfing at my static web site that only contains text and images (and a total of 9 Youtube and maps embeds): https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=medium https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=... Yes. It chokes on the insane number of .... 943 elements with a maximum depth of 8. Apropos of nothing, here's a screenshot of a highly dynamic interface like Ableton Live with hundreds of dynamic elements https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at-01.18.07.png https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at... that the "technical superior" HTML would not even be able to represent, much less render. In reality it's very hard to find anything that is inferior to HTML when it comes to representing and rendering UIs.
    - PaulDavisThe1st 3y ago
      Even after all that, you still haven't made explicit the thing that needs to be explicit for any of this to make any sense: ".... for UI *IN A BROWSER*" I know it's convenient to forget the millions of us who spent years and continue to spend hours implementing UIs outside of a browser context, but it certainly doesn't feel very polite.
scotty79 3y ago
HTML was designed to describe single A4 page of single column text. The fact that people started building apps with is was miraculous persistence. HTML acquire some functionalities that supported such advanced things as multiple columns or fairly recently some automatic layouts not directly stemming from its text displaying roots. But in terms of flexibility and ease of use they are still behind layouts of Delphi from 20 years ago.
immibis 3y ago
Even some of the "proprietary nonsense" is better than HTML. Visual Basic let you just drag-and-drop controls onto a page, arranged in any way you liked! Now, it wasn't responsive, but we didn't have smartphones back then so nobody cared.
- mixmastamyk 3y ago
  There were layout managers in the 90s which were responsive, though they wouldn’t reflow widgets vertically. Similar to horizontal flexbox. I bet someone could have added the functionality but it just didn’t matter when all screens were squareish.

patcon 3y ago

I am not a svelte user, but I really like these principles. I feel very different than you, but I am sincerely glad you have clarity and that you better understand what YOU are looking for :) having said that, we'll likely end up happily working on different things in different pastures

jmull 3y ago

I'm not a big fan of HTML itself, but I do think svelte is right to focus on it for specifying UI. That's because HTML is the native language for describing UI in the browser. No matter what you use to specify UI, you have to understand how it translates to HTML to use it in the browser (and how HTML translates back, for debugging). The further your UI specification language deviates from HTML the harder that it. Of course, there are plenty of people using various frameworks that don't really understand HTML or how the code they write translates to it. But they end up with crappy web sites and bugs they don't know how to fix and various other compromises and frustrations.

blowski 3y ago
> HTML is the native language for describing UI in the browser In the same way that assembler is the native language for giving instructions to the CPU. In practice, it is of zero importance, because there are powerful abstractions built on top of it, with wonderful benefits once you’re building anything more complicated than one-page documents.
- bl4kers 3y ago
  It's quite important for accessibility.
  - threatofrain 3y ago
    I've found that web accessibility often calls for nice templates and abstraction, not less, because you often need to do some dynamic rewriting. For example, in a world where components are embedded into different places on a website and where users might submit rich text content, you have to rewrite their headers (h1...h6) to fit with accessibility guidelines.
- jmull 3y ago
  That's not the same because the abstraction a mature computer language provides is nearly complete (not totally complete, of course, but the situations where you ought to go digging through machine code or lower are pretty rare). Outside of games, almost all the frameworks people use don't try to do that -- you are essentially trying to write HTML, but using the syntax of a different language, or each HTML thing in a thing from a different language. (Flutter is the exception -- it really does try to provide a complete abstraction, though it's certainly not without its tradeoffs.)

ForHackernews 3y ago

No accounting for taste, I suppose. Writing JSX is a nightmare to me. It's like we've forgotten 20 years worth of hard-earned knowledge about the value of separation of concerns.

notpachet 3y ago
I agree with you about separation of concerns, but I don't think JSX is the guilty party there, so much as the overarching frontend ethos that pushes the idea of "single file components" to extremes.
satvikpendem 3y ago
What is the value of separation of concerns when it comes to UI? Because I find not colocating the logic and styling for a component to be very annoying when it comes to looking for the right files.
- vagrantJin 3y ago
  The component DIR should have css, logic/js and template/markup. Seperation of concerns right down to component level. It really comes down to how organised the devs and their tools are.
  - satvikpendem 3y ago
    Or you could put all that stuff in a single-file component or use JSX with atomic CSS or CSS in JS.
troupo 3y ago
> It's like we've forgotten 20 years worth of hard-earned knowledge about the value of separation of concerns. No. We haven't. Because there's a different separation of concerns: https://twitter.com/simonswiss/status/1664736786671869952 https://twitter.com/simonswiss/status/1664736786671869952
shdh 3y ago
JSX is an anti-pattern IMO. People just don’t wana see it as such.

amelius 3y ago

> Magical, not magic The problem with magical is that bugs and performance issues will make you feel like you're dealing with a bad spell and there's no logical solution.

furyofantares 3y ago
I feel like this phrase is causing confusion and the distinction the author is trying to make is clear in their mind but very unclear to read. I'm not sure but I think the distinction being made is "not magic" means you're expected to be able to understand how and why something works. And "magical" means it should be surprisingly easy to do what you want.

satvikpendem 3y ago

I agree, I'm not going to learn yet another DSL for describing basic programming constructs when I can just...use a programming language itself. The lack of TypeScript and LSP support for quite a few of these DSLs is also very annoying, you're basically reinventing new tooling for every new framework.

spankalee 3y ago

> HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree, so much so that people are embedding HTML-like syntax in programming languages because the syntax is better than what the language already has to offer. To paraphrase something I've heard: JSX proves that HTML actually won. And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular. But markup is king, whether it's in JS like JSX or Lit-like tagged template literals, or in an HTML-like file like Angular, Vue, or Svelte. They all share a markup-based syntax. > If HTML is so magical why do they need a fancy template language? Note that Rich doesn't say that HTML is magical. He says it's good, which it undeniably is. It describes elements with attributes and children, which happens to be exactly the structure you need for the vast majority of UI widget concepts. The reason you need a fancier template syntax is that while HTML is good it isn't perfect. HTML doesn't have a dynamic binding syntax (though standards is working on that with Template Instantiation) or conditionals, and attributes are underpowered. So template systems generally add those things. Whether it's JSX, Svelte, lit-html, Angular, etc... they share those common enhancements. The only real big disagreement is whether you embed the logic in HTML or the HTML in JS. It's not even that fundamental of a difference. I prefer HTML-in-JS myself (note: I'm on the Lit team) because JS already has binding syntax, expressions, control flow; because the data is already available in JS; and because JS has a module system and you can do all the things without forking a language or a build step. But having been on the Polymer side too, which is logic-in-HTML, I know that a lot of people prefer HTML syntax and that to some it's more clear how it maps to the DOM created on the page, simply due to syntax similarity. That's fine. But it's really all variants of HTML in the end.

spankalee 3y ago
Also, these differences in syntax and opinion are why I vehemently support and work on web components. You shouldn't have to have two incompatible silos of UI building just because of some frankly minor differences in preferences. Component authors and component users should be able to seamlessly interoperate which disagreeing about such trivial things.

hpeter 3y ago

"HTML is not the mother language" You don't need js to create a website, you only need HTML. For dynamic UI you need a server, not javascript. Your server can render html, it doesn't have to serve json.

deleted 3y ago

[deleted]

shdh 3y ago

Have used: Angular, Vue, Polymer 1 and 2, React Svelte is by far my favorite framework of the lot. It’s also the most productive for me.

pier25 3y ago

> describing dynamic user interfaces GUIs are essentially 2d scene graphs. Basically you need to describe a tree of hierarchical relationships. I agree HTML is not great for the dynamic part and the reacitivity but it's the lingua franca of the web. Why reinvent some new DSL when you already have one that was already designed to represent a scene graph.

scotty79 3y ago

> HTML is not the mother language Personally I just don't like when people go too much into "<lang> in <lang>" mentality. HTML is decent at describing what's there. CSS is sort of fine at describing how it looks. And JS is ok for describing what should happen. My second guiding principle is that everything should be split into composable components, without anything being privileged. So I don't like page components being special in any way. I can excuse some violations of the first principle in the service of the second one like putting a bit of HTML into JS file instead of keeping separate HTML template file for each component. But I don't really like any CSS in JS. The only connection surface between CSS and JS (and HTML) should be selectors that say what is addressed. CSS classes should identify elements. If you want some classes that describe groups of styles (like tailwind) you can have them but don't cram them directly into HTML. Include them in styles for given element using SASS (or LESS) include functionality. HTML (or JS) shouldn't describe how things look. Also all the frameworks that claim to be almost pure HTML but they cram the adhoc behavior description into fake HTML attributes rub me the wrong way. They remind me of what was there 20 years ago. And any reactive bindings between arbitrary stuff is just ordering whole bowl of old time spaghetti, after Redux (and React) shown that it doesn't have to be like that anymore. I agree that additional challenge of keeping the flow of state centralized and unidirectional might feel unnecessary for simple projects, but it's worth it if the project survives more than few years and grows.

davedx 3y ago

> Magical, not magic - I really don't want it to feel magical either. I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical. Don't worry - they hint that they're gonna change it again in Svelte 5 anyway, so the suckers using it can throw away their code and start again with slightly less magic ...but hey, vibes!

blackoil 3y ago

Yes, I also don't see the charm. JS/TS are more expressive, you can have composition and modular code natively. Also JSX is 99% HTML. With HTML first solutions, we sprinkle it with some # language which is neither simpler nor as expressive. It looks simple in toy examples, but for large projects you end up with worse structure.