Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

211–220 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#211
post #168

Earlier quoted context omitted.

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?

Only type hints. They help a linter/IDE bitch about types but they don't have any enforcement beyond that. They're great for self documenting methods but don't remove any dynamic typing from the language itself.

Re: The JavaScript ecosystem is delightfully weird

#212

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…

My experience with javascript as a non-software developer/non web person has often involved frustration. A good example is an experience I had a few years ago (circa 2018) My work acquired some new software which published some results using a REST endpoint. I wanted to pass some parameters to the endpoint get a response and display the response on a webpage. I'm used to working with Python/R and SQL databases it is…

Await is just syntactic sugar for promises.

Re: The JavaScript ecosystem is delightfully weird

#214
post #7

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

> Coffeescript was well before "tree shaking"

From my quick research, it looks like the initial release of google's closure compiler, which had some amount of tree shaking, predates Coffeescript by about a month.

Re: The JavaScript ecosystem is delightfully weird

#215

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…

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

There are lots of well-liked dynamic languages. But JS deserves the bad rap, it has so many WTFs in it's dynamic behavior and as a rule doesn't raise errors when things go sideways. Just painting it as a dynamic vs static thing is misleading.

Re: The JavaScript ecosystem is delightfully weird

#216

Earlier quoted context omitted.

Sorry, but var is absolutely still a thing. It has plenty of valid use cases and sometimes using let just needlessly complicates the code.

I'm curious, what use case? I can honestly say I don't think I've used var once in the last 5 years but maybe my coding style is different. Where is var useful?

I imagine the person above deals with legacy codebases or vanilla JS (with no SPA framework) on the front-end, because I haven't seen "var" in over 5 years outside of those contexts.

Re: The JavaScript ecosystem is delightfully weird

#217
post #197

Earlier quoted context omitted.

What do you think about Deno?

Not a fan, for one reason in particular: they allow URL imports[0]. It's a massive uptime and security flaw in my opinion that was added because someone asked for it. It's been asked for on the Node repository as well where it's received mixed feedback (namely, negative feedback from several core contributors) due to it being, well... a dumb idea. I've never seen the need for Deno. Every library I've written that has…

They have ways to lock, bundle & version those in the faq you linked, so it doesn't seem to be a problem. I wonder if people have the same complaints about golang

Re: The JavaScript ecosystem is delightfully weird

#218

Earlier quoted context omitted.

Are you really trying to say people couldn't build complex apps before TypeScript? I know of hundreds of examples that were made before TS... Complex apps still had lots of tests, which basically solve the same problem as TS is trying to address, without having to write a different language than what gets run by the browsers.

How would you compare the overhead of writing tests un JS to the overhead of doing proper TS? Obviously tests are still useful in TS, but not as many I think. Also, the feedback loop of a static type system is, IME, much faster than with tests only.

Speaking as someone who’s done both, you write the same tests either way. The main benefit of the type system is for IDEs, which have better code completion and automated refactorings when they can statically analyze types. Types also make type-related errors easier to debug: your tests will probably trigger the bug, but you’ll have to do some digging to figure out why.

On the flip side, the TS type checker is painfully slow, the code is noisy, and you’ll waste a lot of time satisfying the type checker.

For me, the sweet spot has been dynamic (runtime) type assertions in JS. Fast feedback loop, no transpilation hassles, good error messages when type-related errors occur. Downside is that now the editor can’t statically analyze types.

Lately, I’ve been experimenting with using swc to transpile TypeScript without typechecking it. Now there’s a fast feedback loop and I use the IDE to discover type errors. (And the integration build checks types too.) I’ve just recently started this experiment, so jury’s out on whether it’s better than runtime type checking.

Re: The JavaScript ecosystem is delightfully weird

#219

Earlier quoted context omitted.

I'm so sick of these paradigm religious wars. There's nothing wrong with object oriented programming. There's nothing wrong with functional, either. You use them for different purposes. These people like Crockford who talk about "Java programmers are stuck in this inferior way" are the ones who are stuck and not all that educated on programming.

They weren’t criticizing OOP per se. Before the class keyword, JavaScript had much more powerful OOP semantics using metaobjects.

The class keyword is just syntactic sugar. JS still uses prototypal inheritance. Nothing has changed. Check out objectplayground.com for details.

Re: The JavaScript ecosystem is delightfully weird

#220

Earlier quoted context omitted.

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…

LoL, and so it begins ...
Post reply on HN