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

71–80 of 154 posts

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

#71

Post by debaserab2 »

lazyasciiart wrote: post #67
debaserab2 wrote: post #58

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.

If you understand each approach well enough they aren't context switches at all - they're just different tools for solving a similar problem. If anything, understanding each of them gives you a better understanding of the approach your team has converged on.

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

#72

Post by throw_m239339 »

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.

IE11 is an unsecure browser and doesn't even support numerous HTML5 security features. Any business that still relies on IE11 is asking to be hacked, no more, no less, because it also means that these businesses are still running older versions of Windows.

Now IE11 isn't even an excuse because $current_year ES version can be transpiled to older ES versions.

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

#73

Post by runarberg »

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…

Most of the websites I write these days don’t have a build step for development, only for production. Modern browsers (and modern node) support ES modules, so there is no need to build anything until you ship to a legacy browser.

The only pain point of not building during development is when I need to pull in a third party dependency (since node and browsers pull from different sources; and import-maps is not is still not a standard), but if your are not using any third party dependencies, you should be fine.

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

#75

Post by conscion »

morrvs wrote: post #14
king_magic wrote: post #9

> There's no custom framework invented here. Proceeds to literally invent a custom framework. It’s interesting, but I’ll stick with Vue/React.

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!

Not OP, but in my reading of your case study, you still made a framework. Instead of having a code-based framework, where the methods and classes enforce how you implement your system - you created a convention-based framework (use a specific CSS naming technique, model your JS on this template, etc.).

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

#76

Post by falcolas »

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

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.

> 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

I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "fluid" (1s). Even the worst case connection times (satellite & mobile) are still measurable using hundreds of milliseconds.

The worst ranked countries still average in excess of 1.5 Mbps transmission rates - more than enough for compressed text.

And, given how unresponsive so many "top 100" SSA pages are (such as blogs that take whole seconds to display their initial content), I can't agree that doing that processing on the server would actually be less interactive or responsive.

Even the test application from this article can load from scratch in under a second, most of that time being the DNS resolution and the server processing for serving the page.

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

#77

Post by Izkata »

wnevets wrote: post #70
nicoburns wrote: post #22

Earlier quoted context omitted.

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?

Not necessarily; just offhand I remember these: https://reactjs.org/docs/react-component.html#legacy-lifecyc...

Admittedly those are trivial renames, but they've been renamed as such because they're very likely to be buggy with async rendering.

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

#78

Post by hackerfromthefu »

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.

bwahahahahahahahahaha

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

#79

Post by hackerfromthefu »

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.

and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate

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

#80

Post by hackerfromthefu »

nicoburns wrote: post #35
JoeyJoJoJr wrote: post #27

Earlier quoted context omitted.

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.

As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant.

React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s

Post reply on HN