Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

51–60 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#51
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.

Re: The JavaScript ecosystem is delightfully weird

#52
post #48
post #46

I moved away from JavaScript because of the same reason I moved away from PHP. An originally decent idea gone terribly wrong.

How do you build web applications?

I don't. I build backend services now.

But to be fair, I still maintain a relatively popular Chrome extension in old-school JS and that's still a pleasure to work with.

Re: The JavaScript ecosystem is delightfully weird

#53
post #49
post #46

I moved away from JavaScript because of the same reason I moved away from PHP. An originally decent idea gone terribly wrong.

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.

Re: The JavaScript ecosystem is delightfully weird

#54
post #29

Earlier quoted context omitted.

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.

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.

Re: The JavaScript ecosystem is delightfully weird

#55
post #12

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

How is it a better codegen target than any other language? That's not intended with an argumentative tone- I'm genuinely curious as to what you mean.

Hum... A lot of people is working on JS codegen, so there are all kinds of knowledge bases, libraries, and standards for it. Also, JS itself got some changes to support it better.

So, yeah, it's a better target than most general purpose languages. It's surprisingly simple to generate, much simpler than to write on. It is also a worse target than most languages specialized on being generated.

Re: The JavaScript ecosystem is delightfully weird

#56
post #45

Earlier quoted context omitted.

JS itself is perfectly fine and quite a nice language when you stick to all its modern idioms that you learned and use today. I think what rankles a lot of people is going through the history of JS when it was terrible and confusing, then basically just jQuery, then the explosion and confusion of server side/node and drama with the company behind it, and finally confusion and drama with moving to modern ES modules. F…

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.

Re: The JavaScript ecosystem is delightfully weird

#57
post #51
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.

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.

Re: The JavaScript ecosystem is delightfully weird

#58

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

It is one of the many things being worked on. The truth is that no part of the web standard bodies has WASM as a priority, so it moves slowly.

Anyway, on practice all that means is a bit of lost performance on the DOM interaction. It's a big deal if you do a react-like framework, but the DOM has bad performance anyway, so people tend to not create react-like frameworks.

Re: The JavaScript ecosystem is delightfully weird

#59
Good article. There's of course editorial decisions about what to mention but still the in the Nobody part the JS-as-compile-target coverage seems a bit selective. There's of course ClojureScript, Elm, Scala.js, ReScript and TypeScript (the latter is mentioned in passing).

Re: The JavaScript ecosystem is delightfully weird

#60
post #31
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.

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't exactly small either.

Post reply on HN