Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

171–180 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#171

> 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

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail f…

> The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.

I agree. Honestly I don't understand the obsession some people in the JS world have against classes.

React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with.

https://overreacted.io/making-setinterval-declarative-with-r...

Of course I know I'm in the minority here.

Re: The JavaScript ecosystem is delightfully weird

#172

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…

Surprise surprise, class syntax is basically just syntactic sugar on top of prototypes, and they essentially work the same way, besides bring able to have private members (which seems like a anti-pattern anyways). You'll able to accomplish exactly the same with both, so why create yet another way? Seems bit wasteful..

The syntax sugar paves a "garden path" for the common experience to be the best experience. It encodes "best practices" from previous prototype-based code, including private members. (They were always possible/always existed [as closures inside a constructor function, among even wilder solutions], but the patterns for building and using them was all over the map. It is nice to have standards now over a lot of ad hoc solutions.) I don't think it is wasteful, because it saves you from having to read books like "JS: The Good Parts" and hunt around for the right toolkit or design pattern to do the right things easily.

Re: The JavaScript ecosystem is delightfully weird

#173

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 d…

> 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 must be living in a parallel world cause I write React &…

I always find myself coming back to react.

Its so delightfully simple at its core. Typically super easy to debug. Extremely composable and reusable.

Re: The JavaScript ecosystem is delightfully weird

#174

Earlier quoted context omitted.

The page has a 2023 last-edited on it, but the code snippet (if you follow the GH link) hasn't been touched in two years. If their JS docs are anything like their Android docs, Google's terrible about updating examples.

async/await is still pretty old by now. Maybe they wanted to be consistent with even older examples. I dunno, every single thing Google-related uses promises, so I'm thinking they're partial to that for some reason. Another example from 4mo ago: https://github.com/kubernetes-client/javascript/blob/master/... (the catch at the end is a promise catch)

There's a tiny benefit of the doubt to be given here that while async/await is several years old, support for "top-level await" was only more recently standardized and took too long for common LTS versions of Node to also support it.

All of these examples appear to be top-level and perhaps they didn't want to write them as async functions or IIFEs, especially for error-handling code.

Re: The JavaScript ecosystem is delightfully weird

#175
post #9

So JS is delightful because we are still not actually writing JS, but stuff that looks like JS? Huh.

It's weird how JS is the only ecosystem entirely designed around the premise of avoiding direct contact with the language you're developing in at all costs. Like, even C programmers are willing to actually write C.

The C macro language is technically a different language (though today they are specified together, they originated once as different compiler tools) than C and lot of DSLs get written in it because C programmers are trying to avoid actually writing C.

There's also a lot of C programmers that prefer to use C++ compilers in C++ mode for their C code to avoid direct contact with C specification bugs or some C standard libraries.

(Plus, early C itself was designed to avoid direct contact with Assembly languages which was designed to avoid direct contact with Machine languages some of which were designed to avoid direct contact with Microcode languages most of which were designed to avoid direct contact with TTL logic and TTL logic was designed to avoid direct contact with the useful properties of transistors for computation and so forth. Programming is turtles all the way down.)

(Also there are quibbles to be made about "at all costs". JSX is still a superset of JS syntax with a little bit extra added in. Typescript is built to be a superset of JS syntax. You can't write either without a lot of direct contact with JS. Neither seems like "at all costs" avoidance to me.)

Re: The JavaScript ecosystem is delightfully weird

#176
post #79
post #6

Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it. Nothing wrong with being C++. The reason JS is so massive and weird is because it's the language that everybody uses, or has to use at some point. Upsides and downsides.

JS is far smaller language than C++. You don't need to agree on common part of language , it's the rest of the ecosystem around that's the problem as you "need" a lot just to fix JS deficiencies

Yes.

Re: The JavaScript ecosystem is delightfully weird

#177
> When a bundler/transpiler encounters an import statement, they don't necessarily presume that the file being imported is JavaScript or even any of the variants mentioned above. If configured properly and you want to import a CSS or PNG file, it will happily do so for you.

This is what I like to nickname "WebpackJS". Code that is simply invalid JavaScript and requires a carefully configured composition of webpack plugins in order to be used. I occasionally run into npm packages wanting to "import" a CSS file when I use them from ClojureScript, and it's always a pain. The good news is that these ar rare encounters, but it's still behavior enabled by people assuming you're using the exact same framework as them with the exact same Webpack configuration made by said framework.

Re: The JavaScript ecosystem is delightfully weird

#178
post #168

Earlier quoted context omitted.

> a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters >Guy must be having a bad day. He was having a bad day because he was doing stupid things with the code he wrote that led to problems. I've never had a problem with Javascript's type system, or having the wrong type show up where it shouldn't. I accepted the dynamic nature of JS long ago when it f…

Yeah, Javascript isn't even the only dynamically typed language out there, but you don't see people compiling strictly typed supersets of Python or Lisp because they consider those languages unusable otherwise. With any other language people are willing to learn the idioms and accept and work with the quirks, but for some reason Javascript alone seems to be the exception.

Didn't python add static typing?

Re: The JavaScript ecosystem is delightfully weird

#179
post #171

Earlier quoted context omitted.

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail f…

> The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced. I agree. Honestly I don't understand the obsession some people in the JS world have against classes. React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language featur…

It's because they have been bitten by inheritance issues. Classes are great as long as you limit or avoid inheritance altogether. They work so nice with typescript.

Re: The JavaScript ecosystem is delightfully weird

#180
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

I'm still using Javascript and jQuery. In combination they work just fine. I took the time to learn TS, but I never felt the need for it.
Post reply on HN