You're viewing a single thread.
When I write JS:
- It's because it has to run in a browser. (Why would I want to write JS that runs outside a browser? Rhetorical question. Don't answer that.)
- I use no JS dependencies. Zero. None. No jQuery. No React. No VUE. No Typescript. Nothing like that. (Unless you count as "JS dependencies" a) a minifier (but not one written in JS) or b) browser builtins.)
- I don't use any ECMA6 stuff. (Who asked for classes anyway?) Though to be fair, that's definitely at least partially because I have yet to even really look into what's available.
- I love callbacks and closures.
- I keep my global scope tidy, though I do store some things in the global scope. (Typically one or fewer global variables defined per JS file.)
- I don't use prototypes. Just because I've never found good uses for them.
I do believe there's a beautiful language living inside JS. It is quite pleasant to work with. But not the kind of thing I'd want to write "real software" in when there are alternatives like Go or even Python.
You do you, but no ECMA6 stuff? I don't use a lot of ECMA6 either because JS is at ECMA14 and continues to change. I can't imagine reinplementing stuff on every project you work on, though perhaps your work is very different to mine. That said, treeshaking has really brought down the cost of imports and there are few occasions where using a custom solution over a reliable third party library is a good option. Curious to hear your thoughts.
Treeshaking imports (which, admittedly, I just learned about from some googling) assume that the JS you're importing comes from another file (that the browser would have to fetch separately), yes? I believe that's not a restriction of RequireJS (which I have experience with through my work but wouldn't use on any personal projects.)
I'm just thinking performance-wise you'd get better performance by putting all of your JS in one (or a very few) files to be fetched from the server via one (or very few) requests. I am perhaps more of a stickler for shaving a millisecond here and there. (Which is part of why I wouldn't use large JS lubraries. I wouldn't want to make the browser have to load them.)
It's very typical to import code from other files, but it's also typical to have a minification step that essentially performs what you're saying, compressing the files down into something more optimal. In fact more advanced solutions essentially stream the minium amount to users as needed, and compute as much as possible in the server side.
To be honest, I'd bet a lot than by not utilising larger libraries and their standardised functions, your code has a good chance of running slower. Besides, for the typical computer and network capabilities today, there's a lot of wiggling room.
That said, for absolute tip top of performance (where experience is a trade off) you can find fun things like this, where groups do have to push for the upmost performance.
We used to use jQuery because there basically wasn't a decent way to do a lot of things back then. Like selectors for instance.
Many of its best features have been absorbed in JS to the point vanilla is a much more approachable choice now.
The reason react and Vue are so popular is that any decently sized js app quickly becomes very hard to maintain. Or at least becomes time consuming to maintain. This is generally down to its dynamic nature.
Yeah, I agree that jQuery used to be pretty necessary for some pretty basic features in JS but is kindof obsolete now-a-days.
I don't agree that any codebase that doesn't use framewok X or Y will inevitably devolve into unmaintainability. If it does, it's probably more because one isn't following best practices. (Like the Unix Philosophy or SOLID (which functionally are kindof the same thing), DRY, ZOI, etc.) And no amount of frameworks can save you from that fate if you indeed aren't taking steps to ensure the longer-term maintainability of your codebase.