71–80 of 162 posts
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 l…
Ha, did not expect this to be on the front page of HN today! Some quick context: in January I was in London for a few days, and while I was there we had a Svelte Society London event. This document is a text version of a talk I gave there, which expands on some of these ideas: https://www.youtube.com/watch?v=eswNQiq4T2w&t=5211s It's deliberately brief and vague in parts, because it's designed to spur conversation. It…
Earlier quoted context omitted.
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…
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} what was the question? {/if}
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.)
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 l…
> 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 actu…
While I think that might be true, similarly, JSX proves that for the dynamic parts of the template, you want a real programming language.
Can anyone fill me in on the backstory about lighthouse? What is it? Why is it a bad measure?
Earlier quoted context omitted.
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.
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.)
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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…
> 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.
Earlier quoted context omitted.
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.
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.