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

51–60 of 391 posts

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

#51

Post by masswerk »

moss2 wrote: post #37
mellosouls wrote: post #26

Basically: How it feels to learn JavaScript in 2016 https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... Original old-man-railing-at-modern-tech parody: https://circleci.com/blog/its-the-future/

That old-man-railing-at-modern-tech parody was a great read

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!) ;-)

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

#52

Post by MCArth »

I've 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 only an es module.

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

#53

Post by chii »

sullyj3 wrote: post #32
tarcon wrote: post #4

Chances are, the only thing interesting from that package is a single source file, which you could just copy over to your project.

I feel like the point of the article isn't so much "how do I solve this specific issue" as "this is the general state of JS packaging", and the solution you present doesn't work in the general case of larger, less trivial dependencies

But the thing is, the general problem of packaging is a complicated system, and the current solution developed are there to solve those complications (which adds more complications unfortunately).

However, the article wasn't about this general problem of package management. It's a problem of somebody wanting to test out some code, and went down the rabbit hole without understanding what they're doing (not a slight at them - it's hard to know what to do).

Ideally, you don't go down that route, because testing out some code doesn't require solving the packaging problem.

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

#54

Post by divan »

synthmeat wrote: post #45
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…

Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.

I recently had to work on a library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18)

It just worked.

And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off.

I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly.

That was as close as I could be to successfully complete 10 Years Reproducibility Challenge [1].

[1] https://github.com/ReScience/ten-years

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

#55

Post by xpmp »

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…

No post body was provided.

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

#56

Post by jiggawatts »

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 attacked us yet so no-one ever will[2]", "it's tracktable to untangle the dependency hell in your head because there aren't that many crates (yet)", and of course "we all know this history like the back of our hand, because we've all been around since v0.1 alpha."

I'm picturing "10 years later" when some junior developer at MegaCorp Inc desperately tries to figure out why the legacy Rust 2018 version he's forced to use in 2032 can't compile some privately hosted crate that's needed for an enterprise project. It'll probably depend on a specific version of a crate that was yanked because some transitive dependency had to be yanked because that guy was a Russian kid that sold access to this popular crate for $500 to Israeli spies. Of course now the patched crate requires Rust 2030 or whatever, breaking fifty seven of the two thousand transitive crates being pulled it, so good luck to him with disentangling that mess and making this work.

PS: I wish I was making this story up, but I basically just changed Angular to Rust for a real thing that happened to me, like... a month ago. There is no fundamental difference to how Rust does packages, it's just younger so the mess hasn't accumulated to Angular's levels of madness. Give it time...

[1] Except for that spat with the core team.

[2] That we know of. Ignore the guy spamming popular, single-word crate names and shovelling in 99.9% C/C++ code with the thinnest possible Rust wrapper. Surprise! Your code is now more C++ than Rust.

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

#57

Post by mojuba »

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…

I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift.

Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number of times various SSL libs are included in a single large and messy application), but it usually just works.

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

#58

Post by MCArth »

etamponi wrote: post #16

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard lib…

Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful.

Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!

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

#59

Post by astrange »

mojuba wrote: post #57
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…

I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift. Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number o…

MachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in).

Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.

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

#60

Post by emn13 »

franciscop wrote: post #34
bryanrasmussen wrote: post #17

I always go into these things hoping the outsider will be an Amish farmer or professional welder, but it always turns out to be just another programmer.

I know a construction worker, a recruiter and a mechanical Engineer, among other random professions, that moved to JS without much trouble. It somehow seems overwhelmingly that it's other fellow devs that have trouble with getting started JS. TBF right now JS is in transition from commonjs to ESM, and we all believe for the better, but this transition period does yield some strange issues like the article said, for i…

The difference likely is that they didn't do what these people did - try to use some package from scratch. It's much easier to take a sample and extend it, especially if you can join a team and hop onto their running, fully-fledged project.

The JS tooling story _is_ convoluted, and most people just don't touch that stuff, or when they do, they start from a working place, and just make small tweaks.

Post reply on HN