Live data from Hacker News

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

lea.verou.me

331–340 of 391 posts

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

#331
post #329

Earlier quoted context omitted.

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the…

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 about it. It's not going anywhere.

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

#332
post #162

Earlier quoted context omitted.

It is not quite hard to learn actually. You just need to go through the webpack Concepts section[0]. Documentations in the JavaScript ecosystem are quite good and explanatory compared to other languages (like Java). Not every front-end developers learn the internals of the tool they chose, like create-react-app. Most of them settled down if the solution "just work". [0]: https://webpack.js.org/concepts/

X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not…

Webpack can be rather complex but that's because you can do a lot with it. It's not really any harder to learn than any other piece of software and the person you were replying to is correct in referring to the official documentation. If you go through the official tutorials you will come out the other end knowing perfectly well how to configure it from scratch.

If you don't want to dedicate a few hours to learning Webpack and your goal is to just set up a basic React + Typescript app then I'd strongly encourage using an opinionated bundler that provides standard templates for setting up such a project. Vite is very good for that https://vitejs.dev/guide/#scaffolding-your-first-vite-projec... you should be able to just type a few lines in the shell and be up and running.

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

#333
post #112
post #88

Earlier quoted context omitted.

> 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…

I feel a bit of this every time there are pushes to get everyone to code, it's very weird. Sort of related is the expectation that you should just be able to switch into a programming career in a few weeks. You can't do that with almost any other meaningful career but for some reason you "should" be able to for programming and there are very profitable businesses selling the lie that you can.

I agree, the expectation of everyone being able to switch to a programming career is of course ridiculous. Neither should this be the expectation nor should everyone actually get into a programming career. Better to leave that to the professionals, who have chosen this path and have the necessary education to avoid building in the typical traps. Learning programming can take a week, but mastering it may take a lifetime. Just the fact, that a person can write a little bit of code, does not mean, that it must become their profession.

However, I do think, that people should be able to make use of the tools they have. Learning a little bit of programming can get people going a long way and there are so many learning resources out there, that you can learn more any time you want. (Of course tutorial hell is a thing.) We really should encourage people to become computer literate and to become enabled. There is no reason to keep our knowledge from people.

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

#334

Earlier quoted context omitted.

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the…

I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems…

> do you expect any Lua to run in every environment Lua is used in?

I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file."

I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this.

What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify.

Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.

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

#335

Earlier quoted context omitted.

Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit. Also Parcel is easier by a factor of 10, skip Webpack entirely.

>Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit. So it isn't hard - it's just not easy and it's time consuming. Wait, what?

Correct, I deal with "difficulty" as a spectrum. The consensus so far here seems to be that this is "hard". I disagree, I think it's not "easy" but surely not "hard" either. Somewhere in between, leaning closer to "easy".

Mostly it takes the willingness to learn and patience to recognize that it's a whole class of knowledge, separate from actually writing a javascript app.

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

#336

Earlier quoted context omitted.

For me esbuild has worked pretty well. Given a index.js as the entrypoint for your app: npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm esbuild is also pretty quick and does not have a lot of npm depencencies thanks to being a go binary. npx should download and run the binary for you and npx is almost always installed with node automatically.

Thank you. It was really hard to figure out which tools even could do this so I knew which one I ought to deeply "RTFM" for, which was really frustrating to me because it seemed like the most obvious default behavior for any JS build/bundle tool, which should be what it did if you just typed "some-build-tool build" or "bundle" or whatever, from your project root with nothing but a package.json containing a "main" ent…

I agree that this is really not a good experience. I prefer js projects that don't rely on build tools at all for this reason, but most devs, frameworks and libraries don't support such a use-case.

When I have to use build-tools I usually go for esbuild.

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

#337
post #210
post #208

Earlier quoted context omitted.

You can still do a webpage just like you did 20 years ago, inserting a couple HTML tags in a notepad. Now the scope of what a webpage is capable of is infinitaly larger, and so is the complexity required for using all the new possibilities. If you want to use advanced stuff without learning the basics, than of course you're going to have a bad time.

> You can still do a webpage just like you did 20 years ago, inserting a couple HTML tags in a notepad. Yes, I agree. That's exactly what I said in several parts of my message. However I believe you missed the point and didn't notice the sarcastic tone.

Perhaps expecting readers of a message board to pick-up on your sarcastic tone is not going to be an effective way to communicate your point.

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

#338
post #228

Earlier quoted context omitted.

Not to be an ass, but playing with css and html isn't programming. At all. It's making web pages. The web is so universal today that many people conflate "making web pages" and "programming". And there's nothing really wrong with that _if your goal is to learn to make web pages,_ but I'm pretty sure there are still more than a few people out there who want to solve problems with code, or just learn to code, with litt…

>Not to be an ass, but playing with css and html isn't programming. At all. It's making web pages. ... except you can literally make desktop and mobile applications now by "playing with css and html"! ^electron -- shudder!^ Part of the reason for the JS mess (which people have been bitching about for years and years) is how easy it is to dip your toes into. Match that with how easy it is to create a "gui" now with HT…

There's a whole lot more to Electron than HTML / CSS and getting started with it is honestly a huge PITA, in my opinion. This is coming from someone well versed in full stack web development who has delivered substantial projects.

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

#339

Earlier quoted context omitted.

X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not…

Webpack can be rather complex but that's because you can do a lot with it. It's not really any harder to learn than any other piece of software and the person you were replying to is correct in referring to the official documentation. If you go through the official tutorials you will come out the other end knowing perfectly well how to configure it from scratch. If you don't want to dedicate a few hours to learning W…

This works until you need to have one tiny thing different than the standard path, that a tool implements. Usually the problems come, when you do not want to do the thing "everyone else" does, but want to avoid some downside of that mainstream approach.

The contrast is other programming language ecosystems. Once you understand how they look up modules from which to import things you need, you are set and can deliver a working program. Not so in JS. Multiple half backed module systems and for a long long time no proper support for modules in the browser, so that things like requirejs had to be shipped, in order to have modules working. All of that is a huge crutch and hack. Also it is mostly unnecessary. It is not like JS apps do sooo much more than traditional desktop apps. It is their dependencies, which make the load big. That in itself is a problem, which then creates the problem of "Oh I must minimize my JS files!" and that creates the need for a tool and then we get to a place, where we have things like webpack, which you configure for a day and no guide does exactly what you want to do in your project. You might even find out, that webpack cannot do what you need it to do, because of being "opinionated". Then you might look for the next tool and the cycle starts again. I have experienced very little of that nonsense in any other ecosystem. Most do not deal with the same problems, because they avoided getting into those problems in the first place and they do not have to deal with a badly designed language as a basis.

In the frontend development world you might even run into people integrating things like webpack into projects needlessly, say a plain JS project of a few files under 100kB, just because they always do, and because of silly project standards they have. In some way we were better off when JS was simply in a script tag and you had to put the script tags in the correct order. None of the webpack and similar tool overhead was there. Heck, those tools even seem to encourage people to include more and more stuff into their projects, because they think, that webpack and similar tools will magically fix it all and make all their code small in size when delivered. Over time this grows into multiple megabytes bundled minified unreadable JS crap.

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

#340
post #337
post #210

Earlier quoted context omitted.

> You can still do a webpage just like you did 20 years ago, inserting a couple HTML tags in a notepad. Yes, I agree. That's exactly what I said in several parts of my message. However I believe you missed the point and didn't notice the sarcastic tone.

Perhaps expecting readers of a message board to pick-up on your sarcastic tone is not going to be an effective way to communicate your point.

I believe I did fine conveying it. The last paragraph makes it pretty clear I know there are other solutions. The problem with the reply wan't the sarcasm, but not reading the whole message.
Post reply on HN