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

The JavaScript ecosystem is delightfully weird

fly.io

Post reply on HN
Print view View original

101–110 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#101

Post by hot_gril »

mattgreenrocks wrote: post #96

I've avoided JS/TS almost entirely, and shown contempt toward it a bunch in the past. I'm now at a place where TS seems like a reasonable language for prototyping backend stuff: JS has a GC, big package ecosystem, sum types, static typing, good tooling support. Only thing that ticks most of those boxes (IMO) is Kotlin. Anyone been down this road before (skeptic->using in prod)?

I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS.

I also gave TS a serious try and found it pointless. Complicated the toolchain, made default stuff like the Node profiler not work anymore, and wasted tons of time on defining types that didn't actually catch any mistakes. Went back to JS. Turns out part of its strength comes from not caring.

Before that had used Java, Scala, C, C++, Erlang, Python, Swift, ObjC, Rust, PHP, and a little Golang.

Re: The JavaScript ecosystem is delightfully weird

#102

Post by ilrwbwrkhv »

harha_ wrote: post #76

I can't help but cringe when looking at the dependency count when using some javascript framework to write client-side code. I think the frameworks and the ecosystem is overly complex and the same could be accomplished by embracing minimalism. I do like things such as babel and webpack though, but those are dev-dependencies which is unrelated to the contents of the final bundle and I can live with few dev dependencie…

Just use mithril

Re: The JavaScript ecosystem is delightfully weird

#103

Post by hot_gril »

Wazako wrote: post #51
pier25 wrote: post #44

I must be the only person left not writing TS at this point. Once EcmaScript adopts optional static types or some kind of standardized type annotations [1] I will probably use those. At least in Node, where I have more control of the runtime version. [1] https://github.com/tc39/proposal-type-annotations

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.

Typing wastes time. Teammate and I tried switching a backend project to TS, and I kept a mental note of time spent defining types vs time saved not debugging type-related issues. The result was some high number vs 0. Also messed with the toolchain, making things like Node profiling not work.

Re: The JavaScript ecosystem is delightfully weird

#104

Post by synergy20 »

toastercat wrote: post #85

I started writing a small static site generator for myself using JavaScript and QuickJS by Fabrice Bellard[1]. QuickJS is not quite complete, and there are some cross-platform inconsistencies, but overall I found it pleasant to use and its libc wrappers to be powerful enough. I also found that JavaScript is actually pleasant to use when I'm not using classes, or dealing with metaprogramming/Babel, or implicit globals…

what's the use case for quickjs? can it be used for a light-weight runtime for JS on resource restricted embedded devices?

by the way, comparing to angular and vue2-vue3, react is actually the one without python2-python3-alike breakages over the years to me, I would say it's the best out of the 3 options(angular,vue,react) so far, which could explain by market share that it remains to be dominant.

Re: The JavaScript ecosystem is delightfully weird

#105

Post by hot_gril »

Scarbutt wrote: post #63
pier25 wrote: post #57

Earlier 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.

Even in a solo project, you import libs from others. Never felt the need for those libs to have types.

Re: The JavaScript ecosystem is delightfully weird

#106

Post by qazxcvbnm »

sequoia wrote: post #98
ntonozzi wrote: post #81

Earlier quoted context omitted.

Have you tried VS Code or WebStorm? They are both independent debuggers. They are quite good for debugging in my experience. I don't know that they offer profiling capabilities.

@qazxcvbnm I don't understand: you don't want to use the chrome debugger but also don't want to use an IDE debugger... it's not clear what would meet your needs and wants, you're rejecting all the main options. Here's an overview of some of the tools in case that's useful: https://sequoia.makes.software/debugging-nodejs-talk/#55

I reject the main options for the reason that the main options are unsatisfactory.

Your link lists the Chrome debugger, IDE debuggers, and the node inspector.

The node inspector is essentially deprecated. IDE debuggers more or less piggyback on the Chrome DevTools protocol, and although I mentioned I have not given them a fair try, but they definitely seem less official, featureful, and well-supported compared to the Chrome debugger. The fact is, this aspect of Javascript seems to have, unceremoniously, already fallen into Google's sole leadership, direction, and discretion, by force or by will.

The Chrome debugger, as mentioned, exists and is probably the most well supported of all debuggers, and is what I use in practice. However, as I mentioned, even 'the best', which is Chrome, does not work very well, exhibits usability regressions per the cadence of Google (e.g. blackboxing used to work, but is very broken today), and moreover compromises basic functionality and freedoms, which comprises my dissatisfaction.

In a better world, we would have something that is native to the language (not a browser), versionable, free, featureful (e.g. profiling and memory debugging), and accessible from the shell (e.g. other languages have gdb, pdb). It would be a good thing for a protocol to actually have multiple implementations.

Something that may at least recover basic functionality from the Chrome DevTools would be to degoogle it for hermetic usage, and separate it from the browser proper. As I mentioned, I am looking forward to make that happen.

Re: The JavaScript ecosystem is delightfully weird

#107

Post by yamtaddle »

hot_gril wrote: post #101
mattgreenrocks wrote: post #96

I've avoided JS/TS almost entirely, and shown contempt toward it a bunch in the past. I'm now at a place where TS seems like a reasonable language for prototyping backend stuff: JS has a GC, big package ecosystem, sum types, static typing, good tooling support. Only thing that ticks most of those boxes (IMO) is Kotlin. Anyone been down this road before (skeptic->using in prod)?

I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS. I also ga…

> Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await

Async/await's pretty new, is probably why you're seeing so many tutorials that don't use it.

Re: The JavaScript ecosystem is delightfully weird

#108

Post by Etheryte »

ipaddr wrote: post #89
harha_ wrote: post #76

I can't help but cringe when looking at the dependency count when using some javascript framework to write client-side code. I think the frameworks and the ecosystem is overly complex and the same could be accomplished by embracing minimalism. I do like things such as babel and webpack though, but those are dev-dependencies which is unrelated to the contents of the final bundle and I can live with few dev dependencie…

Wish we had something simple like jQuery

I mean you can still use jQuery, no one's stopping you. They're still releasing new versions with updates, the last one came out two months ago if I'm not mistaken.

Re: The JavaScript ecosystem is delightfully weird

#109

Post by hot_gril »

yamtaddle wrote: post #107
hot_gril wrote: post #101

Earlier quoted context omitted.

I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS. I also ga…

> Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await Async/await's pretty new, is probably why you're seeing so many tutorials that don't use it.

Yeah, but even new documentation sometimes uses promises, particularly anything related to Google like https://firebase.google.com/docs/auth/web/custom-auth

Re: The JavaScript ecosystem is delightfully weird

#110

Post by philsnow »

I appreciate the summary of the changes in the javascript ecosystem over the last decade+; all of that happened after I had kids and I didn't have the motivation to keep up with it, so it's a complete blur in my mind.

I've tried at various times to get caught up, but it seems that every time I find articles / blogs that talk about How Things Are Done at the time they're written, with only the briefest nod to how it's better than The Old Busted Way (probably because the authors, being steeped in and surrounded by javascript for years, think that their readers will also be similarly up to speed).

Meanwhile, I feel like a historian in the year 5000, reading recipes from 2023 and wondering whether people used dog milk or cat milk (because those were the two kinds of mammals that most households had available).

Does anybody know of other resources that go into more depth on the evolution (and specifically the Whys) of the javascript ecosystem?

Post reply on HN