Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

181–186 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#181

Is the frustration meter shown in the talk video part of that original benchmark? Or is it something we could run on top of any page? I had a search around, but didn't find anything.

https://github.com/sw-yx/async-render-toolbox https://github.com/facebook/react/tree/master/fixtures/unsta...

Thank you so much!

Re: Svelte 3: Rethinking Reactivity

#185

Nice handling of reactivity - I think this should already be in language as well. I'm not sure I like this single components approach and embedding JS in HTML. The problem with this is that it's too frameworkish. The big benefit of JSX/React rendering is that it's composable and declarative (as it's just functions), but it's also simple to get - render just returns wanted structure, given the state and you can use si…

Check out my library DOM Expressions(https://github.com/ryansolid/dom-expressions#readme) It's almost exactly what you are talking about. The libraries I've written on top (Solid.js, MobX JSX, and KO JSX) are among the fastest on the JS Frameworks Benchmark(https://krausest.github.io/js-framework-benchmark/current.ht...). The future is already here.

Re: Svelte 3: Rethinking Reactivity

#186
post #88

Earlier quoted context omitted.

Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.

Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code

Yeah I don't know. More noise sure but I fear Svelte just misses the point. I'd write a rebuttal but I sort of already have: https://medium.com/@ryansolid/what-every-javascript-framewor...
Post reply on HN