The JS ecosystem also relies on npm, which is owned by Microsoft. Having a corporation control package management is pretty weird .
Something something pnpm, yarn, jfrog
The JavaScript ecosystem is delightfully weird
61–70 of 248 posts
Re: The JavaScript ecosystem is delightfully weird
#62Earlier quoted context omitted.
I suspect that if some accidents of history hadn't left JS as the only language you can use to script a Web browser, it would have died off long ago.
I've been wondering about that lately. What is the rationale for making it necessary to run WASM binaries through JavaScript? Seems like a missed opportunity to not be able to just point a script element at a WASM blob, but I'm sure I'm overlooking something.
Google already tried the blob with Native Client, but I recall Firefox decided not to support it.
Re: The JavaScript ecosystem is delightfully weird
#63Earlier quoted context omitted.
typing saves so much time. Especially since the flexibility of its optionality does not restrict, and allows for really nice autocompletions. Especially with esbuild which has made this simple and fast, one could even say it has saved javascript.
I have ample experience with typed languages like C++, C#, Java, Kotlin, Go, AS3, Swift, etc. Maybe I just have exceptional memory but I rarely encounter a problem that would have been solved by using TS.
It's about big codebases and team use, not about you.
Re: The JavaScript ecosystem is delightfully weird
#64Earlier quoted context omitted.
I have ample experience with typed languages like C++, C#, Java, Kotlin, Go, AS3, Swift, etc. Maybe I just have exceptional memory but I rarely encounter a problem that would have been solved by using TS.
It's about big codebases and team use, not about you.
Yep, they're a communication and documentation tool that happens to have pretty-good machine readability and correctness-checkability. Sometimes the person you're communicating with is your future self, is all. Sometimes it's just yourself five minutes from now, even.
Re: The JavaScript ecosystem is delightfully weird
#65Earlier quoted context omitted.
I have ample experience with typed languages like C++, C#, Java, Kotlin, Go, AS3, Swift, etc. Maybe I just have exceptional memory but I rarely encounter a problem that would have been solved by using TS.
It's about big codebases and team use, not about you.
They didn't mention big codebases or working on a team, though. Also, you can just use JSDoc.
Re: The JavaScript ecosystem is delightfully weird
#66Earlier quoted context omitted.
IMHO JavaScript is neither a good OOP language not a good Functional language.
Unfortunately I think the opposite. JS was a great prototype-based language, but very few understood those and tried to fit it into functional or OOP mindsets. When they started talks about adding classes to the spec I knew I had to run away.
> JS was a great prototype-based language
Maybe it's just me, but everything distinctive about prototypal OO falls firmly in the category of "please never actually use this in a codebase I have to work in".
Re: The JavaScript ecosystem is delightfully weird
#67Many other comments have touched upon other unusual aspects of the Javascript ecosystem, but there's another major aspect in the ecosystem at quite a precarious position, yet of which, I see very little discussion on, namely, the debugger. Chrome DevTools is the de facto debugger of Javascript, which becomes apparent once I have to take advantage of Javascript's capability of moving beyond the browser, on alternate r…
WebStorm and VSCode both have OK debuggers, but in my experience they are even more finicky than the Chrome one, which as you noted does have issues. Firefox and Safari are likewise fine, but not as good as Chrome.
More importantly though, if you are that distrustful of Chrome, you probably should not be using Node because it is based on v8, the Chrome Javascript runtime.
Re: The JavaScript ecosystem is delightfully weird
#68Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits. It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node…
> As a maintainer of several large JS packages, and being so dreadfully burnt out on JS, there are other words I'd use to describe the whole thing than "delightful".
My first project that used JS was in 1996, so I've been along the ride every step of the way. Up until today where I am working with all of this on an Angular 15 enterprise project.
I actually would describe it as delightful, compared to what it was like only a short 10 years ago. 1996-ES6 was painful.
I understand your pain as maintainer and am also burnt out on ... um ... 27 years of JavaScript. Yikes.
But now it can just be written in TypeScript and I'll let the transpilers and other tools handle the details.
It is so much better.
Re: The JavaScript ecosystem is delightfully weird
#69The JS ecosystem also relies on npm, which is owned by Microsoft. Having a corporation control package management is pretty weird .
Well, now that Microsoft has embraced and extended open source, I think it's time for us all to let our guards down, because it's not like they have some kind of "third step" to their business plans.
Re: The JavaScript ecosystem is delightfully weird
#70Earlier quoted context omitted.
The problem with JS these days is not that what's there is bad. It's that there's not much there. Anything beyond the basics requires you to roll your own or go hunt for a library.
Very true, it's why I really like deno for server side since it's trying to plug that gap with a nice out of the box standard library. Client side it does feel like something like lodash is the new jQuery and just mandatory to use everywhere.
And then of course you have to pick between lodash and ramda (I'd say "whichever your dependencies use" but every time I've tried to use that as a deciding factor the answer has turned out to be "both").
It's all a bit of a cambrian explosion but it at least means you run into "this awful API has been baked into core and now we're stuck with it" less often.