Live data from Hacker News

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

lea.verou.me

361–370 of 391 posts

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

#361

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…

Regarding point 4: more people need to realise picking the right NPM package in the JS ecosystem is becoming a "must-have" skill, but the only way to find the right package is still to be constantly up-to-date with the ecosystem, endless google searches or hoping someone on Twitter can just tell you what's better. This is why I built https://pkg.land/ (beta), append NPM package name to the url and a list of alternati…

FWIW, I work in security and this skill is becoming very well automated in that domain.

It's imperfect (and always will be), but there's a large overlap between manageable libraries and securable[0] libraries.

[0] In the software-composition analysis field, "securability" is not only about upgrading vulnerable libraries but also about how many vulnerable transitive dependencies you may have to upgrade in future.

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

#362

Earlier quoted context omitted.

> Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day? They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification. Normal exceptions for languages that have a spec based on a reference implementation.

That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation. V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno. Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8. The Ecma International is basically…

JS isn't supposed to have only one relevant implementation, though, and still has two active implementations (SpiderMonkey). (And up until recently usually had at least three active. RIP Chakra.) That's absolutely a bug in the ecosystem that the Chromium hegemony has bullied its way into near monopsony.

It's good of Ecma International to keep standing up to that. It's better for the web.

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

#363
post #329

Earlier quoted context omitted.

The language has a standard library fit for its intended purpose - scripting the DOM. Moving javascript out of the browser and trying to use it as a one-size-fits-all replacement for everything from systems to application programming, and every language from C++ to Java, is the original sin. Stop complaining because Brendan Eich's toy scripting language isn't a good replacement for things it was never meant to be use…

Given how many front-end packages are on NPM, it's obviously not the case that the libraries provided were sufficient for scripting the DOM. Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. I have no particular love for using JS as a language to power everything from IoT devices to web servers, but it doesn't really matter how I feel…

>Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure.

Why should the language provide that? What other languages provide an equivalent to that? left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website, because HTML has tables, CSS and other elements for that.

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

#364

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…

The problems are all eminently avoidable, though. It's all death by a thousand cuts stuff. 1. Churn in something as basic as how modules work isn't common to every programming language, actually that's pretty specific to JavaScript. Java modules remained the same for 20 years, and when the 'new' module system came it's opt-in (you can pretty much ignore them and many people do because a 'new' module is forwards compa…

> They were only trying to use the browser because they had problems with Node

(a) not problems with Node, problem. Singular. (the most common and well-documented problem with Node.) Which they made no attempt to resolve and just gave up on. Immediately.

> The fact that there are security issues loading stuff written by the owner of the computer itself from disk is more an artifact of how browsers work and how they evolved than anything else.

That was... precisely my point? So... nothing to do with JS.

> The usability issue wasn't really with VS Code. It's that the default behavior of browsers

Please re-read the gp as this isn't anything related to browsers. It's just a UI feature around display of folders. FWIW Github has the same (quirky, bad) feature in its directory navigation.

The "bug" here is that you can't use TypeScript directly in a browser (why not? again, mostly complicated browser related tech politics that no beginner would understand)

Oh my. It's not politics it's just age; TS is new. JS is OG. That's all there is to it here.

Putting aside any question of whether you might think browsers should adopt TS (agree), even if they did it would still have a different file extension.

The bug here is it's Typescript code with a JS file extension. TS is the file extension for Typescript. That's broken code no matter what way you frame it.

> He's introduced as "a great computer scientist"

Well colour me thoroughly unconvinced.

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

#365

Earlier quoted context omitted.

That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation. V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno. Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8. The Ecma International is basically…

JS isn't supposed to have only one relevant implementation, though, and still has two active implementations (SpiderMonkey). (And up until recently usually had at least three active. RIP Chakra.) That's absolutely a bug in the ecosystem that the Chromium hegemony has bullied its way into near monopsony. It's good of Ecma International to keep standing up to that. It's better for the web.

> JS isn't supposed to have only one relevant implementation

I mean, alright, but the way things are supposed to be doesn't have any bearing on the way things actually are. And if you plan based on how things are supposed to be instead of how they are, you're going to experience a lot of pain.

> It's good of Ecma International to keep standing up to that.

In what way are they standing up to it? By keeping things in/out of the spec? My claim here is that the spec doesn't matter. If chrome implements something, people will use it, even if it isn't in the spec, and just let things break in other browsers. If chrome doesn't implement it, people won't use it, even if it is in the spec. You don't see poly-fills for chrome.

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

#366

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…

Oooooh did you just call Frank Lantz super-basic kek

I think he's a good contrast to the "great computer scientist, but not a JS person" in the linked article.

He initially built Universal Paperclips to learn JavaScript. It's a cool thing, a lot of people played it, and it doesn't rely on an incomprehensible ecosystem. It's two HTML files, four scripts, two CSS files, and an image.

You don't _need_ all the stuff people complain about to do cool things with JavaScript. Especially if you're just getting started with the language.

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

#367

Earlier quoted context omitted.

Oooooh did you just call Frank Lantz super-basic kek

I think he's a good contrast to the "great computer scientist, but not a JS person" in the linked article. He initially built Universal Paperclips to learn JavaScript. It's a cool thing, a lot of people played it, and it doesn't rely on an incomprehensible ecosystem. It's two HTML files, four scripts, two CSS files, and an image. You don't _need_ all the stuff people complain about to do cool things with JavaScript.…

I agree. You just need to actually be a good designer :) When you have a fun and clear vision for what you want to build, it's hugely motivating and you're way more likely to finish

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

#368

Earlier quoted context omitted.

> Best I could tell, neither of them looked, at least not more than a minute. I once interviewed a guy with a nice, short 1-pager résumé—not from lack of experience, just a solid, terse document. Not just out of school. Had three or four tech jobs in his history. He listed one research paper near the bottom, that he'd co-authored in grad school. I found the paper, skimmed it, and asked him about it in the interview (…

My resume is quite similar. On the bottom, I have a link to something that I'm quite proud of under a small heading titled, "Ask me about it!" I've been interviewing passively / casually for the last 18 months. I've spoke to a couple dozen different organizations in that time. I've had exactly 1 person ask me about it. I've thought about removing it from my resume with the thought that maybe people are just put off b…

Put off? Or lazy? At the end of the day the relationship comes down to "fit". Time and signals are very limited. A bad decision by either party is costly in a number of ways. You threw them a softball and they...couldn't be bothered?

Moi? I'd leave it. Them not looking tells as much as if they do.

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

#369
The author has zero experience on JavaScript or the ecosystem and complaints how difficult it is to use a random library god knows who wrote it.

This would have been a problem on any ecosystem, even more, trying to do something for the first time in life is difficult whatever it it is.

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

#370

I'm mostly a designer and I've been trough the same experience trying to learn the ropes of modern ES6 javascript development and this matches my experience fully. On the same note, it took me days to wrap my head around: - The small differences managing modules ( even simple stuff like inclusion paths using "~" vs "node_modules" vs ../node_modules" vs...) between build environments (Webpack vs Parcel vs ...) or even…

Personally, for the last point, I just use a disable CORS extension on my browser for local dev work, and any http-server.
Post reply on HN