3 ms·

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 agains

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 :)
daliusd 7y ago
We are not stuck here. Check out realworld app.
jf22 7y ago
And bundle size always comes first for some reason... This new Bladderbuster framework is amazing because it compiles to negative KB. It has zero features and is really slow but negative KB!
dsego 7y ago
There's a bunch of real-world examples on the svelte website: https://svelte.dev/examples https://svelte.dev/examples.

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 :)

daliusd 7y ago

We are not stuck here. Check out realworld app.

jf22 7y ago

And bundle size always comes first for some reason... This new Bladderbuster framework is amazing because it compiles to negative KB. It has zero features and is really slow but negative KB!

dsego 7y ago

There's a bunch of real-world examples on the svelte website: https://svelte.dev/examples https://svelte.dev/examples.