Live data from Hacker News

Introduction to Svelte

daveceddia.com

41–50 of 116 posts

Re: Introduction to Svelte

#42
post #36

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way. That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now…

Some people are running around to new frameworks, but most are with React. Imo Vue and Svelte are going backwards.

Re: Introduction to Svelte

#43
post #36

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way. That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now…

tl;dr watch this fantastic intro to svelte talk by it's creator: https://www.youtube.com/watch?v=AdNJ3fydeao , it covers some of the growing pains of React that svelte addresses.

While it might look like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things... Off the top of my head (this timeline might not be right but it's how I went through it at least):

- Backbone got you away from jquery spaghetti, helped you actually manage your data & models. Often paired with Marionette to handle views (if you squint this is the precursor to components) and bring some order in that part of the app.

- Angular bundles backbone's data handling (services), marionette's orderly view separation (views, directives), but they made a fatal mistake in the apply/digest cycle and maybe encouraging a bit too much complexity. Angular is everything bundled together, with consistent usage/documentation/semantics, a familiar programming pattern (MVC), and a large corporate sponsor in Google it caught on like wildfire.

- Knockout sees Angular's MVC, laments it's complexity and focuses on MVVM -- simple binding of a model and a relatively simple reactive-where-necessary controller

- React comes along and suggests an even simpler world where the only first class citizen is components and everything else comes separate (this isn't necessarily new, there is an article out there comparing it to COM subsystems for windows). React is almost always used with react-router and some flux-pattern supporting data management lib -- these are also departures from how angular, backbone and knockout structured in-application communication (backbone was pure event bus, angular had the usual MVC methods, knockout was just callbacks -- if you have a handle to an observable when you change it things reload).

- Vue sees the complexity that React grew to (case in point: shouldComponentUpdate) and devises a much simpler subset along with a new way to handle reactivity -- using the `data` method of a vue component. Vue made a lot of decisions that helped it stay simple and small yet very productive and this is in large part thanks to React existing before hand.

- Svelte comes on the scene and realizes that truly optimal rendering could be achieved by just compiling away the excess and eschewing the virtual dom all together in most cases. No need to track all the structure if you compile the code with the updates necessary. Don't quote me on this but I think a whole host of things influenced this project -- smarter compilers, better type systems, the ideas around zero cost abstractions & doing more work at build time.

- Ember (formerly SproutCore) is actually an anomaly because it tries it's best to be both angular like (so large, and usable by large teams) and keeping up with the tech as it evolves (see: Glimmer, Octane). Ember also has some innovations, like Glimmer's VM-based approach -- turns out you can just ship binary data representing how to draw your components to the browser and skip a bunch of JS parsing, if you bring your own virtual machine that is optimized to draw the components.

As all this moves forward, there are ecosystem pieces like typescript that have gained tons of steam and changed how people are writing JS code these days.

Re: Introduction to Svelte

#44
post #24

Earlier quoted context omitted.

> Each second Svelte will completely destroy the tree from the previous second, and completely rebuild the tree for this second Here is the repl of the code you posted. https://svelte.dev/repl/1a70f2f38af94ed7ac8bd032feea52f9?ver... A Svelte component is mutable & manages the related DOM elements which are also mutable. In the conditional, the tree is re-rendered. Would React's diff algorithm be able to recycle the `…

I believe React recycles DOM nodes based on type (they decide some DOM nodes are faster to recreate instead of reuse depending on the circumstances) I may be wrong, but I believe hyperapp recycles both the physical DOM node and the attached vdom node together (IIRC, they mark reused vdom nodes as "recycled" instead of directly comparing objects so they don't have to construct as many new vdom objects). Preact kinda c…

[deleted]

Re: Introduction to Svelte

#45
post #38

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages." How is it nice that you have almost 30MB of code for something that prints "Hello World"? EDIT: For what it's worth, I don't fault Svelte for this necessarily. This is indicative of NPM bloat which is becoming rampant in my opinion.

To be fair, the Svelte bundle.js that you would actually serve to a browser is only 2.3kb. The 25mb is what the dev's computer has to store in its node_modules.

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages. Compare that to 204MB and 1017 packages for a fresh Create React App project."

Re: Introduction to Svelte

#46
post #36

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way. That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now…

> I actually heard a contractor say the other day, "five years ago everybody wanted Ember developers and now everybody wants React developers. I even have those old Ember clients coming back asking for developers to rewrite the Ember projects in React."

React came out a little over 6 years ago and Khan Academy started using it soon after. We haven't been itching to switch and, from what I've seen, there are _still_ a lot of people adopting it. Its model is working pretty well, generally.

I like that Svelte is taking a different approach. To move away from React will take something that's as big a switch as the jQuery+Backbone switch was when React came out.

Re: Introduction to Svelte

#47
post #38

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages." How is it nice that you have almost 30MB of code for something that prints "Hello World"? EDIT: For what it's worth, I don't fault Svelte for this necessarily. This is indicative of NPM bloat which is becoming rampant in my opinion.

LOL.

I am actually laughing here at this comment. 30 bloody meg.

Never mind ageism in tech, this sort of thing will give me a heart attack before I'm halfway through my career. :D

Re: Introduction to Svelte

#48
For those confused about the "29 MB": that's the size of the compiler itself.

A compiled Svelte app is tiny. Taking the TodoMVC demo app as an example:

React [1] : 289 KiB over the wire (decompresses to 1,255 KiB)

Svelte [2] : 28 KiB over the wire (decompresses to 41 KiB)

---

[1] http://todomvc.com/examples/react/

[2] https://github.com/sveltejs/svelte-todomvc

Re: Introduction to Svelte

#49
post #36

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way. That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now…

tl;dr watch this fantastic intro to svelte talk by it's creator: https://www.youtube.com/watch?v=AdNJ3fydeao , it covers some of the growing pains of React that svelte addresses. While it might look like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things... Off the top of my head (this timeline might not be…

This is literally the first time anyone has ever put together a cogent argument for why the framework du jour exists. Thank you!

I still personally feel like I can usually get more done with pure Javascript but, as I said in my original post, at least they appear to be headed in a better direction. I did a project in Vue last year and it didn't entirely suck. Unlike the nightmare that was an Angular project I did two years ago.

Re: Introduction to Svelte

#50
post #13

Earlier quoted context omitted.

The TL;DR is that Svelte overpromises. They can't possibly write code for every transformation combination as code size would grow exponentially (I'm not completely sure, but I think predicting transforms would involve the halting problem). (thanks to whoever bothered to do this writeup). https://github.com/gactjs/gact/blob/master/docs/long-live-th... EDIT: if anyone has proof this is not true, I'd love to hear their…

Svelte author here. That post overlooks a number of important points; I've responded here https://www.reddit.com/r/javascript/comments/ckpdxk/long_liv...

React is very far from the fastest vdom. It notably suffers from needing to work with non-DOM back-ends where a particular heuristic that is good in the DOM may either be useless or (worse) actively degrade performance. Preact, Snabbdom, or Inferno would probably be better points of comparison to Svelte's approach as they are much more optimized for the web.

DOM nodes can actually be recycled relatively easily. Cache the nodes by type then by class. Most recycled nodes would be a 100% match based on those two alone. If type and class match, then you have a super-high probability of dealing with old nodes for the same object, so few modifications are required. Most nodes without classes tend to have no attributes changed (,

, etc) so they will match as well. Store those nodes with their vdom attached and you will have a record of what has been modified so patching is fast.

This optimization exists in some vdom implementations and would make the case in question much faster. There also seems to be an implication that the diffing algorithm will bloat. If you look at React, the diffing algorithm is a very small part of the codebase.

This is hardly just an academic optimization though. It is the key to reducing overhead on long lists. With long lists of complex objects, you cannot rely on patching text values because there will undoubtedly be actual DOM differences. Rather than dooming the entire list to poor performance, you can recycle those nodes and retain most of the performance of a flyweight scroller where nodes are all identical.

https://developers.google.com/web/updates/2016/07/infinite-s...

Post reply on HN