I had a similarly frustrating experience when I first set up Python to use Django. The complete mess that is the Python 2/3 split (thankfully somewhat better now after many years), trying to figure out what the hell pip and pipenv were (this was before I was familiar with package management).<p>However, I initially learned some Python in university and I liked it then. We just installed Idle and ran some simple scripts, and everything worked. That's the right way to learn a language. If you dive straight into JS package management, you are attempting to learn multiple things at the same time:<p>* Node.js environment<p>* Browser environment<p>* JavaScript syntax<p>* 'running a localhost'<p>* JavaScript modules<p>* NPM package management<p>You need to tackle these one by one. If you do them all at once, even with prior experience in other languages, of course you're gonna have a bad time.<p>Really what I take away from this post is that the author is a bad teacher, although the experience of her student is probably similar to what many people experience when trying to learn by themselves.<p>There are many improvements that could be made to the JS ecosystem, but this post does not do the current state justice. What it highlights, if anything, is a problem with the available of a standardized learning path. But I'm not sure what the solution to that would be.
"Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on.<p>The other day I wanted to publish a little script I've been maintaining for years as a module easily usable by WebPack and whatnot, and that's much easier said than done. I published it on npm and put some UMD magic thing in there, and I <i>think</i> it should work now ... but I'm not really sure to be honest (still need to look at this and confirm).<p>Just searching "publish JavaScript module" and trying to make sense of the WebPack isn't really all that helpful, not for me anyway, as I'm joining half-way through season 6.<p>I have no opinion on the tooling <i>as such</i> – I lack experience to have an informed opinion – but it sure is confusing to "quickly" do something for people who are not heavily involved in it (i.e. me)
> just run it in the browser<p>Yikes. I really do not think that was the solution to this problem and only added a ton of complexity.<p>JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. This tooling (dev server, webpack) builds on other tooling (node, babel, typescript) which is where all this complexity lives.<p>Furthermore, some packages are not worth installing and if you run into issues with that package, then try something else. We have no information about the package they tried to install and since the JS ecosystem encourages people to publish to npm for virtually anything, this is one area where you really have to be careful.<p>The lesson here is the same lesson with installing something like left-pad: be careful what you install and read the source code to understand what it is doing. Most of the time, these packages can be inlined easily. Just because a library exists, doesn't mean you should use it. Most of the time for JS I'm reading the library's source code to see if I can a) inline it or b) use it as inspiration to build specifically what I need.
The module syntax inconsistency situation is atrocious but we're gradually making the transition. Now that we have a clear destination, I suspect it will be a non-issue in a few years. Projects like Deno and Pika are accelerating/papering-over the transition.<p>I've been working in JS for years and I've <i>never</i> encountered a module containing a typescript file with a .js extension... That was extraordinarily unfortunate. I don't think I've encountered a module containing Typescript at all. Correct practice is to build to JS and include the optional type declaration files. In my experience people are pretty good about that.
I just don't use Javascript, for precisely this reason, ever. Nothing is worth the hassle - no fancy libs to do spacing, or anything.<p>This is not progress - as someone who has been professionally programming for 30+years, this state of affairs is atrocious. Its the equivalent of buying a 5-bedroom house for your kids to grow up in, only to go in to your kids room after 20 years and realise they are insane and should be committed.
As a computer scientist who learned JavaScript this year, I strongly agree with the sentiment here. I feel like I often spend more time debugging module errors than my actual project.<p>Granted, once I understood the ecosystem more, I gradually began to grasp the reason these issues are around. But still, it does make it incredibly frustrating as a reasonably decent coder getting started in JavaScript.
It's become easier to build with hard-compiled languages than with interpretive ones. Interpretive ones shouldn't need "building", but they seem to acquire build systems anyway. Compile and link systems at least diagnose what's missing during the build process, not during execution.
I totally agree with the author here, but also would love to give some context since we have lived something like this before on Javascript IMHO:<p>Callback hell around 2015. It used to be that if you wanted to do something async you'd have to create a new callback. This led into callback hell[1], which was specially bad back then on the backend.<p>Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. There was some time where this was extra difficult because some code was using callbacks and some other code was using async/await, but it's almost totally solved in 2020.<p>Which brings us to the article on hand. This is probably one of the biggest issues, and a fake promise in Javascript right now: reuse code on the back-end and front-end. The front-end side has been using `import` for almost a decade with Webpack and friends but this was not easy on the back-end, so there was not a practical way of reusing the code in a project.<p>Luckily since <i>last year</i> Node.js supports import/export, and React supports it in libraries. It took a while because it was not an easy issue. I expect that more and more libraries will start to work only with import/export, and hopefully in 1-5 years this will also be a non-issue.<p>[3] <a href="http://callbackhell.com/" rel="nofollow">http://callbackhell.com/</a>
What experience DOES john have? I've had far worse experiences with ruby, python, scheme, clojure, java and C.<p>If you want a language that requires zero learning to use, I am sad to say that they are very far and few between. Sure, we have a clusterf*ck of a module ecosystem and interoperability issues between preprocessors but it isn't like that is a particularly novel problem either.
I'm a dedicated Javascript hater, but I don't think this is a Javascript problem. This seems to be how people (not me) have decided all software should be organized now.<p>I don't get it. I really don't.
I have hit a few of these myself and I have also hit similar needlessly complicated issues in a bunch of languages. This particular instance also suffers from the seam between Modern ES modules and legacy JS, which could be better.<p>Learning a language involves learning a bunch of non-language arcana about the environment, for no particular reason. Ideally you should be able to write the helloWorld equivalent for any platform and have a single command to turn that one file into a working program, but alas we have tool chains, configurations and requirements standing in our way. I don't think it has to be like that, but it all too frequently is. Deno seems to be making an admirable effort towards making a thing that just works.<p>Developing for Android or iOS makes the JavaScript experience positively direct.
I had very similar experiences with Rust and C++ lately.<p>In Rust, all I wanted is to play an audio file... failed.<p>In C++ all I wanted is to play an MP3 file... failed. With an hours of work I figured out how resources worked in Visual Studio and got a WAV file playing.<p>In Rust I installed a creative coding crate, it had 314 dependencies and the deps folder was 540MB. My openframeworks C++ project is 1.6GB after a bit of playing around in it :) But yeah, node_modules is heavy.<p>Bottom line is, when you are new to an environment and you aren't prepared to fight a battle, you will bleed out quite fast.
> But why do I… ok fine, I’m going to start a localhost.<p>Is "start a localhost" a generic term? If someone told me to do that, I would probably freeze in embarrassment -- no one has ever told me to do that in such context-independent terms. Since this was about node/JS, did John install express, or some other static file serving module? Or did he have an unrelated tool that makes this trivial?
Looks to me like a regular workflow and typical gotchas... ability to resolve this and similar is what pays the salary. Is Android, QT, Django, or Java development any more straightforward?<p>Anegdotally my perception is that people oftentimes think "It's just stupid JavaScript, let me paste it into HTML and run in a web browser, oh wait... why it doesn't work?!".<p>If you think it's confusing then add Angular to this tiny app (it's from Google so it must be good, right?).
So basically the entire series of issues can be rooted to the fact they're trying to run TypeScript code in Node/a browser. This doesn't seem like an issue with "today's JavaScript" but rather a symptom of either not reading the docs or the module not having good docs. I wouldn't be able to compile Java code with a C++ compiler.<p>Also that the package is published to <i>Node Package Manager</i> with only a TypeScript distribution seems very odd.<p>I do agree that the Node ecosystem could be easier to use, especially with the myriad of transpilers and build tools. But this doesn't seem like a very compelling anecdote to demonstrate it. Unless the point is that NPM package authors should not be able to publish their package in languages other than Node-flavored JS?
So, this doesn't seem to be an issue with JavaScript per se. The issue seems to be with the insane environment people have built up around JavaScript. Typescript, node.js, npm, etc. If the code really had been plain vanilla JavaScript that a person could use from an external JS file (just like we did for 20 years) then none of this would have happened.
My friend and I decided to start a project. This friend and I have had discussions where he espoused how libraries like Webpack, React, Redux, etc. just overcomplicate the web. I decided to humor him and do a "simple" stack of lit-html, vanilla JS and ES6 modules (since they landed in browsers). It took us maybe...a day to pedal that back? The first thing to go was doing ES6 imports in the browser. I forget the exact sequence of events but the MIME issue definitely showed up, along with maybe an untrusted source issue. Say what you will about Webpack, but native ES6 modules are definitely not here yet.
Anybody who's an outsider is going to hit stumbling blocks. It's your choice to feign ignorance or pick yourself up. A lot of languages have their peculiarities and JavaScript is no exception. Would "Today's <Language X>, from an Outsider's Perspective" look any different? Where X is a language that's at least 20 years old.
> John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.
> The End.
> Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?<p>The ones who don't give up on the first night will likely have more luck (try, try again).
I have done close to a decade of work in js, with jQuery in 2008, all the way to react and webpacker madness.<p>I hope someone builds a wasm based front end framework. I did a quick search and MSFT seem to be on it with their Blazor framework. Unfortunately, I am not in a hurry to go learn ASP.NET or C# anytime soon.<p>Maybe we need a frontend framework in Golang that compiles to WebAssembly. I am rooting for Golang here, cause after a decade in Ruby/Python/JS, I am really enjoying going back to typed languages.<p>But even a python/ruby to wasm web frontend framework will be awesome. Anything that keeps me away from node hell.
This resonates so much. I support some JS packages but I often wonder how anyone gets anything done in general on the JS side, and why people seem to accept the state of affairs. I'm spending most of my time with Ruby and it is night and day.
Seems like the issue here was a lack of documentation. Almost every npm package worth their salt details the various ways to get started with something along these lines:<p>- In the Browser:<p><pre><code> - Using Parcel/Webpack/Rollup.js...etc
- From a CDN
</code></pre>
- In Node:<p><pre><code> - Using CommonJS
- `const funcName = require('somePackage')`
- Using Native ES Modules
...etc</code></pre>
> Turns out VS Code collapses folders with only 1 subfolder, which is why we hadn’t noticed.<p>OMG. Decades of life in emacs (emacs!) would never have prepared me for a world where my editor would helpfully lie about the filesystem to me.<p>Yeah, this was horrifying to read. Obviously some of it is just normal churn, and all environments have their own oral histories and weird quirks. But... yikes.
This is so shitty and sad. I wish front-end dev could be more fun, with less pain, confusion and suffering. I'm losting the hope over the years about any browser stuff. :[
HTML/CSS/JS has been stretched so far beyond what it was originally designed for.<p>JavaScript’s tooling will only get harder to work with as we push it to handle more.<p>Eventually we’ll need to find something better than HTML/CSS/JS for developing in the browser.
I never really got the modern web app stack and Typescript/javascript compiling until I was forced to use it through Angular CLI. Then it sort of all made some sense. Having a defined structure in a complex stack helps novice people a lot.<p>Before that it was all open up index.html template and import my js files for my projects.<p>I am currently going through the same thing with Python/Django Rest Framework. Another fairly well defined toolbox that some wouldn't like - but it helps with learning good practices and you can lean on a community of developers that have thought long and hard about how things are well structured.
The problem is, these are the Node team's stated goals for ES Modules:<p>> It is worth mentioning that many of our design decisions were made with two primary goals. Spec compliance and Web Compatibility. It is our belief that the current implementation offers a future proof model to authoring ESM modules that paves the path to Universal JavaScript. Please read more in our documentation.<p>Sorry guys, those are the wrong goals! Just make CommonJS and ESM be mix and match interoperatable. ESM wasn't designed to be a local disk build system. Just have CommonJS behavior with ESM syntax for god's sakes.
Today's JS ecosystem reminds me of how people used to talk about Lisp: "Extend the language however you want, just write a macro!" And in practice that means there's a million little language variants floating around there; you can have different import semantics and language features and type systems and it's all glued together with a big pile of configuration and tooling.<p>Obviously this flexibility has been good for progress of the JS ecosystem as whole, but I hope the next 10 years are more sedate than the last 10.
If you are on an older version of node and want ESM, but don’t want to use .mjs, you can try:<p><a href="https://www.npmjs.com/package/esm" rel="nofollow">https://www.npmjs.com/package/esm</a><p>The package.json should have something like this if they are going to use import/export statements so anyone on older versions don’t have to worry about it (it’s not native to Node yet without .mjs extension).<p>We can blame whoever didn’t set that up, or the instructions should have been to just use require().
No offense to anyone, but this image wraps up how JavaScript, HTML and CSS looks from my (outsider's) perspective:<p><a href="https://www.desktopbackground.org/download/1280x1024/2013/02/25/536059_cat-riding-fire-breathing-unicorn-photos-for-desktop_1680x1050_h.jpg" rel="nofollow">https://www.desktopbackground.org/download/1280x1024/2013/02...</a>
"Lo and behold, a pile of unnecessary error conditions, cryptic errors, and lack of proper feedback.". Sounds like literally every initial experience I've had with a new language / library / framework (also, life in general tbh). Usually reduced by RTFM.
to echo others here, python ecosystem is worse imo. And compared to cross compiling C++ and C for ARM, js ecosystem seems like easy mode. You can always just write a little script to attach your module to the window, if you feel averse to webpack
I can sympathize with that. Actually I miss the times where you could just drop a script into your project and have it work and still change it if necessary without having 40MB of build time dependencies.
The JavaScript ecosystem was perfect before 2015. Everything just worked! Then either Hanlon's razor or sabotage. Instead of using the existing standard module system, a new module system was invented that was so alien to the JS ecosystem that now 5 years later it's still <i>broken</i>. I wish ES6 modules where reverted and removed from the JS standard.
Then the standard body not only completely changed the syntax of the language itself, but it also now requires a preprocessor/transpiler...
I feel like the tremendous popularity of node caused the development team to self-reinforce bad habits, but it’s just a theory.<p>I often wonder what the js ecosystem would look like with Google-working-on-Go levels of runtime and package management design discipline.<p>One would really think Google would do this, especially considering that Microsoft now has veto power over the npm repository and package format. Yarn was a huge improvement but is still dependent upon the same broken backend model.<p>AFAICT the success of the JS ecosystem is entangled with Google’s success.
Literally what I went through as well just trying to use a distance between two points module... I wish I was a cool front end kid.... but this type of experience is exactly what turns me off from front end dev
For years on I kept saying that Java is the worst language ever because of the tons of unnecessary boilerplate and it's "you're doing it my way or you are not doing it" approach. But over the last year I've come to realize that javascript has become much worse. A good engineer and community are identified by their ability to say "OK, you know what, this turned out to be a very stupid idea, let's start over and scrap this". However w3, mozilla, opera and every other organization behind js have turned into a full blown North Korean dictatorship and everyone who suggests that there should be alternative, they get chased down with pitchforks and never heard from again. And even if they have a constructive argument as to why everything that is going on is wrong. I'm sure that sooner or later this will bite back those organizations really REALLY hard. Basically we are in the baby boomer era of js - 30 children, 17 cars, all at least 6 liter v8's, hardly getting across the street without refueling, etc. And I'm betting that in a few years time they will be the web-equivalent of climate change and holocaust deniers.
Seems like this should be directed at the particular packaged and not the ecosystem as a whole? I do feel the pain of "I just want to try this out" and it's assumed I have webpack and all the other tooling already setup to do so, though.
All the hand-wringing over the difficulties of js just doesn't seem to track with the reality I live every day. I've been hiring engineers for years and <i>by far</i> the most common skillset comes in the form of contemporary js framework knowledge, especially among juniors. Ask them to debug a native app build and they panic like the output on the screen is hieroglyphics instead of a log of useful information that they can leverage to solve their problem. Many times they're so confused they won't even google the errors because they can't distinguish the error text from the compiler info logs, and that's working with swift/kotlin, I can't even imagine what things would be like if we had any c or cpp projects. This stuff just isn't that hard.