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

61–70 of 391 posts

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

#61

Post by quickthrower2 »

I think they (as in author and the friend) need some expectation adjustments about how easy it will be to get some random code package published for free on the web to work, regardless of the programming language.

In other news I am quite annoyed by the confusing range of hardware and how difficult they make it to bolt a fencepost to a wall: There are masonry bits, high speed steel, different sizes, different anchors. And then getting the right length screws. I seem to do it all right but the post keeps slipping out.

Eventually there will be dropbox-like disruption of both node.js and diy hardware, but until then just do the normal 10-20 hours of mandatory training (like udemy courses) to get the basics down.

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

#62

Post by mattlondon »

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 guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things.

It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.

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

#63

Post by alexb_ »

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 at. And this issue would have never been solved for normal people - the only reason this barrier was ever breached for this person was due to their large twitter following. Most people don't have that luxury.

So, if you think it's hard for someone who is already a programmer - think about how needlessly complicated the entire ecosystem and everything surrounding it is for the average person. It's no wonder many people basically view anything past the surface level of computers as dark magic, and we call people good with these magical devices "wizards".

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

#64

Post by mattlondon »

cutler wrote: post #48
wrnr wrote: post #5

Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.

But Deno is incompatible with npm, no? Deal breaker.

https://deno.land/manual/node#interoperating-with-node-and-n...

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

#66

Post by whostolemyhat »

mattlondon wrote: post #62
MCArth wrote: post #49

Earlier quoted context omitted.

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 guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual -…

> why should ECMAscript care about what node does?

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?

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

#67

Post by an1sotropy »

MCArth wrote: post #52

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.

Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something?

Sure the interoperability between things that do and do not (pure ES6) require a build/bundle/whatever, and between JavaScript and TypeScript may remain an engineering challenge, but that's not for the ES6 modules spec to solve, right?

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#69

Post by mattlondon »

whostolemyhat wrote: post #66
mattlondon wrote: post #62

Earlier quoted context omitted.

I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual -…

> why should ECMAscript care about what node does? 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?

The same could be said about individual browsers. With web standards there is precedent for doing the "right" thing rather than just going along with whatever one product has already implemented and calling it a standard.

E.g. there were recent posts here on HN about WebSQL (already implemented in Chrome so many hundreds of millions of users) being replaced by a design agreed upon by all interested parties rather than just what Google wanted for Chrome and Gmail. Indexdb may not be what everyone wanted of course, but that is beside the point.

There is a place for experimentation and trying stuff out, but just shipping something first shouldn't mean you get to dictate future standards or be guaranteed backwards compatibility or a zero-effort upgrade path. Standards should learn from and build upon earlier implementations and mistakes. They should not be slaves to what has gone before.

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

#70

Post by thegeomaster »

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…

But the problem is, JS has been in a transition from some X to some Y for the last 10 years.
Post reply on HN