Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

131–140 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#131

> Less that 10 years ago, JavaScript sucked bad. It had no imports, no classes, no async, no arrow functions No classes in JS was much better than with. As someone who used and contributed to CoffeeScript, I was initially excited by them but in retrospect, they've been a huge negative IMO. Douglas Crockford saw it immediately: https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=300s

Yeah, I write all my new stuff in JS (React frontend, Node backend) and have never felt the need for defining my own classes. Wasn't actively avoiding them either. React was fully centered around classes and they ditched all that in the new hooks system. I also don't understand the big deal with arrow functions. Yeah I use them, but they're basically regular functions except slightly shorter to write. `async` was a b…

Arrow functions have less-incomprehensible semantics of what "this" means. Though that's less important if you're not using the classes.

Most users just use arrow functions as syntactic sugar. But it's really good syntactic sugar.

Re: The JavaScript ecosystem is delightfully weird

#132
post #122

Earlier quoted context omitted.

Javascript, The Good Parts, is not really relevant to today's Javascript, unless it's been refreshed. I remember working through it 10+ years ago: * `var` is no longer a thing. * Even `let` is less common now. * Using closures and prototypes to enable functions to be used like classes and have private variables and static variables, have been replaced with proper classes Nowadays if you want to use the good parts of…

>just install eslint with insane defaults where do I find these insane defaults?

lol, that was a typo, should have said "the sane defaults"

On the other hand, it's a testament to the comment being written (or at least edited) by a human, and not an LLM right?

Re: The JavaScript ecosystem is delightfully weird

#133
post #14

> Nobody Writes JavaScript Any More This is how "delightful" it is, and is the reason I'm waiting for it to die. Every couple of years we decide on the 'no no, definitely this time we have it all figured out, trust us, just use X' "solution" to the problem of JavaScript. We have the definative 'this is how you do it', until the next one.

Javascript is not going away anytime soon, probably. Personally, I'm waiting for React to die.

As much as I love React and it has been a positive part of my career, I'm starting to think there really are better alternatives. Its staying power may just be the sheer number of people supporting its ecosystem and competent enough to build things with it.

I'm content to keep working with it, and I'm so familiar with it that for small tasks it's kind of my go-to. If I was building something I wanted to be long-live a future-friendly, I might be hesitant to run with React at this point. To be honest though, I'm not sure what's better than would be a clear contender for having similar staying power. I wouldn't complain if that turned out to be Solid.

Re: The JavaScript ecosystem is delightfully weird

#134
post #70

Earlier quoted context omitted.

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.

Anecdote: when using Metalsmith and a sampling of plugins to build my fairly minimal static site, I ended up with 18 direct dependencies and 200 transitive dependencies, including 6 different file name matching libraries.

I now prefer comprehensive standard libraries.

Re: The JavaScript ecosystem is delightfully weird

#135
I like javascript, but I always think about the time when I was working as a front end developer, and a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters. I believe his concern was around the lack of type safety (this was before we used Typescript). And this was someone not prone to dramatic gestures.

At the time I laughed. Guy must be having a bad day. Javascript rules, look at this widget I made.

Cut to a few years later. I am fed up with React, and the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months, the SPAS that made a simple web app spool up the user's laptop fan with all the javascript it was processing just to do basic stuff we could do much more simply in the 90s.

I ultimately quit being a developer in 2019, switched to doing design full time. I still write javascript for personal projects, because it's the thing I'm most familiar with. But, only vanilla javascript.

Javascript rules, but also: f*ck javascript.

Re: The JavaScript ecosystem is delightfully weird

#136

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…

"Modern Javascript for the Impatient" does a good job for the language itself. It doesn't try building on non-existent prior knowledge. It assumes you program, but in other languages.

Re: The JavaScript ecosystem is delightfully weird

#137
post #122

Earlier quoted context omitted.

Javascript, The Good Parts, is not really relevant to today's Javascript, unless it's been refreshed. I remember working through it 10+ years ago: * `var` is no longer a thing. * Even `let` is less common now. * Using closures and prototypes to enable functions to be used like classes and have private variables and static variables, have been replaced with proper classes Nowadays if you want to use the good parts of…

>just install eslint with insane defaults where do I find these insane defaults?

There used to be a lot of nice default packages, but I'm not aware of any actively maintained ones (other than "company X's config"). So instead...

First, find the docs for ESLint and each of the integration packages that you've installed for each major dependency. Then just set each rule to the strictest setting. Then as you're developing, you'll start running into overzealous rules, prompting you to either disable the rule or write some override/exception.

TSConfig, on the other hand, isn't extensible so you can just throw a couple configs from github.com/tsconfig/bases in your `"extends": [...]`. The base config `@tsconfig/strictest` might be of interest to you.

Re: The JavaScript ecosystem is delightfully weird

#138
post #31

Earlier quoted context omitted.

Are you talking about JS the language, or the ecosystem? JS as a language isn't nearly as big as C++ or, say, Swift... I'd say Python complexity is on par or even higher than JS, in terms of core language features. There are some language features that are outdated but it's hardly like the C++ situation.

ECMAScript Language Specification 13th Edition / June 2022 (846 pages): https://www.ecma-international.org/wp-content/uploads/ECMA-2... Working Draft, Standard for Programming Language C++ from 2020-01-14 (1815 pages): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n48... I'm not sure what's the "correct" spec for the current C++ standard is. Still a big difference between these languages, but 846 pages isn…

To be fair, so much of the C++ standard is literally just being explicit about what the standard does not define and often who defines it instead. But to be fair, it would probably be entirely reasonable to categorize that as essential language knowledge and a "part of the language."

Meanwhile, the ECMAScript spec really does not leave very much wiggle room. It (like every other web standard) is almost just documentation or often even pseudocode-ification of an actual implementation... Certainly makes you think.

Re: The JavaScript ecosystem is delightfully weird

#139

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)?

Dart appears to tick some of those boxes, but probably not the big package ecosystem and sum types boxes. I'm considering building something with it at the moment, but I'm hesitant to commit much brain power to something Google has a lot of influence over. Yet, Go has been awesome and I don't regret learning it. In some ways, Dart looks a bit like what I wish TypeScript could be, though not exactly.

Something I use a lot in Rust is exhaustive matching and sound types, which Dart now has. It's a somewhat specific thing, but I like designing finite, well-scoped systems which can be handled and tested almost completely. Doing this in TypeScript is kind of possible but can be incredibly verbose and difficult to navigate for less experienced programmers. While the design patterns aims to simplify and eliminate errors, the type system can easily complicate it and introduce mistakes.

That's such a drag in my experience. For example, stuff like this can happen in TypeScript: https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwd...

However, TypeScript has come a long way and it gets better in this regard all the time.

Re: The JavaScript ecosystem is delightfully weird

#140
post #29

Earlier quoted context omitted.

When I last looked, it seemed like WASM blobs just take arrays of numbers and return arrays of numbers. No objects, strings, or DOM elements, so I think it'd be tough to do web dev in wasm as it stands. And you need javascript glue if you want anything in the way of side effects. There is, however, quite a bit you can do in it. TeX has been compiled to wasm[1], it's about 600kb uncompressed 90k compressed (the memory…

Right, yes, that's how WASM is now, but what I'm asking is why didn't we give WASM access to the DOM? We could have, and we just didn't.

Sounds good to me, I was disappointed when I learned that wasm didn’t do this already. (It’d be nice to have tail call optimization too.)
Post reply on HN