Live data from Hacker News

Tenets

github.com

141–150 of 162 posts

Re: Tenets

#141
post #105

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.

No worries :) DAWs have now become my go to example of complex interactive UIs :)

Re: Tenets

#142
post #33

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

[deleted]

Re: Tenets

#143
post #7

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…

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.

Re: Tenets

#144
post #54

Earlier 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?

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

Re: Tenets

#145

Earlier 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…

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

#146

Earlier 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…

I get that runes are in some sense a reduction of magic, I just don’t see the point. Svelte 4 feet, to me, incredibly natural to write, because the choice of idioms matched so closely with the behaviour I’d expect from JavaScript. Going into Svelte 5, I hoped to see fixes for the things that bit me - missing transitive reactivity in $:, for example. But not wholesale changes to the way you declare and use the framework.

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

#147
I like the general idea of Svelte, but last time I tried it, it required a lot of bloat (tens of files) for just a simple “hello world” project, which put me off.

Re: Tenets

#148
post #19
post #7

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…

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

Re: Tenets

#149
post #141

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

That said, there are examples of these being implemented in-browser. Not sure how any just use the canvas/webgl vs. the DOM (I know examples that do each).

Re: Tenets

#150
post #7

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…

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.

if that's what you thought separation of concerns meant it's best to forget it
Post reply on HN