Any framework that requires me to learn custom syntax, is a problem in my opinion. I agree with the author that the browser is already the framework, and a powerful one at that. I don't really struggle with views and dom thanks to my own libraries, so maybe those without appreciate thw guilded gardens of these frameworks. Problem is that if these frameworks fall out of favour or stray from their original quality, you're stuck with worthless knowledge and maybe code as well
Why Vanilla JavaScript
11–20 of 176 posts
Re: Why Vanilla JavaScript
#12I wish there was some sort of "use strict-typed" or something that let you use in-browser interpreted typescript
Well, you could use jsDoc to hold your types instead of writing them in typescript. The typescript compiler can still check types in jsDoc comments but you do not need a build step and the javascript you ship to the browser would be the same you write in your editor.
I built some modules with jsDoc because I didn't want to have a build step but wanted type support.
Works fine.
Re: Why Vanilla JavaScript
#13This hit so close to home. For the last eight months I've been building a web app without any major framework like react or angular. Angular taught me a lot of important lessons about best practices for structuring UI. But eventually you run into boilerplate that doesn't jive with what you want to do.
The author frames this as artificial complexity, and that's the best framing I've seen. The browser has a particular presentation philosophy and the more you try to cover it up, the more awkward your code becomes at the edges.
The killer application of LLMs is their ability to inform and adapt to a particular API, and analyze the code that you write. They are garbage at producing functionality for which they don't have a thousand examples, but provide documentation and intent and they will help you fill in the gaps. This is the real 10x opportunity, and the best part is that you can still write all the code yourself.
I'm certain this doesn't just apply to javascript and the web. I predict that the need for frameworks will slowly go away.
Re: Why Vanilla JavaScript
#14Some good history of the JS ecosystem here but the underlying message is all the same, frameworks scale and provide structure but you don't need them. Very easy to agree up to this point. Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves f…
>"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 head. Whereas pages in our legacy PHP codebase look completely different depending on who implemented them.
Re: Why Vanilla JavaScript
#15I appreciate the sentiment, but can't agree fully. I used vanilla JS for many years before AngularJS even existed (and I also tried AngulasJS when it was the new thing).
Vue is just a huge convenience over raw JavaScript for large, complex view. Sure, I don't get to do direct DOM manipulation, but when I write C code I also don't get to pick which variable goes in which CPU register. I accept giving up control that ASM would give me, for all the improvements that C brings on top of it, even if C just compiles to ASM and is an abstraction on top of it.
Re: Why Vanilla JavaScript
#16What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?
Re: Why Vanilla JavaScript
#17It’s been a minute since someone ranted about frontend frameworks. Take a shot.
Re: Why Vanilla JavaScript
#18Some good history of the JS ecosystem here but the underlying message is all the same, frameworks scale and provide structure but you don't need them. Very easy to agree up to this point. Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves f…
We practice engineering. As engineers, we need to understand the realities of each project we take on. Those realities are not limited to the marketing bullet points we might apply to the imagined product someday, which is what early career folk might naively call "the requirements". Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in whi…
It is truly insane that this still continues to happen today, I mean the entire cloud industry is built on overcharging clients for compute they will never ever realistically use.
Not too mention how damaging it all is to environment in exacerbating the climate catastrophe.
Re: Why Vanilla JavaScript
#19I've been considering going back to vanilla javascript, given the current power of LLMs. It could become unreadable spaghetti, but it does that anyway with frameworks.
Re: Why Vanilla JavaScript
#20Sad to see no mention of @ts-check. I love being able to write native browser JS modules with nearly all of the functionality from TypeScript.