Live data from Hacker News

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

github.com

61–70 of 154 posts

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

#61

Why is there an fps counter at the top right?

Performant drag & drop + FLIP animations were not trivial to implement (naive approaches like re-render fully on each mousemove fail spectacularly). I needed to see FPS on a couple different devices so I added the counter. Also, since I claim good rendering performance in the case study, I just kept it there as "proof" :)

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

#62
I love it! It's definitely an exercise worth taking. Nice transfer size, and I'm happy to see that the code is quite maintainable.

I do my wordsandbuttons.online in similar spirit: no dependencies, and all the pages are kept below 64KB. However, as the code base grows, I'm starting to employ scripts to do the grunt work for me. So while I don't have dependencies per se, code patterns become dependency it its own right.

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

#63

Oops, I expected vanilla web development to mean server-rendered HTML with forms. Thanks for making me feel old.

Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.

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

#64
post #21

Earlier quoted context omitted.

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

Partly I agree, 5% of users is a lot. However, this number will only continue to decrease as time goes on, and it also has to be questioned for any specific product whether that number is bigger or smaller on average. Both for the (near?) future when ES6 is near-universal and for projects that have the luxury of just ignoring older browsers even today, it would be nice to have a proof of concept project like this tha…

Completely agree. In hindsight the choice of ES5 is questionable and in the study I actually conclude that another ES6-based experiment is desirable. Also, as others here have noted, you could start with ES6, see if it works for enough of your users, and only if not orthogonally introduce transpilation to ES5 as a production optimization.

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

#65
post #21

Earlier quoted context omitted.

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

I very much appreciate proof that we don't need modern frameworks as much as people claim we do. As for ES5 support, would you consider using something like Babel to be close enough to using polyfills to consider them? Transpiling ES6 into ES5 fixes your compatibility issue with ES6 just like I would argue adding a polyfill for WebP images would.

Thanks, although I wouldn't claim it to be "proof" :) and yeah, the choice of ES5 vs. ES6 seems to be a major weakness of the study as others here have said as well. In any case I believe switching the current product to ES6 would make the results even more convincing.

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

#66
as someone who has made money as front-end developer, & saw the error in my ways. I will say the industry is not interested in simpler things. they're not interested in making the web faster for everyone. your typical insert framework here web app is slow on a laptop and even worse on mobile. now throw in hiring, it means everyone thinks their app should be on react or whatever, when it doesn't warrant it to be. look at Basecamp for apps that work without a major framework. things like htmx exist but community is small.

so yeah, props to the author for making a proposition for something that would work.

but nah, frontend work this days is about making everything complex from getting the project running to the build steps and even deploying the project.

though one area, I will say frontend is now better on is testing: cypress, jest and react-testing library are nice things to work with.

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

#67

Earlier quoted context omitted.

Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects. Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the fr…

Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?

One time work to get knowledge outside your head vs mental notes for context switching while you code? For some people/projects, the first one would be much easier.

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

#69

Earlier quoted context omitted.

Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?

One time work to get knowledge outside your head vs mental notes for context switching while you code? For some people/projects, the first one would be much easier.

Personally I don't find hooks vs. classes much of a context switch. The mental model for the component lifecycle is more or less the same, it's mostly just a different surface syntax (there are a few extra rules for hooks like not putting them in conditionals, but you'd have those in a pure-hooks setup too).

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

#70

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.

Can you run code written in 2015 on the latest version?
Post reply on HN