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

41–50 of 154 posts

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

#41

Post by vanadium »

shams93 wrote: post #39
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…

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?

IE11. IE11 remains the problem.

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

#42

Post by futureproofd »

ryanbrunner wrote: post #30
nicoburns wrote: post #22

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…

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 framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.

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

#45

Post by lynndotpy »

I appreciate this project a lot! As someone exploring webdev as a hobby, everything is new to me and there are a variety of frameworks. I'm hesitant to start from somewhere that isn't "vanilla". As someone only a little familiar with JavaScript, the script seems surprisingly comprehensible.

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

#46

Post by DarkWiiPlayer »

vanadium wrote: post #41
shams93 wrote: post #39

Earlier quoted context omitted.

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?

IE11. IE11 remains the problem.

In the corporate world, yes (sadly), but for personal and free projects I'd say it's acceptable to just ignore IE entirely and at most include some JS snippet to tell its users to get a real browser.

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

#47

Post by jeroenhd »

morrvs wrote: post #21
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 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.

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

#48

Post by gumby »

throw_m239339 wrote: post #43
mark_and_sweep wrote: post #38

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

and Perl CGI. That's all a developer needs!

I have written (internal) production CGI in bash.

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

#49

Post by boplicity »

On a side note, the TeuxDeux app they cloned is wonderful. It immediately clicked for me. As someone who's been managing five big projects simultaneously, this is going to significantly help with cognitive load. I love the lists below the calendar.

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

#50

Post by nicoburns »

Cthulhu_ wrote: post #37
nicoburns wrote: post #22

Earlier quoted context omitted.

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.

Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component.

Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).

Post reply on HN