4 ms·

> I decided to try and build a fairly standard To Do App that allows a user to add and delete items from the list. Isn't it enough of such really? These (micro

> I decided to try and build a fairly standard To Do App that allows a user to add and delete items from the list. Isn't it enough of such really? These (micro)apps which are actually single extracted screens of anything seriously larger can't help to decide about a stack. What about other aspects of real apps: user auth, undo, back-button action, rich forms, client-side error logging, permalinks, rendering/filtering user markup, uploading/attaching content, drag&drop, notifications, SEO, integration with other useful libs (e.g. bootstrap, highcharts, d3), app extensibility with customer views/plugins?

PretzelFisch 8y ago
I am not sure having all of that together in one demo would help or just be to much noise. It might be better to pull each feature in to its own isolated demo. That you can see how they are differ.
- imhoguy 8y ago
  Right, but real apps are such glued "noise". For isolated demos we already have countless todoapps on GH and snippets on StackOverflow or some JS Fiddles. Then when it comes to integration of a front-end framework in a real app with non trivial but common use case the one has to compare and learn the hard way by scouring forums or diving deep down into source. E.g. dynamic templates are discouraged in Vue, but customers would like to have a control over couple of loadable HTMLs without npm work - think of most CMS stuff. My point is that I came to this article with true intrest that the author made a real non-trivial application comparison, thus we could learn subtle gotchas and battlefield tactics. But then I got letdown it's another todoapp to compare basic syntax.
  - aidos 8y ago
    I’ve thought for a while that this would be an awesome community project for people to work on together. Pick a project and create it using a few different technologies. It would also help to demonstrate the best way of doing things in each framework because everyone would be competing to make their framework appear to be the most compelling choice.
    - mrunkel 8y ago
      Somebody else agrees with you.. https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld
      - aidos 8y ago
        Woohoooo! That's brilliant. Thanks.
- mrunkel 8y ago
  I posted this below, but I'll repost it here for better visibility. https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld This is a medium clone built in various frontend and backend technologies.
  - mrunkel 8y ago
    There is also this: http://todomvc.com/ http://todomvc.com/ A todo app written in many many frontend tech stacks.
    - bmarkovic 8y ago
      Except that, unlike realworld, this is about as useless (for proper comparison) as the OP app if not more.
EB66 8y ago
I agree with PretzelFisch. It's not necessary to delve into framework minutia and ALL possible use cases in order to get a feel for how the frameworks operate. The OP made a very wise decision by choosing to build a demo app that incorporated a list and child components. Lists with child components provide a very succinct encapsulation of the primary challenges that JS frameworks must manage. Managing state between parent and child, one-way or two-way binding with repeatable items, etc.

PretzelFisch 8y ago

I am not sure having all of that together in one demo would help or just be to much noise. It might be better to pull each feature in to its own isolated demo. That you can see how they are differ.

imhoguy 8y ago
Right, but real apps are such glued "noise". For isolated demos we already have countless todoapps on GH and snippets on StackOverflow or some JS Fiddles. Then when it comes to integration of a front-end framework in a real app with non trivial but common use case the one has to compare and learn the hard way by scouring forums or diving deep down into source. E.g. dynamic templates are discouraged in Vue, but customers would like to have a control over couple of loadable HTMLs without npm work - think of most CMS stuff. My point is that I came to this article with true intrest that the author made a real non-trivial application comparison, thus we could learn subtle gotchas and battlefield tactics. But then I got letdown it's another todoapp to compare basic syntax.
- aidos 8y ago
  I’ve thought for a while that this would be an awesome community project for people to work on together. Pick a project and create it using a few different technologies. It would also help to demonstrate the best way of doing things in each framework because everyone would be competing to make their framework appear to be the most compelling choice.
  - mrunkel 8y ago
    Somebody else agrees with you.. https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld
    - aidos 8y ago
      Woohoooo! That's brilliant. Thanks.
mrunkel 8y ago
I posted this below, but I'll repost it here for better visibility. https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld This is a medium clone built in various frontend and backend technologies.
- mrunkel 8y ago
  There is also this: http://todomvc.com/ http://todomvc.com/ A todo app written in many many frontend tech stacks.
  - bmarkovic 8y ago
    Except that, unlike realworld, this is about as useless (for proper comparison) as the OP app if not more.

EB66 8y ago

I agree with PretzelFisch. It's not necessary to delve into framework minutia and ALL possible use cases in order to get a feel for how the frameworks operate. The OP made a very wise decision by choosing to build a demo app that incorporated a list and child components. Lists with child components provide a very succinct encapsulation of the primary challenges that JS frameworks must manage. Managing state between parent and child, one-way or two-way binding with repeatable items, etc.