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

Why Vanilla JavaScript

guseyn.com

Post reply on HN
Print view View original

111–120 of 176 posts

Re: Why Vanilla JavaScript

#111

Post by CM30 »

Honestly, I've always thought that whether frameworks or vanilla JavaScript are better is very context dependent. If you're working on a complex UI where keeping everything consistent and understandable without a framework would be hell (like Google Docs or Gmail), then a framework like React is preferable. If you're working with a simple website that needs minimum interactivity, then vanilla JavaScript is probably the better tool for the job.

The issue is that much of the time, people seem to choose tools based on convenience/past experience, not whether it's actually the right solution to their current issue.

Re: Why Vanilla JavaScript

#112

Post by oneeyedpigeon »

dsego wrote: post #103
inigyou wrote: post #100

Earlier quoted context omitted.

Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.

But it's harder to have component composition. Consider also lists and adding/removing items and so on, juggling all of it gets insanely complex and requires MVC or MVVM patterns like with backbone.js

But now we're back at "Not everyone is building complex UIs like google sheets". I agree with the underlying sentiment of this thread: overengineering is way more common than underengineering.

Re: Why Vanilla JavaScript

#113

Post by olavgg »

I fully agree with the author, and I have stayed on vanilla JS for decades now. I like the simplicity, ownership, zero dependecies. I have my own bundler in Spring Boot using Google Closure Compiler, which works autonomously with the javascript assets. No nodejs needed.

Also with the developer disruption of agentic coding AI, the arguments for using vanilla JS is even stronger. Code reviews of code/solutions is much easier. Scoping of code paths for each server-side render templates is easier. The AI does all the boilerplate coding, while keeping it readable and debugable. Implementing design patterns is just common computer science stuff, and the coding agent is pretty good at it.

I also what to mention, as a business owner, and boss of a startup. All developers here work with vanilla javascript. They were first surprised, but today they prefer it by a huge margin because of the simplicity and zero dependency and non existing build steps. The web browser is the framework, you need another abstraction over the web browser.

Re: Why Vanilla JavaScript

#114

Post by dsego »

oneeyedpigeon wrote: post #112
dsego wrote: post #103

Earlier quoted context omitted.

But it's harder to have component composition. Consider also lists and adding/removing items and so on, juggling all of it gets insanely complex and requires MVC or MVVM patterns like with backbone.js

But now we're back at "Not everyone is building complex UIs like google sheets". I agree with the underlying sentiment of this thread: overengineering is way more common than underengineering.

Eventually each crud form evolves into something more complex, the bar is set higher today, we expect pagination, filtering, search, inline editing, grids, instant validation, auto-save, push notifications, state sync, ... that's not a complex UI nowadays, it's expected. Not sure what a non-complex UI looks like.

Re: Why Vanilla JavaScript

#115

Post by dsego »

not-a-llm wrote: post #106
inigyou wrote: post #100

Earlier quoted context omitted.

Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.

it can be faster, but is it correct? React was invented because jQuery style state management collapsed into unmanageable code past a certain size

And it wasn't composable, state was kept in the DOM. Even with higher level libs like backbone we didn't have a component-oriented way like now. Each component had to manually manage all of its child components.

Re: Why Vanilla JavaScript

#116

Post by ChadNauseam »

bfjvibybd6cuvu6 wrote: post #93
ChadNauseam wrote: post #75

Earlier quoted context omitted.

As a user I don't really appreciate sites that do this as they tend to have worse latency for UI interactions and less pleasant page transitions. And of course, they are unusable offline

My sites with htmx have less latency for ui interactions and page transitions work like every page on the internet. As for offline, yeah, my Internet web page doesn't work offline. Shocker.

> As for offline, yeah, my Internet web page doesn't work offline.

That's really too bad honestly. What about your users who want to use your site when they're offline? Sympathy with those users is why I made sure that my site works well when offline.

Re: Why Vanilla JavaScript

#117

Post by nashashmi »

VanillaJS ecmascript needs far more rapid development. Right now too often there are polyfills being suggested to avoid developing features into the browser. For example, react and vue and angular features should be standardized by now.

As for frameworks, we are not progressing towards AI-driven frameworks.

Re: Why Vanilla JavaScript

#118

Post by inigyou »

dsego wrote: post #103
inigyou wrote: post #100

Earlier quoted context omitted.

Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.

But it's harder to have component composition. Consider also lists and adding/removing items and so on, juggling all of it gets insanely complex and requires MVC or MVVM patterns like with backbone.js

You just call updateFieldVisibility() every time the list selection changes and don't worry about the redundancy.

Re: Why Vanilla JavaScript

#120

Post by pjmlp »

wett wrote: post #14
FpUser wrote: post #6

Earlier quoted context omitted.

>"frameworks scale and provide structure" Web Components and vanilla JS scale just as well. Been doing this for ages.

Asking in good faith: how is your experience working with vanilla JS on a team? While I’m not the biggest fan of Nextjs for my own solo projects, I really enjoy using it at work. Leaning into the opinionation it provides/encourages keeps my team from bickering too much about how to structure things. It’s really nice to say “this is the idiomatic way of doing it according to the docs” and for everyone to nod their hea…

You impose static analysers on the CI/CD pipeline, or git pre-commit hooks for code style?

Folks learn about how to use modules and libraries?

Post reply on HN