13 ms·

Introduction to Svelte

187 points by lobo_tuerto 7y ago

nailer 7y ago
I've been building something with Svelte 3 for about 6 months now. - As should be clear in the article, it's very easy to pick up. In the first couple of weeks I got compiler errors, and kept having to look at how props and binding worked in the tutorial, but now I just make components without having to really think about Svelte. - TS support is on the way (yaay) - I'd like to know more about server-side rendering on Lambda - ie, Sapper currently wants to use something persistent like Express, but that really shouldn't be necessary.
- TehShrike 7y ago
  I've used Svelte to generate static HTML, it's pretty great at it. If you pass generate: 'ssr' to the compile function https://svelte.dev/docs#svelte_compile https://svelte.dev/docs#svelte_compile you get JS that can be used to generate static HTML in a Lambda or anywhere else
- wirahx 7y ago
  Sapper can generate static html for lambda or anything else i f you run `npm run export`. In fact the ideal way to use Sapper is without express/polka.
  - nailer 7y ago
    Hah brill. It might just be the tutorials, which seem focused on using express or something with express-like middleware. I'll do some further investigation. Thanks.
dccoolgai 7y ago
This looks much more germane to the Web than the other frameworks du jour. Will be interesting to see how it develops, but this was a pretty interesting look at how it works.
- nailer 7y ago
  Ins't /Svelte/ the framework du jour? :)
  - azangru 7y ago
    Doesn't du jour imply that it's the go-to framework of the day? Surely, that would be React :-)
    - bbmario 7y ago
      That's so last week.
    - sooheon 7y ago
      I guess if it's getting a good response on HN along the lines of "it's better than the other ones," it's close? :)
    - nailer 7y ago
      JQuery was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day. Backbone and Angular were a completely different way of looking at things with a huge advantage. They got popular and became the go-to tool of the day. React was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day. Svelte is a completely different way of looking at things with a huge advantage.
Doctor_Fegg 7y ago
> Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages "Only".
- nailer 7y ago
  That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
  - sealjam 7y ago
    I've never heard it described like that but you're right. Interesting counter point.
    - huzaif 7y ago
      Even though these are compile/build time requirements, their size ends up slowing down CI/CD process. Our ondemand cloud build servers download the code, restore nuget packages and download node modules. Most of the build time is spent downloading. Compiling generally takes an order of magnitude less time compared to those 2 steps. This especially effects scenarios where end-to-end testing can only be done in a staging environment due to complexity of the product.
      - wirahx 7y ago
        Sounds like you need some caching. I have three large production svelte projects and the entire checkout and npm install (Cache then update) process takes three seconds on CircleCI.
  - asdkhadsj 7y ago
    It can matter though; fwiw. I love Rust, but my "node_modules" in Rust is absolutely huge. Not a problem on Desktop, but because I am full-time Rust these days my next laptops have to have lots of storage. Gone are the days where I can have a small SSD in my laptop. Fwiw though, even a 250MB node_modules would pale in comparison to my Rust version lol.
gedy 7y ago
I loved Svelte a few years back and still think it's a nice framework with cool ideas. However, a big issue for me using it at a company is that testing (especially unit testing) seems to be an afterthought. This has made it a non-starter for using it with multiple teams working on same code base. Maybe it's changed with Svelte 3 but a library I wrote for it wasn't clear how to test. (Edit sounds same: https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do-testing-svelte-apps https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do-test...) JS libraries sometimes take a non-presciptive approach of "test however you want!", But roll your own testing for a UI framework really limits adoption and enthusiasm at larger companies.
- tobr 7y ago
  Did you look at svelte-testing-library[1]? It looks like a good option to me, but I haven’t tried it. 1: https://github.com/testing-library/svelte-testing-library https://github.com/testing-library/svelte-testing-library
  - gedy 7y ago
    Ah that looks nice, will try it out, thank you!
- rich_harris 7y ago
  Honestly, the biggest blocker to us having a 'blessed' story around testing isn't figuring out how to test (which is relatively straightforward), it's figuring out what to test. Do you really need to test that `<p>Hello {name}!</p>` results in `<p>Hello world!</p>` if `name = world`? Because then you're really just testing that the framework itself isn't buggy, rather than anything to do with your app. Which isn't to dismiss the concern — just to offer an explanation as to why it hasn't been our top priority so far.
  - gedy 7y ago
    > "Because then you're really just testing that the framework itself isn't buggy" Not in all cases, I maintain some component libraries (mostly React, but a Svelte one too) and ensuring a standard component interface is pretty valuable imho. Enzyme as an example lets you test React components, props, state, etc in isolation but is not very prescriptive about what you 'should' test.
daoxid 7y ago
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
- hajile 7y ago
  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-the-virtual-dom.md 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 counterargument.
  - daoxid 7y ago
    I guess whether a structural comparison (VDOM) or a value comparison (Svelte) is more efficient really depends on the concrete use-case. For example, even changing a single value in a big list requires the whole VDOM to be recreated, but should be very efficient in Svelte as it can directly modify the specific DOM node. On the other hand, as pointed out in the article you linked, if changing a value affects a large part of the DOM, but does not actually change that much, then value-comparing frameworks (e.g. Svelte) probably do a lot of unnecessary work compared to VDOM-based approaches (intuitively I would think that this case does not occur that often).
    - hajile 7y ago
      You don't have to recreate the entire vdom if only one part changes. You need only recreate that component and its children (something like React's PureComponent or shouldComponentUpdate optimizations can prevent the worst cases without too much trouble). Changing branches in a component is extremely common in code I write (very large business application with lots of rules). Another important optimization is caching and re-using DOM nodes. With a vdom, you know exactly which properties and attributes differ from the default node. To reuse a node you need only update these properties to their new values or restore their original values. Without that tracking, it would be computationally cheaper to just create a new node. One important example of this is our use of flyweight scroller patterns in lists. The content of the sub-tree changes, but most of the sub-components stay the same, so a vdom could keep most of the dom nodes around.
CREwert 7y ago
"Theres a new JS framework, it must be Tuesday".
- jedisct1 7y ago
  Svelte is not exactly a new framework.
Zelphyr 7y ago
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 Vue is appearing to be greener than the others. Is Svelte where everyone will go next? My point is this: if all these frameworks were so great, why do we keep running to the latest new one? 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." Maybe it really is turtles all the way down...
- deleted 7y ago
  [deleted]
- s_y_n_t_a_x 7y ago
  Some people are running around to new frameworks, but most are with React. Imo Vue and Svelte are going backwards.
  - wishinghand 7y ago
    > Imo Vue and Svelte are going backwards Big claims need big evidence.
    - s_y_n_t_a_x 7y ago
      I said in my opinion. I think going from JSX to templates is a bad idea and going back to where we were.
      - daliusd 7y ago
        What exactly JSX offers what templating does not?
sktrdie 7y ago
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 allows one's idea or framework (or whatever) to really battle test the grounds with reality. On the web however it's different... we're somehow stuck with todo-lists. 1. https://mdetools.github.io/mdetools18/challengeproblem.html https://mdetools.github.io/mdetools18/challengeproblem.html
- olooney 7y ago
  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 when data are changed 5. How form inputs are represented The easiest thing to do is to show an array getting rendered as a list, then add click handlers which change the list somehow, which naturally segues into showing how the DOM is changed. Adding new items or deleting items also answer important questions about how exactly collections of data are mapped to collections of elements and how updates are happened. Finally, no demo of a front-end framework can be considered complete unless it addresses how form input elements work; adding functionality to add a new item or update the text of an existing item is an obvious way to demonstrate this.
  - sktrdie 7y ago
    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 :)
Zelphyr 7y ago
"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.
- bbmario 7y ago
  Is it 29MB for production dependencies, or dev and prod?
  - wishinghand 7y ago
    Just dev. Production size is minuscule.
- jacobedawson 7y ago
  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."
  - Zelphyr 7y ago
    A somewhat apples-to-oranges comparison I know but; 277B: <!DOCTYPE html> <html lang="en"> <head> <title>Test</title> </head> <body> <div id="howdy"></div> <script type="text/javascript"> document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!') </script> </body> </html>
    - lioeters 7y ago
      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: <title>Test</title> <div id="howdy"></div> <script> document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!' ) </script> Edit: formatting
playpause 7y ago
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/ http://todomvc.com/examples/react/ [2] https://github.com/sveltejs/svelte-todomvc https://github.com/sveltejs/svelte-todomvc
- acemarke 7y ago
  FWIW, that React demo should not be used as a network perf comparison in any way: - It's using an ancient version of React (0.13.3) - It's a debug build of "React with addons", not a minified prod build - It appears to include `JSXTransformer.js` as a separate script to handle in-browser JSX compilation If you were to redo this using a modern version of React and a standard CRA build, I guarantee it would be _much_ smaller. edit Just for kicks, I did a quick search and dug up a pre-existing React "TodoMVC" app based on CRA ( https://github.com/ChrisWiles/React-todoMVC https://github.com/ChrisWiles/React-todoMVC ). It's 3 years old, but it was trivial to bump the requirements up to the latest versions of React and react-scripts. From there, running `yarn build` says that: File sizes after gzip: 39.22 KB build\static\js\2.3ec0f98b.chunk.js 2.14 KB build\static\js\main.4514f0a8.chunk.js 1.73 KB build\static\css\2.bc2ff3bb.chunk.css 782 B build\static\js\runtime~main.0ff4d30b.js The actual sizes on disk are: 2.3ec0f98b.chunk.js : 128435b main.4514f0a8.chunk.js: 7259b 2.bc2ff3bb.chunk.css: 5423b runtime~main.0ff4d30b.js: 1577b So yeah, Svelte is certainly going to result in much smaller bundles than a React app, but you have to use a legitimate fair production comparison.
  - hajile 7y ago
    Looks like Preact comes in at 6K (compresses to 4.7K). That's pretty interesting when you realize that Preact generally about as fast or faster than Svelte in a lot of benchmarks. https://github.com/developit/preact-todomvc https://github.com/developit/preact-todomvc https://medium.com/@ajmeyghani/javascript-frameworks-performance-comparison-c566d19ab65b https://medium.com/@ajmeyghani/javascript-frameworks-perform... That said, I don't know that 6K vs 40K is particularly significant. For small apps, it disappears into the noise compared to ads, images, video, trackers, etc. For large apps, the framework starts to make less and less of a total percentage of the total app and often slides into insignificance on that side as well.
writepub 7y ago
We need someone to take Svelte on a test drive for something more complex than a to-do list. I'm assuming the results will be favorable to svelte, but please blog after said exercise. The un-ending list of blogs and tutorials on to-do lists with svelte are certainly plentiful, repetitive, and not particularly convincing
- Vinnl 7y ago
  While I'm still in the wait-and-see stage of evaluating Svelte, Pinafore [1] is a relatively big app build using it. It also identified highlights to some extent why wait-and-see is still a good approach for non-spare time apps: it's still on v2 because the upgrade to v3 was rather significant. It's probably good to let the API and the tooling stabilise some more, especially since the latter includes a full-blown compiler and hence also has to replace Babel, as far as I'm aware (which is not too far) - and TypeScript, for that matter. [1] https://pinafore.social/ https://pinafore.social/
- theprotocol 7y ago
  FYI I've selected Svelte for an enterprise project and after using it for some time, it seems to have some pretty big issues. I would honestly call the current release a beta version. In particular, there is a _lot_ of flakiness with reactivity and because reactive things are magical in Svelte, it's very hard to diagnose and correct such issues. Reactive code becomes spaghetti fairly quickly once you start adding logic to prevent it breaking. Those neat out-of-the-box transitions completely break unmounting/remounting as would be the case with, say, changing "pages" (using a router). If there's any transition still going on, the unmount will fail and yet the replacement component will be mounted, resulting in a frankenpage. It's also maybe _too_ declarative in the sense that certain things that are easy to do imperatively require you to coerce Svelte to achieve them. You sometimes find yourself deliberately trying to fool Svelte into doing an update. __ But do I regret choosing it? Not really. All frameworks have flaws. IMHO: Angular is a convoluted spaghetti of nonstandardness, React has its head on backwards with JSX, Vue has too many quirks... I'm partial to riot.js which has just been updated to v4, but I have yet to try the latest version.
sveit 7y ago
Mark Volkmann gave a great talk on Svelte[0]. [0]: https://www.youtube.com/watch?v=4_PTdJq-1rA https://www.youtube.com/watch?v=4_PTdJq-1rA
icemelt8 7y ago
After working with React now for a few years. I will now never learn any more JS frameworks. I think React is the best and I don't need anything more.
fiatjaf 7y ago
Doesn't work with Browserify. Please someone make it work with Browserify!

187 points by lobo_tuerto 7y ago

I've been building something with Svelte 3 for about 6 months now. - As should be clear in the article, it's very easy to pick up. In the first couple of weeks I got compiler errors, and kept having to look at how props and binding worked in the tutorial, but now I just make components without having to really think about Svelte. - TS support is on the way (yaay) - I'd like to know more about server-side rendering on Lambda - ie, Sapper currently wants to use something persistent like Express, but that really shouldn't be necessary.

TehShrike 7y ago
I've used Svelte to generate static HTML, it's pretty great at it. If you pass generate: 'ssr' to the compile function https://svelte.dev/docs#svelte_compile https://svelte.dev/docs#svelte_compile you get JS that can be used to generate static HTML in a Lambda or anywhere else
wirahx 7y ago
Sapper can generate static html for lambda or anything else i f you run `npm run export`. In fact the ideal way to use Sapper is without express/polka.
- nailer 7y ago
  Hah brill. It might just be the tutorials, which seem focused on using express or something with express-like middleware. I'll do some further investigation. Thanks.

dccoolgai 7y ago

This looks much more germane to the Web than the other frameworks du jour. Will be interesting to see how it develops, but this was a pretty interesting look at how it works.

nailer 7y ago
Ins't /Svelte/ the framework du jour? :)
- azangru 7y ago
  Doesn't du jour imply that it's the go-to framework of the day? Surely, that would be React :-)
  - bbmario 7y ago
    That's so last week.
  - sooheon 7y ago
    I guess if it's getting a good response on HN along the lines of "it's better than the other ones," it's close? :)
  - nailer 7y ago
    JQuery was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day. Backbone and Angular were a completely different way of looking at things with a huge advantage. They got popular and became the go-to tool of the day. React was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day. Svelte is a completely different way of looking at things with a huge advantage.

Doctor_Fegg 7y ago

> Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages "Only".

nailer 7y ago
That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
- sealjam 7y ago
  I've never heard it described like that but you're right. Interesting counter point.
  - huzaif 7y ago
    Even though these are compile/build time requirements, their size ends up slowing down CI/CD process. Our ondemand cloud build servers download the code, restore nuget packages and download node modules. Most of the build time is spent downloading. Compiling generally takes an order of magnitude less time compared to those 2 steps. This especially effects scenarios where end-to-end testing can only be done in a staging environment due to complexity of the product.
    - wirahx 7y ago
      Sounds like you need some caching. I have three large production svelte projects and the entire checkout and npm install (Cache then update) process takes three seconds on CircleCI.
- asdkhadsj 7y ago
  It can matter though; fwiw. I love Rust, but my "node_modules" in Rust is absolutely huge. Not a problem on Desktop, but because I am full-time Rust these days my next laptops have to have lots of storage. Gone are the days where I can have a small SSD in my laptop. Fwiw though, even a 250MB node_modules would pale in comparison to my Rust version lol.

gedy 7y ago

I loved Svelte a few years back and still think it's a nice framework with cool ideas. However, a big issue for me using it at a company is that testing (especially unit testing) seems to be an afterthought. This has made it a non-starter for using it with multiple teams working on same code base. Maybe it's changed with Svelte 3 but a library I wrote for it wasn't clear how to test. (Edit sounds same: https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do-testing-svelte-apps https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do-test...) JS libraries sometimes take a non-presciptive approach of "test however you want!", But roll your own testing for a UI framework really limits adoption and enthusiasm at larger companies.

tobr 7y ago
Did you look at svelte-testing-library[1]? It looks like a good option to me, but I haven’t tried it. 1: https://github.com/testing-library/svelte-testing-library https://github.com/testing-library/svelte-testing-library
- gedy 7y ago
  Ah that looks nice, will try it out, thank you!
rich_harris 7y ago
Honestly, the biggest blocker to us having a 'blessed' story around testing isn't figuring out how to test (which is relatively straightforward), it's figuring out what to test. Do you really need to test that `<p>Hello {name}!</p>` results in `<p>Hello world!</p>` if `name = world`? Because then you're really just testing that the framework itself isn't buggy, rather than anything to do with your app. Which isn't to dismiss the concern — just to offer an explanation as to why it hasn't been our top priority so far.
- gedy 7y ago
  > "Because then you're really just testing that the framework itself isn't buggy" Not in all cases, I maintain some component libraries (mostly React, but a Svelte one too) and ensuring a standard component interface is pretty valuable imho. Enzyme as an example lets you test React components, props, state, etc in isolation but is not very prescriptive about what you 'should' test.

daoxid 7y ago

The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?

hajile 7y ago
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-the-virtual-dom.md 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 counterargument.
- daoxid 7y ago
  I guess whether a structural comparison (VDOM) or a value comparison (Svelte) is more efficient really depends on the concrete use-case. For example, even changing a single value in a big list requires the whole VDOM to be recreated, but should be very efficient in Svelte as it can directly modify the specific DOM node. On the other hand, as pointed out in the article you linked, if changing a value affects a large part of the DOM, but does not actually change that much, then value-comparing frameworks (e.g. Svelte) probably do a lot of unnecessary work compared to VDOM-based approaches (intuitively I would think that this case does not occur that often).
  - hajile 7y ago
    You don't have to recreate the entire vdom if only one part changes. You need only recreate that component and its children (something like React's PureComponent or shouldComponentUpdate optimizations can prevent the worst cases without too much trouble). Changing branches in a component is extremely common in code I write (very large business application with lots of rules). Another important optimization is caching and re-using DOM nodes. With a vdom, you know exactly which properties and attributes differ from the default node. To reuse a node you need only update these properties to their new values or restore their original values. Without that tracking, it would be computationally cheaper to just create a new node. One important example of this is our use of flyweight scroller patterns in lists. The content of the sub-tree changes, but most of the sub-components stay the same, so a vdom could keep most of the dom nodes around.

CREwert 7y ago

"Theres a new JS framework, it must be Tuesday".

jedisct1 7y ago
Svelte is not exactly a new framework.

Zelphyr 7y ago

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 Vue is appearing to be greener than the others. Is Svelte where everyone will go next? My point is this: if all these frameworks were so great, why do we keep running to the latest new one? 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." Maybe it really is turtles all the way down...

deleted 7y ago
[deleted]
s_y_n_t_a_x 7y ago
Some people are running around to new frameworks, but most are with React. Imo Vue and Svelte are going backwards.
- wishinghand 7y ago
  > Imo Vue and Svelte are going backwards Big claims need big evidence.
  - s_y_n_t_a_x 7y ago
    I said in my opinion. I think going from JSX to templates is a bad idea and going back to where we were.
    - daliusd 7y ago
      What exactly JSX offers what templating does not?

sktrdie 7y ago

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 allows one's idea or framework (or whatever) to really battle test the grounds with reality. On the web however it's different... we're somehow stuck with todo-lists. 1. https://mdetools.github.io/mdetools18/challengeproblem.html https://mdetools.github.io/mdetools18/challengeproblem.html

olooney 7y ago
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 when data are changed 5. How form inputs are represented The easiest thing to do is to show an array getting rendered as a list, then add click handlers which change the list somehow, which naturally segues into showing how the DOM is changed. Adding new items or deleting items also answer important questions about how exactly collections of data are mapped to collections of elements and how updates are happened. Finally, no demo of a front-end framework can be considered complete unless it addresses how form input elements work; adding functionality to add a new item or update the text of an existing item is an obvious way to demonstrate this.
- sktrdie 7y ago
  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 :)

Zelphyr 7y ago

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

bbmario 7y ago
Is it 29MB for production dependencies, or dev and prod?
- wishinghand 7y ago
  Just dev. Production size is minuscule.
jacobedawson 7y ago
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."
- Zelphyr 7y ago
  A somewhat apples-to-oranges comparison I know but; 277B: <!DOCTYPE html> <html lang="en"> <head> <title>Test</title> </head> <body> <div id="howdy"></div> <script type="text/javascript"> document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!') </script> </body> </html>
  - lioeters 7y ago
    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: <title>Test</title> <div id="howdy"></div> <script> document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!' ) </script> Edit: formatting

playpause 7y ago

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/ http://todomvc.com/examples/react/ [2] https://github.com/sveltejs/svelte-todomvc https://github.com/sveltejs/svelte-todomvc

acemarke 7y ago
FWIW, that React demo should not be used as a network perf comparison in any way: - It's using an ancient version of React (0.13.3) - It's a debug build of "React with addons", not a minified prod build - It appears to include `JSXTransformer.js` as a separate script to handle in-browser JSX compilation If you were to redo this using a modern version of React and a standard CRA build, I guarantee it would be _much_ smaller. edit Just for kicks, I did a quick search and dug up a pre-existing React "TodoMVC" app based on CRA ( https://github.com/ChrisWiles/React-todoMVC https://github.com/ChrisWiles/React-todoMVC ). It's 3 years old, but it was trivial to bump the requirements up to the latest versions of React and react-scripts. From there, running `yarn build` says that: File sizes after gzip: 39.22 KB build\static\js\2.3ec0f98b.chunk.js 2.14 KB build\static\js\main.4514f0a8.chunk.js 1.73 KB build\static\css\2.bc2ff3bb.chunk.css 782 B build\static\js\runtime~main.0ff4d30b.js The actual sizes on disk are: 2.3ec0f98b.chunk.js : 128435b main.4514f0a8.chunk.js: 7259b 2.bc2ff3bb.chunk.css: 5423b runtime~main.0ff4d30b.js: 1577b So yeah, Svelte is certainly going to result in much smaller bundles than a React app, but you have to use a legitimate fair production comparison.
- hajile 7y ago
  Looks like Preact comes in at 6K (compresses to 4.7K). That's pretty interesting when you realize that Preact generally about as fast or faster than Svelte in a lot of benchmarks. https://github.com/developit/preact-todomvc https://github.com/developit/preact-todomvc https://medium.com/@ajmeyghani/javascript-frameworks-performance-comparison-c566d19ab65b https://medium.com/@ajmeyghani/javascript-frameworks-perform... That said, I don't know that 6K vs 40K is particularly significant. For small apps, it disappears into the noise compared to ads, images, video, trackers, etc. For large apps, the framework starts to make less and less of a total percentage of the total app and often slides into insignificance on that side as well.

writepub 7y ago

We need someone to take Svelte on a test drive for something more complex than a to-do list. I'm assuming the results will be favorable to svelte, but please blog after said exercise. The un-ending list of blogs and tutorials on to-do lists with svelte are certainly plentiful, repetitive, and not particularly convincing

Vinnl 7y ago
While I'm still in the wait-and-see stage of evaluating Svelte, Pinafore [1] is a relatively big app build using it. It also identified highlights to some extent why wait-and-see is still a good approach for non-spare time apps: it's still on v2 because the upgrade to v3 was rather significant. It's probably good to let the API and the tooling stabilise some more, especially since the latter includes a full-blown compiler and hence also has to replace Babel, as far as I'm aware (which is not too far) - and TypeScript, for that matter. [1] https://pinafore.social/ https://pinafore.social/
theprotocol 7y ago
FYI I've selected Svelte for an enterprise project and after using it for some time, it seems to have some pretty big issues. I would honestly call the current release a beta version. In particular, there is a _lot_ of flakiness with reactivity and because reactive things are magical in Svelte, it's very hard to diagnose and correct such issues. Reactive code becomes spaghetti fairly quickly once you start adding logic to prevent it breaking. Those neat out-of-the-box transitions completely break unmounting/remounting as would be the case with, say, changing "pages" (using a router). If there's any transition still going on, the unmount will fail and yet the replacement component will be mounted, resulting in a frankenpage. It's also maybe _too_ declarative in the sense that certain things that are easy to do imperatively require you to coerce Svelte to achieve them. You sometimes find yourself deliberately trying to fool Svelte into doing an update. __ But do I regret choosing it? Not really. All frameworks have flaws. IMHO: Angular is a convoluted spaghetti of nonstandardness, React has its head on backwards with JSX, Vue has too many quirks... I'm partial to riot.js which has just been updated to v4, but I have yet to try the latest version.

sveit 7y ago

Mark Volkmann gave a great talk on Svelte[0]. [0]: https://www.youtube.com/watch?v=4_PTdJq-1rA https://www.youtube.com/watch?v=4_PTdJq-1rA

icemelt8 7y ago

After working with React now for a few years. I will now never learn any more JS frameworks. I think React is the best and I don't need anything more.

fiatjaf 7y ago

Doesn't work with Browserify. Please someone make it work with Browserify!