Today’s JavaScript, from an outsider’s perspective (2020) • Hacker News Board

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#351

Post by unsupp0rted » Fri, May 27, 2022, 9:03 PM UTC

jdminhbg wrote: post #322

donatj wrote: post #256

Earlier quoted context omitted.

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the…

Is there an NPM module that serves as a standard library?

My code is a combo of lodash bits, datefns, helper regexes I’ve curated over the years, etc

Is there a standard library-like package that you import on most projects?

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#352

Post by 8bitsrule » Fri, May 27, 2022, 9:16 PM UTC

blenderdt wrote: post #186

hudo wrote: post #81

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tuto…

Not only this. Try to change the app two years later. Dependencies gone, wrong NPM version, Webpack config depricated and what not. That's why I like to use vanilla JS as much as possible. It will be maintainable years later.

And even then, browsers will probably respond differently.

After a recent FF upgrade, it balked at JS that worked fine for years ... on occasion, not always ...because: navigator.onLine === true, internet.connection === false.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#353

Post by meragrin_ » Fri, May 27, 2022, 9:27 PM UTC

alexb_ wrote: post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

> Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at.

Sorry, no it does not. It shows me a lot of people are perfectly competent but lack the motivation or proper expectations. Once the person gets more into the data analysis, I'm sure they'll realize why tutorials just don't show how to do data analysis.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#354

Post by jhgb » Fri, May 27, 2022, 9:33 PM UTC

atemerev wrote: post #109

mattlondon wrote: post #95

Earlier quoted context omitted.

If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools. Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to d…

Oh, there is another way to code with JS on the server side? Something else besides node?

Deno, as someone mentioned. Also, Civetweb embeds Duktape. Also, txiki.js embeds QuickJS. So there's at least three other options with varying features. You should try Deno first, though.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#355

Post by lucideer » Fri, May 27, 2022, 9:49 PM UTC

jeroenhd wrote: post #200

lucideer wrote: post #146

The author encounters four problems trying to approach a programming task: 1) A problem common to every programming language (feature introduction/deprecation compatibility conflicts w.r.t. import/require) 2) A security issue around browser filesystem access (not-JS related at all: HTTP content-type sniffing) 3) A usability issue with the VSCode IDE (not JS related) 4) A bug in a single JS module Concludes this is al…

One thing in particular I hate about Javascript's platform is how much time you have to spend on learning the ever-changing tooling. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going. The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended…

Hard agree on JS tooling.

This is largely centred on browsers these days (ironically it used to be better for browsers and worse for server, now it's the opposite).

However I'll say two things in javascript's defence:

(1) No other language has yet taken on supporting server and browser environments simultaneously: it's unlikely to be easy for the first.

(2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers

> The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore.

No idea what you're talking about here though. Is this about NPM? What 6 different ways? What tooling extensions? This sounds like vague projection.

> Python venvs and pip are easy enough to understand

If only "understanding" was near enough. Good luck putting together a robust unattended install routine for anything python: does the user have existing venvs, should this script create a new one, where?, how should the user easily init it?, should it be a global init??, autoinit via bash or shortcut via bash alias? What about Elvish? What about fish? What about ...

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#356

Post by jeroenhd » Fri, May 27, 2022, 9:54 PM UTC

lucideer wrote: post #355

jeroenhd wrote: post #200

Earlier quoted context omitted.

One thing in particular I hate about Javascript's platform is how much time you have to spend on learning the ever-changing tooling. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going. The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended…

Hard agree on JS tooling. This is largely centred on browsers these days (ironically it used to be better for browsers and worse for server, now it's the opposite). However I'll say two things in javascript's defence: (1) No other language has yet taken on supporting server and browser environments simultaneously: it's unlikely to be easy for the first. (2) I have a strong suspicion it'll get much much easier one Nod…

> (1) No other language has yet taken on supporting server and browser environments simultaneously, it's unlikely to be easy for the first.

ASP.NET has allowed you to write purely backend code and add interactivity forever. Of course you can't get around JS in the front-end, but a mix of backend and frontend code existed long before Node got any popularity.

> (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers

I agree. Then again, the Node ecosystem always seems to be moving from one standard to another.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#357

Post by WorldMaker » Fri, May 27, 2022, 10:06 PM UTC

mattlondon wrote: post #42

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recen…

> I've never heard of people putting typescript into a .js file - is that some node thing?

Node won't load TS files by default at all. You need complicated plugins like ts-node and few people know/setup ts-node, and I believe ts-node still expects Typescript code to be in TS files. It's likely accidental babel "bleedover" in that at this point even non-Typescript babel presets will strip Typescript types without warning.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#358

Post by lucideer » Fri, May 27, 2022, 10:12 PM UTC

cxr wrote: post #209

lucideer wrote: post #201

Earlier quoted context omitted.

> Those speedbumps used to also not be there—they were put in recently > having read through your comment It doesn't sound like you've read my comment at all: 3 of the problems I listed are not new at all. The one that is - modules - is a result of two colliding independently standardised implementations from one language (commonjs vs ecma). > The module fiasco is 100% a consequence of really, really bad decisions on…

> It doesn't sound like you've read my comment at all Well, I did. > I'd genuinely like to hear an elaboration on this. You already alluded to it. NodeJS's take on modules (which are not CommonJS[1]) were never a good idea, and they were never standard, least of all in any sense that matters. Too many people treat the NodeJS project and its associated silliness like it's the be-all and end-all of "JS". It's not. It's…

In terms of early days serverside JS, I was mainly a Flusspferd user (outside of earlier Rhino & lots and lots of awkward XULRunnering), so I do get where you're coming from. Node was absolutely the mainstream enemy in the early days, and for me strongly represented the antithesis of what the ecosystem should become, including CommonJS.

But that battle was lost and at this stage Node realising late is so so much better than Node never realising at all.

It's also such a familiar story across ecosystems. Node gets all the flack because it's the browser-similar language platform and browsers have been where it's at for a long time (and will continue to be). That's neither a flaw nor an asset though - other ecosystems deal with very large (different) problems despite not having as many challenges to overcome as JS does.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#359

Post by masswerk » Fri, May 27, 2022, 10:18 PM UTC

jeroenhd wrote: post #207

masswerk wrote: post #51

Earlier quoted context omitted.

Now this inspired me to the great idea that we all should move to microservices in the browser, running as concurrent background tasks along a managed message bus, as soon as possible… (Functional programming and modules are dead, browser microservices are the future! We may even launch our web app in a fleet of redundant windows/tabs, by the this greatly improving stability!) ;-)

Write a system of service workers intercepting each other's HTTP requests and I think you can do it!

Also, include WebRTC for distributed remote partitions! (For redundant peer to peer backup, call your Ma and ask her to join your session as a distributed backup peer. If your computer dies, she'll still have the data. Now she really shouldn't close that window until your gear comes back from service…)

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#360

Post by WorldMaker » Fri, May 27, 2022, 10:19 PM UTC

MCArth wrote: post #49

mattlondon wrote: post #42

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recen…

I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export on…

I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too).

It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around.

It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in.