Another good guide to mvc with js is this one https://github.com/madhadron/mvc_for_the_web The neat thing is that it starts from scratch and adds things, like pub/sub, then models, controllers and so on.
Vanilla-todo: A case study on viable techniques for vanilla web development
31–40 of 154 posts
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#32I hope to leave productive feedback later.
I do hope people don't miss the point that I think OP was trying to be modest about. This study is not for or against frameworks, it is a detailed and informative reflection of the current state of client JavaScript.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#33I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…
However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#34Earlier quoted context omitted.
React has been stable since ~2015, and there are no signs of that changing.
I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it. Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase…
At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style.
If you feel like you need to upgrade then I think that on you, not the framework.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#35Earlier quoted context omitted.
React has been stable since ~2015, and there are no signs of that changing.
I would say that the React ecosystem as a whole is in constant flux, which is what really matters.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#36Earlier quoted context omitted.
I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#37Earlier quoted context omitted.
Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.
React has been stable since ~2015, and there are no signs of that changing.
While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#38Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#39I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#40I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…
Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.