<story><title>Vanilla-todo: A case study on viable techniques for vanilla web development</title><url>https://github.com/morris/vanilla-todo</url></story><parent_chain><item><author>sfrinlan</author><text>I don&amp;#x27;t know who originally said it but &amp;quot;If you&amp;#x27;re not using a framework, you&amp;#x27;re building a framework&amp;quot;. This repo even has the following caveat:
(2) These usually end up becoming a custom micro-framework, thereby questioning why you didn&amp;#x27;t use one of the established and tested libraries&amp;#x2F;frameworks in the first place.&lt;p&gt;That said, I don&amp;#x27;t hate it. For quite some time, I&amp;#x27;ve taken the stance that a web development team needs an opinionated framework, but it&amp;#x27;s fine for it to be a bespoke creation rather than off-the-shelf. The biggest value of choosing React, Vue, Svelte, etc is, in my opinion, less about it doing the heavy lifting for you with the DOM and more about adopting an established valid opinion to guide the team&amp;#x27;s development.</text></item></parent_chain><comment><author>wtetzner</author><text>&amp;gt; These usually end up becoming a custom micro-framework, thereby questioning why you didn&amp;#x27;t use one of the established and tested libraries&amp;#x2F;frameworks in the first place.&lt;p&gt;Often a custom micro-framework better suits the needs of a particular project.&lt;p&gt;I&amp;#x27;ve written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn&amp;#x27;t do, or it was very difficult to get them to do.&lt;p&gt;An additional benefit was that using the micro frameworks ended up being simpler, and the startup time was much, much faster.&lt;p&gt;Whether or not you use an existing framework depends on how much effort it is to write and test a custom framework vs the amount of effort you&amp;#x27;d need to put in to use an existing framework.&lt;p&gt;The ones I&amp;#x27;ve written have been pretty quick to develop, and were also intended to be used for a few different projects that had similar needs.&lt;p&gt;Edit: Just for clarification, the micro frameworks I&amp;#x27;ve written are server-side, if that makes any difference.</text></comment>
<story><title>Vanilla-todo: A case study on viable techniques for vanilla web development</title><url>https://github.com/morris/vanilla-todo</url></story><parent_chain><item><author>sfrinlan</author><text>I don&amp;#x27;t know who originally said it but &amp;quot;If you&amp;#x27;re not using a framework, you&amp;#x27;re building a framework&amp;quot;. This repo even has the following caveat:
(2) These usually end up becoming a custom micro-framework, thereby questioning why you didn&amp;#x27;t use one of the established and tested libraries&amp;#x2F;frameworks in the first place.&lt;p&gt;That said, I don&amp;#x27;t hate it. For quite some time, I&amp;#x27;ve taken the stance that a web development team needs an opinionated framework, but it&amp;#x27;s fine for it to be a bespoke creation rather than off-the-shelf. The biggest value of choosing React, Vue, Svelte, etc is, in my opinion, less about it doing the heavy lifting for you with the DOM and more about adopting an established valid opinion to guide the team&amp;#x27;s development.</text></item></parent_chain><comment><author>madoublet</author><text>Framework churn is real. I no longer recommend JS frameworks simply b&amp;#x2F;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.</text></comment>