Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 154 posts

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

#21

Post by morrvs »

tobr wrote: post #2

This is nice, patterns over libraries. I would question the choice to use ES5, as it makes it significantly more complicated to handle dependencies between modules in a scalable way. I understand the point of avoiding a build step, but if the code can run in modern clients without it I don’t think it breaks the spirit of the project to use a bundler to support certain older browsers. It’s a lot like using polyfills w…

Original author here - thanks! Yes, ES5 is a huge pain. However, I believe 5% of users (see other comment) are not a joke for many apps. There's always the question of minimum critical APIs required: If you build a 3D or webcam app you can forget ES5 altogether, of course.

> It’s a lot like using polyfills when needed.

Never thought of it this way, thanks for that! As is state in the conclusion, the study would likely be more convincing with ES6 and build steps. So yeah, ES5 is questionable :)

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

#22

Post by nicoburns »

madoublet wrote: post #20
sfrinlan wrote: 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.

React has been stable since ~2015, and there are no signs of that changing.

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

#23

Post by nicoburns »

noir_lord wrote: post #19
sfrinlan wrote: 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…

Of the three you listed Vue is the most 'opinionated' in that it ships with official router, official store (vuex) etc and that is a huge deal. With React and particulary svelte (for now) it's a mishmash of possible choices. Where that bites is when you have 3 choices to make with 4 options. 4^3 === 64 - so any project you pick up/come onto has a 1/64 chance of using a stack you've seen before.

True, but routing libraries don't tend to be that complex. Picking up a different is not exactly a big deal.

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

#24

Post by morrvs »

rablackburn wrote: post #4
tobr wrote: post #2

This is nice, patterns over libraries. I would question the choice to use ES5, as it makes it significantly more complicated to handle dependencies between modules in a scalable way. I understand the point of avoiding a build step, but if the code can run in modern clients without it I don’t think it breaks the spirit of the project to use a bundler to support certain older browsers. It’s a lot like using polyfills w…

Agreed, I originally thought this might be an older project from a couple of years ago because of the ES5. “Vanilla” doesn’t have to mean “supports IE11” in 2020 (before anyone jumps on me, yes, depending on your users you may very well still need to support it, but it’s very clearly on the way out - finally) I love the motivation behind the repo though. The author’s write-up is fantastic and refreshingly reasonable…

Thank you very much! This is quite exactly what I'm trying to achieve. Very happy that you like it :)

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

#25

Post by madoublet »

nicoburns wrote: post #22
madoublet wrote: post #20

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.

I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.

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

#26

Post by NiceNamesOrg »

madoublet wrote: post #25
nicoburns wrote: post #22

Earlier quoted context omitted.

React has been stable since ~2015, and there are no signs of that changing.

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

#27

Post by JoeyJoJoJr »

nicoburns wrote: post #22
madoublet wrote: post #20

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.

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

#28

Post by morrvs »

Joker_vD wrote: post #16
morrvs wrote: post #14

Earlier quoted context omitted.

Original author here. During the study, I explicitly forbid myself from writing general-purpose helpers which would make up a framework. Would you mind elaborating what in your view makes up the "custom framework"? Thanks!

If general-purpose helpers make up a framework, then what is the difference between a library and a framework? I'm pretty sure jQuery is not a framework.

Sorry, I didn't mean to make a difference between frameworks and libraries in this case; both would violate the method/goal of the case study which was finding vanilla patterns that are not dependant on general-purpose code.

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

#30

Post by ryanbrunner »

nicoburns wrote: post #22
madoublet wrote: post #20

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.

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 up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.

Post reply on HN