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

51–60 of 154 posts

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

#51

Post by wtetzner »

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…

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

Often a custom micro-framework better suits the needs of a particular project.

I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do.

An additional benefit was that using the micro frameworks ended up being simpler, and the startup time was much, much faster.

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'd need to put in to use an existing framework.

The ones I've written have been pretty quick to develop, and were also intended to be used for a few different projects that had similar needs.

Edit: Just for clarification, the micro frameworks I've written are server-side, if that makes any difference.

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

#52

Post by twodave »

> Data flows downwards, actions flow upwards

I know I'm nitpicking here, but I always find this phrase confusing, and I think this way of explaining unidirectional data-flow is problematic for those new to the concept.

If you want to persist something from a child component, the message that represents the action contains the data needed to make that state change, which sort of exposes the flaws in the up/down analogy.

Unidirectional data flow doesn't have an "up" and a "down". It doesn't even follow a single path. It's more like a ladder with several water slides connected to it. The pool is where the state lives. The slides are the child components. The people are the data. Climbers are performing state propagation. People who are sliding are creating actions. People who are landing back in the pool are updating the state.

Edit: no, it's not lost on me that the example I ended up using involves up and down motion--it's just not a very easy concept to convey using real-life analogies (which I think also contributes to the learning curve).

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

#53

Post by overgard »

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…

I think the problem with bespoke frameworks is that many career driven developers won't want to become a specialist in proprietary tools that won't transfer. However...

I have this strong suspicion that most projects that use something like React don't really need it. Like, if you're creating something that actually acts like an application and data might be shown in many places it makes a lot of sense, but for something that's just displaying data from a db on a page hit it can be massive overkill.

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

#54

Post by DarkWiiPlayer »

shams93 wrote: post #40
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.

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.

That hardly makes any sense. Most widely used frameworks are open source projects; it seems much more reasonable to assume that constant changes in direction are more an expression of developers wanting to play with the fancy new toys instead of sticking with one paradigm and keeping it stable.

Even setting that aside, there's nothing keeping older developers from switching to a newer technology; it might be a bit bothersome to adapt to ultimately inconsequential changes again and again, but that applies to younger devs just as much.

It's also not like web development is old tech in any way. There's constant improvements being made and things are often changing for the better.

Well, for the most part at least. Looking at the situation with serverside resource compilation I have to wonder when the world of web will re-invent make and call it a revolutionary achievement.

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

#55

Post by onion2k »

NiceNamesOrg wrote: post #26
madoublet wrote: post #25

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.

Most of the code people have written in Vue 2 is compatible with Vue 3.

All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.

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

#56

Post by nicoburns »

onion2k wrote: post #55
NiceNamesOrg wrote: post #26

Earlier quoted context omitted.

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.

Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.

Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.

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

#57

Post by DarkWiiPlayer »

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…

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 that uses modern ES6 features, since many of them address precisely the types of problems that many pre-processors also fix.

Template-strings, custom elements, etc. add a huge amount of possibilities for web-application development and imo should get way more attention outside of a small circle of excited people.

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

#58

Post by debaserab2 »

futureproofd wrote: post #42
ryanbrunner wrote: post #30

Earlier quoted context omitted.

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 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?

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

#59

Post by morrvs »

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

Thank you very much, looking forward to your feedback! And yes, this is exactly what I wanted to achieve :)

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

#60

Post by morrvs »

boplicity wrote: post #49

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.

Totally agree. I should update the study to express praise for the original TeuxDeux, it's conceptually the best to-do app out there in my opinion.
Post reply on HN