Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lea.verou.me

Post reply on HN
Print view View original

281–290 of 391 posts

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

#281

Post by fendy3002 »

donatj wrote: post #270
fendy3002 wrote: post #263

Earlier quoted context omitted.

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with…

> It's literally the name itself "node"_modules, it's designed to be used with node. That’s the problem . It’s not JavaScript. It’s not any part of the ECMA standard, it doesn’t work in runtimes other than node (read: the browser) yet it lives in the .js files making them not truly JavaScript. You have split the language. The syntax isn’t part of the language and was designed in such a way that it cannot be polyfille…

If anything, it's not the fault of javascript, it's on node. However finding the popularity of it means that somewhat it's more suitable for many devs than the alternatives.

Well I can understand it. As I've used the previous generation of jQuery, knockout, etc, nodejs and it's tooling makes things easier to scale, even with bigger overhead cost.

EDIT:

> That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.

Copy, make it run well, modify, learn is how I learn things. Without working example, it's magnitude times harder to learn something. The fact that people copy and use without trying to understand things is their fault, not the hundreds of boilerplate code.

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

#282

Post by moochmooch »

jiggawatts wrote: post #56
gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attac…

whinging about supply chain security is the bikeshedding topic of 2022

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

#283

Post by fendy3002 »

marpstar wrote: post #269
fendy3002 wrote: post #263

Earlier quoted context omitted.

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with…

Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.

Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.

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

#284

Post by moochmooch »

halfmatthalfcat wrote: post #240
AgentME wrote: post #100

Earlier quoted context omitted.

+1 for Deno. It seems like it's taking the good ideas that developed from the node+npm ecosystem while filing off the unnecessary complexity that's accumulated in the ecosystem over the years. I've worked with node+npm+typescript/babel/webpack/etc for years and know the ecosystem pretty well, but I get apprehensive when thinking of starting a new project with it because there's such a deluge of not-very-meaningful ch…

Why not just use ts-node and be done with it?

ts-node introduces its own bugs and ergonomics inconsistencies on top of node. I've used it on multiple projects in the past and ended up removing it as a dep when I've been able to.

Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.

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

#285

Post by AlchemistCamp »

woojoo666 wrote: post #38
michaelsalim wrote: post #8

Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful. Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.

The compatibily issues with NodeJS dependencies (aka CommonJS modules) and ES6 modules is one of the most painful parts of Javascript today. But at the same time, I wonder if it could have been avoided. Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it. So it's understandable that NPM made some mistake…

> Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it.

They drew a lot of inspiration from the Ruby ecosystem and its gems. It was even a lot of the same people contributing. Somehow, they ended up with a much worse tooling story, though. I think a lot of it stems from the browser/server divide they had to contend with and the worse common library.

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

#286

Post by moochmooch »

wrp wrote: post #168
aahortwwy wrote: post #116

Earlier quoted context omitted.

This just isn't true, though. I have quite a few non-technical colleagues who know just enough Python to Get Shit Done. My father (a writer) taught himself R for research purposes and is productive with it. Universal Paperclips has a super-basic JavaScript codebase[0] but was a really popular game. Thing is, if you search "how to do X in Python" you're going to get a bunch of resources aimed at professionals because…

But are they building software tools that are useful and stable enough to distribute? That's the level of capability he is talking about.

That should not be the litmus test for writing software. Lots of software can have 1 user, yourself. Stability and ability to distribute be damned

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

#287

Post by [deleted] »

gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

[deleted]

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

#288

Post by tyingq »

gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.

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

#289

Post by jcalabro »

synthmeat wrote: post #50
rat9988 wrote: post #46

Earlier quoted context omitted.

My old go code doesn't compile anymore with the newer compiler versions

What was it that broke it? Usage of unsafe? Security and bug fixes in the compiler/tooling? Just interested.

The Go 1 promise[0] says that the language spec and set of core libraries will be backwards compatible. I maintain a few dozen go projects, some of which are 10 years old, and while upgrading from i.e. 1.4 -> 1.18 has been relatively easy, it definitely has not been zero work. There are changes in the tooling, dependency ecosystem, deprecated dependencies that should be replaced, runtime behavior differences, things like that. But the language itself and stdlib is totally stable.

[0] https://go.dev/doc/go1compat

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

#290

Post by the__alchemist »

krapp wrote: post #273
the__alchemist wrote: post #265

The examples in the article are all realistic, but I'd like to add something important: This is using the NPM ecosystem and JS dependencies. A language's tooling and ecosystem are arguably part of the language itself for practical purposes. So, the article is a fair assessment. I'm making this distinction because you can use JS in what it accels at without invoking build tools and dependencies: As an imperative langu…

> I'm making this distinction because you can use JS in what it access at without invoking build tools and dependencies. Theoretically, yes. Practically, no, because almost all javascript code is written in typescript, packaged into modules and distributed on NPM nowadays. There's the tiniest inking of a "vanilla js" movement out there, but otherwise all of the libraries and tutorials and advice assumes that ecosyste…

https://developer.mozilla.org/en-US/docs/Web/JavaScript

You don't need any of those to invoke client-side UI changes.

Post reply on HN