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

81–90 of 391 posts

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

#81

Post by hudo »

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 tutorials (unofficial blog posts) on internents, none of them work. Front end dev work is broken.

Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.

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

#82

Post by hyperpallium2 »

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…

It is unique to old languages.

Young languages are easy to get started in. Ruby used to be.

Though ruby has a separate problem of breaking changes. The back-compatibility crowd can run old code (e.g. java), but at the cost of their soul.

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

#83

Post by Gigachad »

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'm also sympathetic to the author but don't really see it as a problem. NPM modules are not apps on the App Store. They aren't intended to just be run by regular people quickly. The steps described in the article show someone hitting Node.js with a hammer until it gets closer to doing what they want without any understanding of what is going on. Which is fine, that's what people do often, but it isn't a failing of the tools when this doesn't work.

I don't expect to walk in to a workshop and find the welding tools intuitive to use with no training, and I don't expect npm modules to be intuitive to an outsider either.

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

#84

Post by AltruisticGapHN »

We just need all this tooling to go in the browser.. which is where it always belonged. That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly.

As for my own rant, simply the fact that Microsoft, of all places are the ones who run TypeScript and now the proposal to add TS to native JS.. is part of the issue. MS has zero imagination.

JS needs native typing and it shouldn't be done by MS, and it should be a limited subset of TS with no particular intent to be compatible with MS's TS. Then and only then JS becomes its own thing again.

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

#85

Post by Gigachad »

IshKebab wrote: post #77
quickthrower2 wrote: post #61

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…

I disagree. I've never had issues of the magnitude of JS's mess with random free code written in Go or Rust. I think the reasons for it in JS's case are kind of reasonable though. Just annoying that it's taking so long to sort out.

I have had plenty of issues trying to get packages from Rust working. Half of them depend on external libraries and its up to you to work out what package for your distro satisfies the compile. And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult.

I don't blame any of this on Rust. You can be expected to be proficient in the tools as these are not end user products designed for someone with no training.

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

#86

Post by lbriner »

RedNifre wrote: post #68

Isn't it like this with most languages? The only exceptions I can think of are Io and Go (I heard that Rust also works, but I haven't tried that one).

Yes it is to a lesser or greater degree.

I guess a lot of languages struggle with the balance between Communism and Dictatorship. If you allow genuine communism, people don't agree on things, stuff gets built to different levels of quality, some of it maintained better than others etc. You end up with the problems we see in lots of package management.

On the other hand, if you have an individual or team who dictates how stuff gets developed, what is an acceptable level of functionality, getting rid of stuff that is not maintained etc. then it is possible to build a much more reliable package management system but perhaps get less people getting involved because they can't just offer what they feel like but only what is accepted!

I think some languages suffer less because they really invested in the standard library including a tonne of stuff avoiding the need for external packages. .Net, Go and Python are like this I believe.

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

#87

Post by bborud »

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…

You are probably right, but there are differences. Languages like Go and Rust are much easier to get started with since they have better tooling, and more importantly, the tooling has a smaller and more regular surface. This is immensely important. Granted, they occasionally have unnecessary and stupid quirks, but they tend to be small (in terms of cognitive footprint) and contained.

In my neck of the woods, Python is the major source of time spent trying to get other people's code to run on my machine. The path of least resistance for Python developers tends to produce code that requires you to go through an easter egg hunt to make it run outside the original author's machine.

Yes, you could write Python utilities that are easy to install and run, but people don't. And the last bit of that sentence is the one that actually counts. "Could have" doesn't actually count in an engineering context. If the consumer has to assemble and repair software before getting it to run, the developer isn't being very professional.

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

#88

Post by kaoD »

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…

> needlessly complicated

IMO this is unfair characterization.

If using Photoshop is driving, programming is building an internal combustion engine vehicle. You cannot expect to just randomly google for car-making tutorials and get an SUV done in a weekend. Heck, you can't even expect to be able to build a very simple combustion engine from basic principles without a lot of study.

I'm not saying this is Aella's fault or anything, it's fair to have wrong expectations, but calling this "needlessly complicated" is not fair either.

If I had to take something away from that Twitter thread is how marvelous is that someone without any programming experience has been able to programatically manipulate CSV data in a couple of days.

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

#89

Post by qwertox »

This is exactly my issue with all this modern JavaScript / Node-stuff.

The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow.

Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.

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

#90

Post by laputan_machine »

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.

ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-mostly dev since 2013, and I've had enough of ESM ideologues.

See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.

I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.

ESM _is_ the future, but not the present, and I wish people would stop foisting it on packages before its ready.

Post reply on HN