Live data from Hacker News

Vanilla-todo: A case study on viable techniques for vanilla web development

github.com

31–40 of 154 posts

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#31
post #12

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.

It does start from scratch but it (re-)invents a whole lot of general-purpose code, in effect making up a framework/library, which was an explicit non-goal for the case study (because there are good ones already).

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#32
I read it all despite my short attention span. Beautifully written study.

I 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

#33
post #5

I 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…

Using frameworks is far more about hiring and human resources than technology I feel.

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

#34

Earlier 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…

The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features).

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

#35

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

How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#36

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

My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#37

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

Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context.

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

#39
post #5

I 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…

With es6 template strings you can do a lot of heavy lifting with some very simple code. This example still uses es5 to mr that’s insane who on the web is still using ie6?

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#40
post #5

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

Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.
Post reply on HN