Hacker News Reader

Comment by bradchris | Hacker News Reader

Wow, just learned of Svelte from this. After reading their explanatory blog post and coming upon this blurb:

  That all changed with the advent of hooks [React and Vue], 
  which handle state in a very different fashion. Many 
  frameworks started experimenting with their own 
  implementations of hooks, but we quickly concluded it 
  wasn't a direction we wanted to go in 
  ...
  We can just use the language. Updating some count value — and 
  all the things that depend on it — should be as simple as 
  this:

    count += 1;

That's super exciting to me, as it puts the emphasis back on solving the task at hand and instead of framework nuances around state management. Will definitely be keeping my eyes on it.

https://svelte.dev/blog/svelte-3-rethinking-reactivity

View on HN

Svelte seems promising. I think it's a natural evolution from what I think is an over focus on FP and purity in React, to a more natural and intuitive DX without significant drawbacks.

Svelte does have an irritating wart IMO, citing their tutorial:

     Because Svelte's reactivity is triggered by assignments, using array 
     methods like push and splice won't automatically cause updates.

So for reference types that are mutated in place you need to do something like:

     numbers.push(numbers.length + 1);
     numbers = numbers;

Or:

     numbers = [...numbers, numbers.length + 1];

This looks like a leaky abstraction to me since it forces the developer to work according to the implementation details. Don't know how easy it would be to fix this.

I'm a huge fan of persistent data structures such as those implemented by immutable.js. The "normal" way that I would update an immutable.js List is just:

numbers = numbers.push(numbers.length + 1);

Maybe it's just a coincidence, but Svelte seems awfully congruent with the pure FP way of doing things.

To be fair, React has the same "wart". React is not guaranteed to work properly if you do:

  numbers = this.state.numbers;
  numbers.push(numbers.length + 1);
  this.setState({ numbers: numbers });

React docs here: https://reactjs.org/tutorial/tutorial.html#why-immutability-...

There's no good way around it without doing deep equality checks everywhere which is not reasonable.

Since Svelte is a compiler I was thinking they could wrap the exported variables in an observable of some sort and make any method call on the reference variable trigger a value update behind the scenes. I have now idea how costly/complex that would be though.

Also, maybe it's a conscious choice and they want to make any data update explicit with reassignment.

FWIW, MobX lets you mutate state in the same way. It does require you to make use of its observer/observable functions to make things reactive, but in general it works amazingly well. I strongly urge everyone to try it!

Agreed. I feel so weird seeing everyone messing around with hooks while all the time I've been using what feels to me like a much simpler better solution.

If you know React, look at the "Ten minute introduction to MobX and React" to see if it's for you. https://mobx.js.org/getting-started.html

MobX is great. It's even better when you remove the virtual dom and rely only in its internal dependency tracking:

https://github.com/ryansolid/mobx-jsx

Huh, interesting! I’ll have to try this out, thanks

Yeah Svelte is the next thing. Backbone and Angular were great, but then came Vue and React. Vue and React were great, but then came Svelte. It's:

- Simpler. You change values with `=` not some method call.

- Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time

- Smaller, since Svelte's output doesn't include Svelte.

Svelte is just a web framework, React is a software framework.

Then there's the missing Typescript support...

That's what happens when you create your own template syntax...again.

I'll continue to use React so I can simply use Typescript for my components, not some random syntax.

My styles are typed, my components are typed, my state is typed. Why would I ever go back?

> That's what happens when you create your own template syntax...again.

> I'll continue to use React

React also created it's own syntax. Svelte's syntax looks more similar to preceding work than React's syntax did.

JSX is syntactic sugar for function calls, but they are still just JS functions. You don't even have to use JSX.

Templates are 5 steps backwards, Svelte overall is a leap backwards.

Familiarity != simplicity.

The only thing I'd use Svelte for is for simple websites, but oh no you can't because it requires JS...

It seems like you're splitting hairs. React had a new syntax. Svelte has a new syntax too, albeit a familiar one.

You can call Svelte's syntax 'templates' if you want, but if you do, you should call JSX a 'template' syntax too. You seem to be saying templates are bad, which is fine, but a vdom and a compiler are both sufficiently different from, say, mustache templates and you seem to be favoring React for no technical reason.

> Familiarity != simplicity.

Sure. But you literally just said:

> That's what happens when you create your own template syntax...again.

Which seems to indicate you preferred familiarity.

I'm not really sure what your argument is except pointing out that you prefer React. OK.

JSX is not a template syntax. JSX is entirely optional, it's just syntactic sugar for function calls.

JSX is simply a way to write JavaScript that looks like HTML.

I know when I develop in React there's no magic. I know JSX are just functions, everything else in the code is as is.

> I know when I develop in React there's no magic.

That's the biggest misstatement of the day. ️ We understand that you prefer React, but this is utter...

I honestly don't care what you think, I explained my position.

I'll continue to use the one framework that supports typing styles, components, and state.

I'll continue to use the one framework that can bridge to every major desktop and mobile OS's native UI.

I'll continue to use the one framework backed by both Facebook and Microsoft.

I'll continue to use simple JS functions to build every part of my app.

You can use Svelte, lol.

Oh and don't use "we", you're one person.

Svelte also doesn't support anything like rollbar/sentry. Some exceptions won't trigger the error handler in sapper, so your app just freezes.

https://stefankrause.net/js-frameworks-benchmark8/table.html

Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity.

InfernoJS is massively faster than Svelte or Preact (the benchmark author had to do some rather convoluted re-writes of vanillaJS over the years to keep ahead) and it uses a virtual DOM, but has a few optimizations that React doesn't have or can't use due to its external API.

stdweb is the real thing to keep your eye on as it seems to show that WASM can be every fast. They still haven't gotten the vanilla benchmark up to the same speed.

https://stefankrause.net/js-frameworks-benchmark8/table.html

React's Fibers do some cool batching behind the scenes which means that large updates (especially constant ones like animations) don't have large negative impacts on user interaction. I doubt this would be possible without a vdom or something very similar to track all changes before deciding batches and update priority.

Also, remember that vdoms have gotten a lot more efficient too. Newer ones can do things like re-use existing sub-trees or recycle vdom objects (they can also recycle the associated real DOM nodes too). Preventing all that extra garbage goes a huge way toward keeping those vdoms efficient.

As to svelte in particular, you aren't "just using an equals". It actually compiles behind the scenes into a completely different set of reactive code. This gets at my biggest issue with such frameworks. Their abstractions aren't free. I have to learn their proprietary syntax and markup. I then have to learn how their compiler works behind the scenes when its time to debug the code I wrote. When I compile a React-style component into ES7 and run it in the brower, I have to deal with webpack for imports and I have to understand that JSX is really just JS functions. Otherwise, what I wrote is what I'll see.

https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.m...

This statement makes no sense:

> I have to learn their proprietary syntax and markup.

One of Svelte's raison d'etre is to "use the language" and err on less proprietary syntax / api / markup. Of the big three (not including Svelte), Svelte uses far less proprietary syntax, boilerplate, and API coverage. It errs on using as much native JS, CSS, and HTML as possible.

React has one and only one syntactic conceit which is JSX. Truth be told, that is based on a subset of the now deprecated e4x standard.

Let's look at Svelte's special syntax going over the docs. Everything mentioned here is NOT part of either the HTML or JS spec.

* Uppercase HTML is special (I really don't understand this one as this seems like the perfect opportunity to go all-in on web components)

* Interpolation using curly braces

* magical $$props object

* custom if..else..end syntax

* multiple variants of the custom loop syntax

* custom await, promise, and handler syntax

* custom HTML escape syntax

* custom debugger syntax

* custom element directive syntax

* tons of stuff using the element directive syntax (especially events and data binding)

* 4 non-standard pseudo-DOM events

* magical <slot> (lowercase) HTML element

* magical <svelte> (lowercase) HTML element

* magical $: syntax for binding updates

That's a ton of magic and doesn't include all the magical code generated to wire everything together. That wouldn't be important except that you can't really avoid it. In React, I can just step over library calls, but since there's no Svelte library, I have to step through the spaghetti it creates from my code (spaghetti because efficient machine-generated code is always spaghetti).

> https://stefankrause.net/js-frameworks-benchmark8/table.html

The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's.

https://krausest.github.io/js-framework-benchmark/current.ht...

Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0)

    Vanilla JS  1.04 (5.8% faster than Inferno)
    Inferno JS  1.10 (14.5% faster than Svelte)
    Svelte  JS  1.26 (12.6% faster than Preact)
    Preact  JS  1.42 (22% faster than React)

Total Size isn't that different either. That's an 11% payload difference between Inferno and Svelte and a less than 5% difference with Preact and Svelte. This isn't surprising since Preact is about 9kb unzipped (less than 4k zipped) and Inferno is about 21kb unzipped (less than 9k zipped).

    Vanilla JS  144kb
    Inferno JS  163kb
    Svelte  JS  146kb
    Preact  JS  153kb

Maximum memory difference between Svelte and Inferno is negligible too at only 9%. I'd argue that memory usage for any of these will be dwarfed by actual data and the DOM itself. Preact memory usage is interesting as it uses more than Inferno despite not having to diff against a vdom.

    Vanilla JS  3.3mb
    Inferno JS  4.8mb
    Svelte  JS  4.4mb
    Preact  JS  7.5mb

Startup time (parse to first load) is also completely unimportant with Svelte at about 1.2ms faster than Inferno, but 1ms slower than Preact (which even beats out the fastest vanillaJS version).

    Vanilla JS  20.3ms
    Inferno JS  21.6ms
    Svelte  JS  20.4ms
    Preact  JS  19.4ms

Even the pessimistic responsiveness isn't very different with svelte being about 8% faster than Preact or Inferno.

    Vanilla JS  1882ms
    Inferno JS  2033ms
    Svelte  JS  1883ms
    Preact  JS  2031ms

Inferno and Preact both have access to the wide support of the React ecosystem and tooling. Inferno is faster overall while not being particularly worse in any single area and better in others compared to Svelte.

Why would I want to choose Svelte?

Your total size numbers are almost entirely dominated by Bootstrap and a font, which are the same for all the tests (and not something that would be used on a site where payload size matters). Svelte's JS output, gzipped, is about 40% smaller than Preact and 65% smaller than Inferno.

Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.

With only 20-ish milliseconds to load, parse, and execute, the size difference disappears into the noise and is irrelevant. In addition, that difference definitely does NOT scale. As you add more components, the ration of component to framework becomes larger and larger as the internal wiring is used over and over again. All those things in the framework have to be re-created quite often in svelte. Even if Svelte could fit all its component changes into the same area as a React-style component (which I doubt), that extra 9 or 21kb would still disappear into irrelevance.

The biennial JS framework migration makes me glad to be in ClojureScript world, where it's a little more static (in a good way). Well, perhaps thats a function of its smaller developer base. ClojureScript + Re-frame + GraphQL subscriptions (Hasura) is the most fun combination I've used in a while. I hope nothing 'better' takes the CLJS market anytime soon.

I implemented a similar feature in the Blop language, but by simply using a Proxy

https://github.com/batiste/blop-language

Not sure why they claim proxies are complicated... I found it was a piece of cake to implement a working library for state management using a Proxy.

Svelte is great but IMO it has some weird dev ergonomics.

Unfortunately even though it is written in Typescript, it doesn't actually support Typescript, which makes it a no-goer for any serious work.

Reply on news.ycombinator.com