Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tenets

github.com

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Tenets

#121

Post by __jonas »

doctor_eval wrote: post #118
__jonas wrote: post #117

Earlier quoted context omitted.

How is this new syntax not javascript? I’m not familiar with it but your example is just object destructuring no? What am I missing?

Because it’s introducing a magic global compiler directive - $props - that’s unique to Svelte. Everyone knows what export let prop = 10 means. But what’s $props? It’s a magical invocation (literally, a rune) of a compiler directive. So while it’s valid JS, it’s actually a signal to the compiler, with special behaviour. It’s something you need to learn and understand beyond just JavaScript. Also, to your point, it’s n…

> Everyone knows what

> export let prop = 10

> means.

What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks.

I'm just a bit surprised because while I like Svelte I feel like all of is like this, it's all technically JavaScript syntax but all of it is magic that only works through the Svelte compiler, and this new syntax actually looks slightly less so to me, although I wouldn't say I prefer it.

Re: Tenets

#122

Post by doctor_eval »

__jonas wrote: post #121
doctor_eval wrote: post #118

Earlier quoted context omitted.

Because it’s introducing a magic global compiler directive - $props - that’s unique to Svelte. Everyone knows what export let prop = 10 means. But what’s $props? It’s a magical invocation (literally, a rune) of a compiler directive. So while it’s valid JS, it’s actually a signal to the compiler, with special behaviour. It’s something you need to learn and understand beyond just JavaScript. Also, to your point, it’s n…

> Everyone knows what > export let prop = 10 > means. What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks. I'm just a bit surpr…

But doesn't

    export let myProp = 10
work in any JS module? I thought it was quite standard. Maybe I'm mistaken, JS/TS is not my first language, but I think it's pretty obvious what it's doing.

In any case,

    let { myProp = 10 } = $props
does not even remotely work like it would in JS. It's literally a compiler directive.

That is, $props is not an object. The string "$props" is a compile-time directive that declares myProp to be a prop. It's not destructuring $props, it's declaring myProp. "$props" is a magic incantation defined within the Svelte compiler.

I mean, this is my point really. It's using JS syntax but it's no longer obvious what it's doing.

To your point, given that Svelte compiles the code anyway, I don't understand why they couldn't have kept the existing syntax ("vibe") and just changed the semantics. Why come up with some brand new, syntactically-compatible- but semantically-incompatible-with-JS, syntax?

Re: Tenets

#123

Post by spankalee »

PaulDavisThe1st wrote: post #85
spankalee wrote: post #45

Earlier quoted context omitted.

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

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

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

Re: Tenets

#124

Post by __jonas »

doctor_eval wrote: post #122
__jonas wrote: post #121

Earlier quoted context omitted.

> Everyone knows what > export let prop = 10 > means. What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks. I'm just a bit surpr…

But doesn't export let myProp = 10 work in any JS module? I thought it was quite standard. Maybe I'm mistaken, JS/TS is not my first language, but I think it's pretty obvious what it's doing. In any case, let { myProp = 10 } = $props does not even remotely work like it would in JS. It's literally a compiler directive. That is, $props is not an object. The string "$props" is a compile-time directive that declares myPr…

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

Look at this example:

https://svelte.dev/repl/c450c88a415a435485729f4ba88069f1?ver...

If you check the JavaScript output tab on right, this prop declaration in Child.svelte

> export let count = 0;

Has become

> let { count = 0 } = $$props;

Which looks a lot closer to this new rune syntax, so

> does not even remotely work like it would in JS.

Is not true at all, it works a lot like this in JS, or at least a lot more than the "export let" syntax.

Edit:

I want to add to your point here:

> That is, $props is not an object. The string "$props" is a compile-time directive that declares myProp to be a prop. It's not destructuring $props, it's declaring myProp. "$props" is a magic incantation defined within the Svelte compiler.

I get you on this! I wasn't aware it worked like this and replaces the $$Props interface [1] which I am using to declare component props at the moment. I understand your point and I agree that 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.

[1] https://svelte-5-preview.vercel.app/docs/runes#$props-what-t...

Re: Tenets

#125

Post by saila »

noSyncCloud wrote: post #76
dayjah wrote: post #53

Can anyone fill me in on the backstory about lighthouse? What is it? Why is it a bad measure?

It's a set of performance tests built into the Chrome dev tools. It profiles your site on a variety of metrics and gives you a report. I'm not exactly sure what's wrong with it in the context of this post.

I've recently started using Lighthouse to test sites for accessibility compliance, and you can easily get a score of 100 without actually addressing all the accessibility issues a site might have. So, if you're not conscientious, you can just point at the score and say "all good" while your site might still have major issues.

I assume the same is true of the other checks Lighthouse does for performance, best practices, etc.

Lighthouse and other such tools are a good starting point, and using them is better than doing nothing, but a thorough understanding of accessibility etc is necessary to create truly accessible and performant sites.

Re: Tenets

#126

Post by xwowsersx »

One of the comments on GitHub says:

> the first time I use Svelte & Kit I feel the same joy as I feel when the first time learning web development in 2015

That sounds pretty awesome. If you have experience with Svelte and this resonates with you, could you explain why?

Re: Tenets

#127

Post by doctor_eval »

__jonas wrote: post #124
doctor_eval wrote: post #122

Earlier quoted context omitted.

But doesn't export let myProp = 10 work in any JS module? I thought it was quite standard. Maybe I'm mistaken, JS/TS is not my first language, but I think it's pretty obvious what it's doing. In any case, let { myProp = 10 } = $props does not even remotely work like it would in JS. It's literally a compiler directive. That is, $props is not an object. The string "$props" is a compile-time directive that declares myPr…

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 declaration has no basis in my previous experience. Both the syntax and the behaviour is magical.

If Svelte is about the vibe, Svelte 4 was perfect for me - it’s why I moved from Vue, which I found had too many magic objects, and then doubled down on it with Vue 3 (I think) and refs. With Svelte 5, I feel it’s making the same mistake - the vibe no longer gels with me, and I gotta say, in addition, that pushing reactive behaviour into pure JS feels like a huge mistake to me. Sadly, I think I’ll be getting off this particular train.

Edit: I think my reaction to this is because $props - and the other runes - are effectively svelte-specific keywords added to JavaScript. I'm sure the Svelte folks have their reasons for this; but I hate it. They could have just introduced a new actual keyword, like "prop myProp = 5". I honestly can't see myself ever adopting Svelte 5.

Re: Tenets

#128

Post by [deleted] »

rykuno wrote: post #25

The direction React/NextJS has taken modern web development is a modern day abomination. I say this as a passionate fullstack developer whos worked for YC startups and a fortune 10 company within the past decade. I appreciate Vercel as a company too; I have no hate towards them but the NextJS 13 release almost made me quit web development. Svelte is an absolute love language to the web and a direction for healing the…

[deleted]

Re: Tenets

#129

Post by Charon77 »

nine_k wrote: post #70
blowski wrote: 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.

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…

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.

Re: Tenets

#130

Post by noahtallen »

mhh__ wrote: post #112
nonethewiser wrote: post #28

Earlier quoted context omitted.

It’s meaningless.

That's a good thing, we should embrace it more — we should be more driven by gut feelings than "objective" bullshit, that's how you end up with nonsense like megabytes of JS going down the wire in the first place.

I halfway agree with the first part, and I like the statement by the maintainers.

But, I think other libraries have done this too. React is a great example. It prioritized making the reactivity model really strong, and everything else is less important. (Like performance or bundle size.) To the extent that the official solution to performance issues is writing a compiler for the library to auto-optimize everything, because they don’t want to compromise on the reactivity model itself.

To me, that feels like a subjective choice, going more off vibes than certain metrics. (Not making a value judgement, just explaining what I’ve heard at conferences.)

In other words, I don’t think “objective BS” got us into this place. Shops which care a lot about performance will have “performance budgets” for things like TTFB or time to reactive. It’s a more objective approach that tries to minimize lots of MB going over the wire.

Post reply on HN