Hacker News Reader

Comment by jmull | Hacker News Reader

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.

View on HN

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

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}

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.

The same argument could be said of JSX though.

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

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

Svelte does not make any opinions about HTML attributes or tags, unlike JSX which contorts language standards such as `className` or disallowing style="..." without JS in CSS.

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.

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

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

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

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

It's quite important for accessibility.

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.

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

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

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.

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.

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

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

Reply on news.ycombinator.com