Earlier quoted context omitted.
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.
Sorry, somehow I really misread your comment. Not sure how I was so wrong in my reading. Needless to say I agree with everything you've written, and also appreciate the use of a DAW screenshot to make the point.
Tenets
141–150 of 162 posts
Re: Tenets
#142Earlier quoted context omitted.
> 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.
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.
Re: Tenets
#143Now 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…
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.
Re: Tenets
#144Earlier quoted context omitted.
My browser can't run Delphi or Turbo Pascal.
So, like an election in Russia, there's only one candidate in the race?
- 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
Re: Tenets
#145Earlier quoted context omitted.
What do you mean by "work"? You can export a mutable variable yes, but why would you? It makes no sense outside of Svelte and it doesn't relate to the rest of the code where you presumably use that variable as if it was set from the outside at the moment you were exporting it or something along those lines. In the end it is also just a compiler directive for svelte, it doesn't end up in the code the svelte compiler o…
> parsing required props and such out of this destructuring assignment is a bit magical, but to be honest in my view not significantly more magical than the rest of Svelte. I think this is the only place we really disagree. To me, the export syntax is obvious and consistent, even if under the covers the behaviour is magical. On the other hand, the $props syntax is not obvious; for a putative assignment to result in a…
> At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn't it better if let count is reactive by default?
> Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. And the heuristic only works for let declarations at the top level of a component, which can cause confusion. Having code behave one way inside .svelte files and another inside .js can make it hard to refactor code, for example if you need to turn something into a store so that you can use it in multiple places.
(https://svelte.dev/blog/runes)
If the vibes are subjectively off for you with the new syntax that's fair, I just can't get it to align with what you are saying because at the end of the day, they are removing some Svelte magic and replacing it with regular JavaScript, apparently even the "$" label dependency tracking stuff, which I find to currently be the most magical thing in Svelte
To me that looks like a step to making Svelte more easy to reason with, but vibes are subjective in the end.
Re: Tenets
#146Earlier quoted context omitted.
> parsing required props and such out of this destructuring assignment is a bit magical, but to be honest in my view not significantly more magical than the rest of Svelte. I think this is the only place we really disagree. To me, the export syntax is obvious and consistent, even if under the covers the behaviour is magical. On the other hand, the $props syntax is not obvious; for a putative assignment to result in a…
Interesting, because now that I'm looking at them a little closer, it seems to me runes are reduction of magic objects in Svelte > At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn't it better if let count is reactive by default? > Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. And the heurist…
Anyway I certainly agree that the vibe is subjective, but I for one am bitterly disappointed by Svelte 5. It’s yet another framework that can’t make up its mind, and stick to it.
Re: Tenets
#147Re: Tenets
#148Now 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…
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…
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.
Re: Tenets
#149Earlier quoted context omitted.
Sorry, somehow I really misread your comment. Not sure how I was so wrong in my reading. Needless to say I agree with everything you've written, and also appreciate the use of a DAW screenshot to make the point.
No worries :) DAWs have now become my go to example of complex interactive UIs :)
Re: Tenets
#150Now 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…
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.