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

Introduction to Svelte

daveceddia.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Introduction to Svelte

#101

Post by hajile »

daliusd wrote: post #93
hajile wrote: post #50

Earlier quoted context omitted.

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…

Either I have completely misunderstood you or you are simply wrong. It looks like you are implying that vdom is magical solution to long lists and svelte should have problem here. While in real world we have this: https://svelte.dev/repl/f78ddd84a1a540a9a40512df39ef751b?ver...

Like most other scrollers, the svelte one tries to only show the elements on screen plus a couple above and below to keep up the illusion. The Google article makes it very clear that top performance requires re-using DOM nodes.

In that very simplistic example, there are only 4 nodes to each list, so creating and destroying them doesn't matter. I have a scroller in a business app where each item has a few hundred DOM nodes. Create and destroy them constantly and you'll definitely notice on a desktop and performance will crawl on a mobile device.

Instead, you want to save those DOM nodes in a cache and re-use them. In order to do this though, you must know what parts are default and what parts have been modified by their previous user. A vdom does this automatically, but the cost for Svelte to calculate which of the hundreds of properties have changed is too big, so they just throw it away and make another.

An even better optimization would be where each list item has the same node structure and only text or images change. I believe Svelte can handle this case. Unfortunately a lot of lists are slightly irregular in real-world applications. I work with these kinds of lists a lot and a vdom keeps it smoother than all the other libraries we've looked at.

Re: Introduction to Svelte

#102

Post by daliusd »

hajile wrote: post #101
daliusd wrote: post #93

Earlier quoted context omitted.

Either I have completely misunderstood you or you are simply wrong. It looks like you are implying that vdom is magical solution to long lists and svelte should have problem here. While in real world we have this: https://svelte.dev/repl/f78ddd84a1a540a9a40512df39ef751b?ver...

Like most other scrollers, the svelte one tries to only show the elements on screen plus a couple above and below to keep up the illusion. The Google article makes it very clear that top performance requires re-using DOM nodes. In that very simplistic example, there are only 4 nodes to each list, so creating and destroying them doesn't matter. I have a scroller in a business app where each item has a few hundred DOM…

I don't see what stops you adding caching in Svelte for virtual lists.

Re: Introduction to Svelte

#103

Post by daliusd »

Chyzwar wrote: post #97
daliusd wrote: post #83

Earlier quoted context omitted.

> I can interact with it using whatever JS libraries I prefer. Could you give an example with JSX where templating will not cut? > JSX components are functions or classes which are trivially composable. This is framework's feature IMHO not language's. > I can type functions and classes with typescript unlike string templates. Situation where types are important in other frameworks is JS part not templates part. Could…

> Situation where types are important in other frameworks is JS part not templates part. Could you give an example where typing is import purely in component's return value? You will lose type-safety when composing components in template-based frameworks. It is jsx part where types are most important. Instead of getting runtime errors because you passed wrong props you get instant feedback from tsserver and compile e…

I have not checked any typescript implementation in svelte but I think this case can be done. The only special case being for cycle. *

* I use React with typescript mainly and I understand what you are referring to.

Re: Introduction to Svelte

#104

Post by shortercode »

hajile wrote: post #50
rich_harris wrote: post #29

Earlier quoted context omitted.

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…

Last time I tried keeping a collection of simple DOM nodes to "recycle" my perf tests showed it was slower than just creating new nodes. So I wouldn't necessarily consider this an optimisation, although memory use might be better.

Re: Introduction to Svelte

#105

Post by sktrdie »

olooney wrote: post #59
sktrdie wrote: post #37

I like reading scientific papers and most examples sections provide rich and intricate outlines of real-life use-cases where the idea can be experimented against. These examples usually involve quite complicated scenarios that "put the idea to the test". One that I recently read involved a solution to the "Challenge Problem" [1] (simulating the movement of a rover) which involves lots of interesting properties and al…

Todo apps are used as front-end examples for the same reason the factorial function is used to explain recursion: it's simple, it's intuitive, but it exercises what you need without dragging in a lot of incidental complexity. To demo or teach a front-end framework, you need to show: 1. How data gets rendered to the DOM 2. How collections are handled 3. How events are registered and handled 4. How the DOM is updated w…

I disagree. Those things are already available in pure library-less and framework-less code. What frameworks should provide is a solution at scale (i) as complexity increases, (ii) whether code is more maintainable or not and (iii) also I guess how easy it is to "fix" as bugs are discovered.

A todo-list gives you pretty much 0 insight into almost any of these facets. Let's be honest here, it's a "hello world" cheap demo to quickly showcase: "here's how my new framework works" and you can quickly understand it.

But you have no way of understanding whether those framework decisions actually work at scale. More complex examples are a good thing, not a bad thing :)

Re: Introduction to Svelte

#106

Post by hajile »

shortercode wrote: post #104
hajile wrote: post #50

Earlier quoted context omitted.

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…

Last time I tried keeping a collection of simple DOM nodes to "recycle" my perf tests showed it was slower than just creating new nodes. So I wouldn't necessarily consider this an optimisation, although memory use might be better.

It depends on how you recycle them I guess. One of Inferno's biggest optimizations (according to its creator) is the reuse of DOM nodes and vdom fragments. To my knowledge, it's still the fastest vdom implementation around.

Re: Introduction to Svelte

#107

Post by hajile »

daliusd wrote: post #102
hajile wrote: post #101

Earlier quoted context omitted.

Like most other scrollers, the svelte one tries to only show the elements on screen plus a couple above and below to keep up the illusion. The Google article makes it very clear that top performance requires re-using DOM nodes. In that very simplistic example, there are only 4 nodes to each list, so creating and destroying them doesn't matter. I have a scroller in a business app where each item has a few hundred DOM…

I don't see what stops you adding caching in Svelte for virtual lists.

Imagine you add a few attributes, some properties, and a couple event listeners to a node. In order to reuse the node, you have to reset it to factory settings.

How would Svelte know what things had been changed when looking at a node saved in a cache?

If it has to check every property, the cost to check will exceed the cost to create new. If it saves a list of changes, it's essentially created a vdom anyway.

Re: Introduction to Svelte

#108

Post by sullyj3 »

Zelphyr wrote: 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…

> My point is this: if all these frameworks were so great, why do we keep running to the latest new one?

If last years processors were so great...

If steam engines were so great...

If the wheel was so great...

Honestly I don't even know why we bothered inventing fire

Re: Introduction to Svelte

#109

Post by lioeters »

Zelphyr wrote: post #52
jacobedawson wrote: post #45

Earlier quoted context omitted.

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

A somewhat apples-to-oranges comparison I know but; 277B: Test document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!')

Omitting html, head, and body tags is allowed by HTML specs, and the script tag's default type is "text/javascript". So it could be further simplified to:

  Test
  
  
  document.addEventListener('DOMContentLoaded',
    () => document.getElementById('howdy').innerHTML = 'Hello world!'
  )
Edit: formatting

Re: Introduction to Svelte

#110

Post by hajile »

gactleaks wrote: post #80
hajile wrote: 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…

You’re welcome :) There’s more discussion here: https://mobile.twitter.com/Shub7241/status/11570049077753241... .

When discussing structural changes, it seems like lifting constant fragments a compile time wasn't discussed. There's a Babel React optimizer to do exactly this. Lift those to their own functions. Since those functions don't take any props or state, their values are cached almost indefinitely.
Post reply on HN