[nightski]

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.

[jmull]

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.

[ricardobeat]

> I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical

99.9% of people using React have no clue how the reconciler works, how hooks are implemented, how context works, what useEffect does, yet none of that is considered “magic” somehow.

[nightski]

I hear you, but at the end of the day it isn't really targeting HTML. Not when it looks like this -

{#if answer === 42} <p>what was the question?</p> {/if}

[jmull]

You're just pointing out that svelte isn't 100% the same as HTML...

That is true... but of course, if you wanted 100% HTML, you aren't looking for a framework at all.

The approach in svelte is that you write the HTML parts of your app in HTML. It sounds almost silly to say -- that should almost be a silly circular statement -- but with some popular frameworks you write the HMTL for your app in something sorta like HTML but with various syntactic and semantic differences.

(You also write most of your UI logic in Javascript or typescript. The amount of syntax that is svelte-specific is pretty small, though semantically, the Javascript you write for the UI is built on the svelte concepts.)

[spankalee]

Sure it is, all the rest of the markup is HTML. Just because it's an extension of HTML doesn't mean it's still not very HTML.

[nightski]

The same argument could be said of JSX though.

[jmull]

Sure... but there are degrees of closeness to HTML and the closer to HTML it is, the less translation you have to do and the easier it is to deal with.

That is, the closer to HTML the better.

Plain javascript is a crappy way to represent HTML because both the syntax and semantics are different (and sometimes there are conflicts, like with "class").

JSX is better than plain javascript because the syntax is closer, but the semantics are still Javascript, and there are still a number of differences you need to work through.

svelte is even better, because the HTML parts are strictly character-by-character the same as HTML, but you still need to know the syntax of a few escape mechanisms.

If there were a way to improve significantly on svelte then I'd be all for it. (Maybe HTMX? I'm skeptical of the approach of putting a network round-trip into every UI interaction, but they sure have nailed down the HTML aspect of it.)

[nightski]

I'm not buying it. Svelte's template language also has different syntax/semantics from HTML as well - arguably just as much. The JSX parts are character for character the same as HTML as well, except for the class/className distinction (which if you have used Preact it does not have that issue).

[scotty79]

It's html plus adhoc behavior description language. Behavior does not belong in HTML. You shouldn't have full programming language in HTML. And if you do, at least use existing language not make your own.

Since all of this is client side (and display: none; is the best you can do in terms of not revealing everything to the user anyways) you don't even need any behavior language in HTML. Just set classes to elements and manipulate them with the framework from outside.

[foota]

Sure, you should understand how your html will render, but expressing logic and handlers etc., in the html is just painful to me.

[immibis]

Check out the examples. Logic is expressed in Javascript inside <script> tags, just like vanilla web dev.

[blowski]

> 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.

[jmull]

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.)

[nine_k]

Abstractions are great, as long as you understand their performance implications. Some are essentially free, some are surprisingly costly if you hold them wrong.

Sadly, there's no way around understanding HTML and CSS when you need to troubleshoot what a high-level framework built for you. (Or maybe there is! Render everything using WebGL, the way Flutter does, and Flash did before it. But it's a different kettle of fish.)

[Charon77]

That is what's called a leaky abstraction.

Think, how often do you write a javascript code and think to yourself to debug it by understanding the underlying assembler code. I'd guess it's nil.

But abstractions to html leaks a lot.

Leaky abstractions are never good as now you have to think about your cool framework and the underlying library.

[amadeuspagel]

Open the browsers dev tools and you see HTML. Read MDN and you see HTML. Constantly translating back and forth between that and another language isn't worth it.

[Aerbil313]

Though if there was a better language to describe the UI which is as performant, widely supported and documented as HTML, I can easily see people using it. Maybe someone will start that project today based on my comment, and a decade later browsers will integrate it natively because it's such a success and everyone is using it :).

[bl4kers]

It's quite important for accessibility.

[threatofrain]

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.

[PaulDavisThe1st]

problem is, the most important "abstractions" for describing the UI are not built "on top of" HTML, but along side it (CSS and to a limited degree JS). the relationship between contemporary "frameworks" and HTML is not like that of C and assembler or even Rust and assembler. It is more like that of a driver of a vehicle that has each of a gasoline, electric and steam powered motor, and must constantly pick which one to use for a given situation (sometimes two and occasionally all three).

[spankalee]

> 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]

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.

[mixmastamyk]

Have a blogpost handy? Sounds interesting but I don’t know much about it.

[codeflo]

> JSX proves that HTML actually won.

While I think that might be true, similarly, JSX proves that for the dynamic parts of the template, you want a real programming language.

[scotty79]

I'd say that it's better to use real programming language, but you shouldn't use it in JSX beyond the simplest statements like ifs and loops.

Mixing any logic beyond that with HTML makes a mess of both.

I'm personally a fan of minimalist templating engines that provide only simple loops and conditionals so that template has to receive prepared data tree which is created by the actual programming language first and passed into the template.

[mixmastamyk]

Sounds like Django, which I’ve found maintainable.

[wruza]

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.

That’s completely an opinion, and I have another one. Html sucks at reading and writing, it is cumbersome (and also non-typed, and non-structured), and js structs/calls are much better for creating these trees.

Jsx proves nothing but that react team had to make a decision about format and they decided to not experiment with formats due to drop-in compatibility. That’s it.

[lenkite]

I personally agree - mileage definitely varies with people. Prefer markup languages over code for describing user-interfaces any day. Find myself quite comfortable with XAML and struggle with SwiftUI.

[mixmastamyk]

It depends on the markup format, language, and libraries of course. However in general I prefer code. Why? While it takes a bit longer to get started, you can factor patterns into reusable methods and before you know it are working at a higher level:

    make_fancy_dialog(msg);

Html only recently got templates but I don’t believe they are that powerful.

[Hugsun]

I suspect that the dominance of HTML is largely due to it being the only browser native markup language. Crucially, the browsers' dev tools always show HTML and having an obvious mapping from there to your code is hard to beat.

I personally dislike HTML due to the verbosity. I prefer hyperscript.

[PaulDavisThe1st]

> I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree,

In the context of the discussion, that would imply that "a render and layout tree" is a good way to describe a UI. That too is subject to serious questions.

[spankalee]

Yes, I would claim that. What major, non-game, UI stacks out there aren't structured that way?

[PaulDavisThe1st]

Well, the constraint layout system that Apple introduced (sorry, I am drawing a blank on the name) is sufficiently different that I'd say that although technically you could call it a layout tree, that is really missing the point.

Also, the render tree concept doesn't exist in the internals of GTK (at least; I could speculate about Qt but will not). Rendering is done by invalidating rectangles and then finding intersections with widgets; since there is no z-axis stacking, there's only ever 1 widget to be drawn at a given pixel coordinate.

[patcon]

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

[pier25]

> 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]

> 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.

[ramesh31]

>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.

[troupo]

> 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]

My browser can't run Delphi or Turbo Pascal.

[troupo]

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=...

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... 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]

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.

[troupo]

1. I've already answered about "in the browser"

2. Even in the browser it's the worst possible system

3. The original comment I was replying to didn't make any references to "in the browser", and explicitly talked about things like QML and XIB which are very much not in the browser.

[CharlesW]

I don't think anyone's trying to be impolite or diminish What Came Before, but HTML is used for lots more than websites and browsers. (Examples that come to mind are email, desktop and mobile apps, ebooks, and digital signage.)

[WeAddValue]

So, like an election in Russia, there's only one candidate in the race?

[wruza]

As a russian, I like this comparison, because it’s really on point and how I feel every time someone says:

- But HTML is lingua franca!

- There’s no alternative, that means it’s perfect

- You don’t need js/json/etc, just use HTML

- HTML is not that bad

- You can choose JSX, but it’s mostly HTML

[immibis]

"There's literally nothing better than HTML for UI" and "There's literally nothing better than HTML for UI in my browser" are two different statements; anyway, until relatively recently there was XUL.

[troupo]

Yes, they are two different statements. However, the comment I was responding to was making general claims and even used QML and XIB as examples.

[scotty79]

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.

[bbkane]

Flutter has been a lot of fun in my few experiments with it, but it's not nearly as proven as HTML

[immibis]

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]

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.

[amelius]

> 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]

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]

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.

[hpeter]

"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.

[shdh]

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.

[ForHackernews]

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.

[satvikpendem]

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]

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]

Or you could put all that stuff in a single-file component or use JSX with atomic CSS or CSS in JS.

[blackoil]

Do a 5 why for separation of concern and you'll find JSX is more logical.

You want things edited together to be closer in code also. A single file or couple of files next to each other that decide structure, behaviour and view of a component is better than few CSS/JS for whole site.

[nathias]

if that's what you thought separation of concerns meant it's best to forget it

[shdh]

JSX is an anti-pattern IMO. People just don’t wana see it as such.

[notpachet]

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.

[troupo]

> 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

[blackoil]

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.

[davedx]

> 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!