So accurate, and I’m glad Lea had the patience to put it into writing. I’m much more inclined to write off the entire ecosystem as some expletive.
This is generally why I push juniors towards learning Elm instead of JavaScript these days. There are so many edge cases in today’s JavaScript. So many inconsistencies. So much magic one just has to know. So much conflicting information and constant churn. I feel this pain every time a junior asks me for help with something that won’t work as they expect, which these days is effectively every day.
Juniors are surprisingly good at finding logic rules that are internally inconsistent in programming languages.
There’s been a push lately for people to write “simple Haskell”, and to be honest I think we more desperately need a push towards simple JavaScript. That or just abstract it away entirely and allow it become the bytecode of the web.
So many inconsistencies. So much magic one just has to know.
This sounds like English.
JS has two clear strong points: everybody knows it and it’s the lingua franca of the web. Just like how everybody knows English and it’s the lingua franca of international commerce.
The way it is going, we will use JavaScript forever.
Yes you could learn Elm. But when you quit your company 2 years from now, it will likely be better to have +2 years of JS than 2 years of Elm.
I think “incomplete and error-prone” is what causes user experiences the likes of which is described in the article. For an experienced programmer, that might mean giving up on some library or language. For a novice, that might mean reconsidering their interest in programming.
It sounds a bit like C, in fact: A standardized cross-platform (ha!) language with odd corner cases everyone seems to augment with libraries to smooth over the fact it was never fully portable from the beginning. It keeps being used, so it accretes more libraries around it, making it harder to switch away from, as even if you’re writing in a different language, you need to accept that the rest of the world speaks an API designed around That Language the moment you talk to something from the outside world.
“everybody knows it and it’s the lingua franca of the web
“everybody knows English and it’s the lingua franca of international commerce”
Sure, if by that you mean “everyone claims to know it, but when they need to use it, many fall flat on their face, or resort to some half-assed translation system that just complicates matters”.
You push juniors towards learning Elm, a little known language, with smaller community and fewer learning and documentation resources, and no proven longevity (just google “leaving Elm” for crying out loud)? As someone who had to pick up JS over the past year and uses it at their job, any newbie picking up Javascript ES6 and following good programming practices should have little problem. The ecosystem is a different story, but most “edge cases” and “gotchas” come from inexperience with the language. Recommending they learn some random language won’t help with a PEBCAK problem like that.
I’ve been writing JS since the late 90s and know multiple other languages. I still wouldn’t recommend a junior dev pick up Elm. Your reply is extremely condescending.
I still wouldn’t recommend a junior dev pick up Elm.
But why? Why do you think a language with an inconsistent API, confusing casting rules, and confusing scoping rules is easier for a beginner to learn than a language that has none of that?
Many of the “leaving Elm” genre of posts seem to focus on a Stalin-esque cult of personality of the lead developers combined with hard breaks incompatibility with no transition plans because they were told what they wanted was wrong and they shouldn’t have that.
As someone who was in a classroom where the class was trying to figure out API breaks with a replacement because of some old materials versus the latest version of a tool, that was annoying enough; at least I helped the others figure it out. If your language broke compatibility with zero intent on making your application change to something better, it would probably be disheartening for a new developer.
trying to figure out API breaks with a replacement
Can you be more specific on this point? I won’t suggest Elm is perfect or that its developers are infallible, but most complaints that I have seen are essentially people who are sad about no longer being able to use a private API that they shouldn’t have been using in the first place.
It’s about practicality. JavaScript has been around for nearly 30 years and is bigger than ever. The ecosystem is only bad if you know nothing about it and try to dive in like the OP talks about, but that’s the same with every language. I don’t know what the ‘inconsistent API’ is meant to be, and I don’t think the scoping rules are very confusing at this point with ES6/let.
JS is easy for beginners to pickup because they can go into their browser console and start writing it. No other installation necessary. Elm is a niche language that has a very small community and likely won’t ever pick up steam OR will completely cease to exist within a few years. Because of the attention JS gets, it gets new features that people want, better APIs, faster runtimes, and all the TLC you could ever ask for.
You are taking words out of context to try to argue against that rather than what I actually said.
So a few things here: let has been recommended over var for years now. You don’t need to worry about var hoisting if you follow standard coding practices, but it is good to learn about hoisting regardless. Most folks who are in JS beyond a few months know what function hoisting is (or at least have a general understanding that you can declare a function wherever within a file and it will still be available to you even above it). I think var hoisting is confusing for new folks and that’s the whole reason its usage has been deprecated.
When you refer to this being confusing, that’s true. But with the introduction of fat arrows and .bind(), it’s really not much of an issue. Again, this is taught as the recommended way to do things, and it’s always highlighted as a notice/warning.
People can do stupid things with any language. I don’t see how this argument says anything about JS specifically.
I agree with you, and especially from the context of a beginner. Yes, if you start with some old book on JS you’re going to be dealing with a world of var and this and discussions of how prototypes differ from classes. I’ve coded through all of that during my career.
The modern JS my team writes is almost entirely functional. We never write var; we don’t modify prototypes or create classes; this barely ever shows up in new code. We use the Object and Array helpers a lot (.values, .map, etc…). Callback hell is long dead, and async and await keep code readable and will get you a fairly long way (you will end up needing Promise.all and Promise.allSettled, most likely).
Would I take a newbie and ask them to maintain a JS app from 5, 10 years ago? Full of jQuery and maybe written half in Coffeescript? No, that’d be horrible. But I would feel fairly okay about getting them up-to-speed in ES6 first, and maybe suggesting they look to lodash first for extra helper functions.
const and let don’t hoist the same way as function and var. The way that function and var hoist is confusing because it brings it up from the bottom of your file or function and puts it at the top level, defining it as “undefined” to start. let and const do NOT do that. Let’s show an example here:
function test() {
console.log('fake variable', fake);
}
This will give you a ReferenceError exception because it’s never defined.
function test() {
console.log('fake variable', fake);
let fake = 'nothing';
}
This will give you a ReferenceError exception because you are trying to access it BEFORE initialization.
function test() {
console.log('fake variable', fake);
var fake = 'nothing';
}
This will log undefined without an exception.
You are just reading articles without understanding what they even say. let and const don’t hoist the variable up and define it, but they DO let the program know that they are defined within the scope later. I don’t know how you can even remotely say these are similar.
You were saying 2 of those 3 produce the same hoisting functionality, which is clearly (and quite obviously) NOT true.
You making false statements (and clearly not understanding how the language works) is not a discussion. I’m pointing out where you are wrong. It’s not about opinion.
I’m someone who first learned JavaScript back when most sites still used terms like “DHTML”. Call it turn of the millennium, because I’d have to go dig a bit to find the exact year.
I wouldn’t push Elm on new developers unless I had literally no other choice, and even then I likely wouldn’t. If I were looking to teach someone a more-predictable/less-warty language that compiles to JavaScript, I’d push them in the direction of TypeScript, not least because of the broader community and ecosystem for a new developer to take advantage of.
You think that Elm is literally the worst programming language ever designed?
Within the context of both the earlier comments in the thread, and the rest of my own comment’s text that you chose to omit from your quotes, I can find no way in which a good-faith interlocutor would choose to attempt that interpretation of what I said. As such, I wish you luck in your further endeavors but I will not be engaging with what you’ve done here.
Ok. If it pays well enough and I still enjoy it, maybe I’ll be writing JS in 10 years. How likely do you think it is people will be writing Elm at the end of that decade? At my job I also use Nim and Python, and Python and C when working through university. For fun I write in the languages I work with, as well as various Forths.
I hope you try picking up a few more manners. You might not come across like a dick :)
Why? I don’t know Nim and I don’t know how it compares to Python, but why is a language’s popularity a factor in a junior’s journey in learning how to program?
This is bad logic. If we follow that logic, then we could ask why we are teaching children how to program with Scratch and not C.
This is bad logic. If we follow that logic, then we could ask why we are teaching children how to program with Scratch and not C.
It’s not though.
Scratch is meant to teach children the ideas around how computers works in a fun way.
‘Juniors’ already know how computers work. Now what they want is expertise in a language that would get them a paying job, at this role JS is far superior. It is basically the language to know in that regards.
Perhaps we’re talking past each other, in that we have different ideas of what “junior” means.
The juniors that I have mentored have no prior understand of types, functions, control flow, etc.
The curriculum they typically go through involves cargo-culting some JavaScript libraries.
Gaining a more thorough understanding of fundamentals like why you can evaluate 'foo' + 1 in JavaScript gives a junior a better foundation for further autodidactic learning, and I believe it also gives a junior better leverage in the labour market.
Despite being a Haskell fan, I don’t find Elm to be an attractive target. Sure, it’s simple, but the JS interop is really messy, some aspects of setting up elements just don’t scale well, and I’ve seen far too many complaints about the core team’s behavior to assume it’s just a fluke.
Yes, JavaScript has a ton of weird stuff going on. However, it’s still the standard, and learning it is beneficial—even if you don’t like to use it personally—because at minimum you’ll be seeing a lot of it. The edge cases in tooling are a mess but there are improvements lying around if you scan a bit (e.g. Parcel 2 is looking far more promising over Webpack’s config soup), and most of the type system weirdness is “solved” by using TypeScript (which makes me sad since it’s unsound, but it also has some incredibly powerful type system features that many other languages don’t).
I want to be clear that the point of my comment was not to fetishise Elm.
The point is that all of JavaScript’s inconsistencies makes learning how to write programs with confidence immensely more challenging.
JS interop is not part of learning how to write programs, and some people’s reaction to how the the language designers reacted to language feature requests (which usually added a greater surface area for potential runtime failure) is also not part of learning how to write programs.
Minor aside: I don’t see how Elm’s FFI is “messy”. The port system works the way I would expect it to. It might feel more cumbersome than running some IO unsafely, but effects are hard, and this is the price we pay for a smaller surface area of potential runtime failures.
With 8+ years of JS (and TS) experience, and a smattering of Perl, Java, C, C++,C#, Elm, Ruby (Rails), Elm, Haskell, and more. I’d rather write all of those other languages combined every day than write more JS. The community always feels like they revert to whataboutisms and “it’s the language of the web!”. When it comes to writing a server, it’s perfectly acceptable to use any of a variety of languages. When it comes to writing for the browser it’s JS or nothing. Suggesting Elm is akin to suggesting cannibalism. I’d suggest Svelte, but most people think it’s JS. Why can’t the web front end be as diverse and accepting as the back end?
I see this kind of thing in the industry time and time again. I have always been bewildered at the tremendously high degree of tolerance my industry peers seem to have for suffering and frustration in day-to-day work. Time and time again, I have seen and experienced horrifically poor UX with some given $tech, $tool or $framework which the industry has accepted as okay (or heck, even good or great) for what I can only assume is fallacious reasoning like popularity, appeal to authority, or tradition. Some examples: OAuth, JWT, [devving with] PayPal, AngularJS, yarn, Docker.
When I find some tech that is easy to use, which just gets out of the way so I can just get stuff done, I really enjoy and cherish it. A couple examples: Ruby (N.B.: not Rails), and Vue.
It’s mostly that these kinds of things don’t show up on the radar when you’re looking for a place to work, and once you’re there you find out that the tooling is torturous and, if it happens that you cannot improve it, you either put up with it or bail out.
Oh my goodness. This is not Javascript, it’s Typescript!! With a .js extension!!
Wow, that’s a new level of wtf. I wouldn’t chalk that particular error to Node - mislabeling source files is pretty much an “developer is gravely mistaken” error.
The more I think about it, I wonder if the github author first took a node project skeleton then dumped or rewrote a section in typescript and didn’t update the README.
A mislabeled typescript file put erroneously into a stale project skeleton is hardly a fair experience, except for “how a developer with a stale readme can cause pain”.
My guess is that it was Flow rather than TypeScript. They have very similar syntax for type declarations, but Flow was mostly written with a .js extension, whereas TypeScript will issue a compile error if types are embedded into a .js file using the typical syntax. (You can use TS with types in a .js file, but only in comments.)
Why do the Flow developers think it’s okay to appropriate the extension of a different, closely-related file type?!
Because the ambition was to have Flow as a superset of JavaScript, which would allow teams to gradually introduce static typing to their existing codebase.
I’m not going to pass judgment on whether or not I think this is a good idea. However, this was devised by some of the highest-paid programmers in the world (since they work[ed] at Facebook), which I think validates the points about the JavaScript ecosystem that Lea Verou was making in her article, and the points that I’ve made elsewhere in this thread.
You’re right to be horrified, but it’s not the developer’s fault, I’d bet. The reason it’s .js extension (if it’s TS and not flow) is likely to be the difficulty they had in configuring their build toolchain, which is a constant thorn in the side of all of us JS devs with everything constantly shifting underneath us. And almost every single npm package in existence is filled to the brim with content that has no business being in the built+published artefact. NPM the tool makes publishing the correct content incredibly difficult, if you’re doing any sort of build-time tooling at all.
“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 (I stole this analogy from someone describing Ruby on Rails a few years ago).
A few days ago I wanted to publish a little “progressive enhancement”-type script I’ve been using for years as a module so other people can easily use it with WebPack and whatnot. That’s much easier said than done, as there is a lot of conflicting and confusing information out there. Publishing to npm isn’t too hard, but making it available as a module and keeping window.imgzoom for non-WebPack users proved to be hard; I’m not entire sure what the “best” way to do this is, or what exactly I need to support; is just ES2015 modules enough? There’s a lot of conflicting information out there.
Just searching “publish JavaScript module” and trying to make sense of it all is rather hard, it is for me anyway as I’m joining half-way through season 6. I have no strong opinions on the tooling as such – 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).
Several people in the HN thread were quick to point out that “but language X also has problems!” Aside from being a boring whataboutism, in my experience “quickly doing something” in other languages I’m not familiar with is typically quite a bit easier.
This is absolutely a fair criticism. I’ve spent a lot of time in the JS ecosystem and I find that usually the best way is to just completely ignore all the hype and just stick with season 1-2 of the show. Mostly I just assume the new shiny is unnecessary and move on with it. (Note though that I basically do JS on my own time, so if you’re in a company with people who try to keep up with all the new technology, this might not work out.)
Another way to think of this is: the vast majority of the JavaScript ecosystem is composed of early adopters. Not being one will save you a lot of energy. There’s a difference between keeping up with the times and being an early adopter that jumps on unproven technology and gets burned/has to work to solve problems that didn’t exist in the old stack, but the JavaScript ecosystem is largely unaware of that difference.
As an example, take your question: what format do I publish a module in? You’ll find lots of excited blog posts and documentation telling you to use Babel and ES6 modules and the new syntax, and here’s the 5 different modes Babel has to compile ES6 module syntax to, and by the way you probably should be using TypeScript too. All of that is noise. As far as I know, the only really compelling reason to switch to ES6 module syntax is that “it’s in the spec and it’s the future,” and that is no reason at all. It doesn’t really have any practical benefit. Traditional Node modules that use require() are Good Enough™, and all the new stuff works with them because there’s so much existing code. ES6 definitely has lots of useful new syntax, and maybe it’ll benefit you to learn some of it. But don’t feel obligated to rewrite everything in the new syntax, because ES5 is Good Enough™. All you’re doing is creating a problem for yourself that has to be solved by learning how to use Babel.
tl;dr:
Ship “boring” ES5 code, maybe with some extra ES6 stuff sprinkled in if it actually helps you (but not too new, because then you’ll have to get Babel involved, and definitely not simply for the sake of it being new)
Ship traditional Node modules, because it’s the “lowest” common denominator but honestly it isn’t really lower if you only look at practical benefits
If someone wants to use new module syntax or a new loader or whatever, that’s their problem, not yours. Everything should be compatible with require() anyway so why bother catering to someone else’s need for novelty? Let them figure out the problems they’ve created.
edit: honestly I’m not sure if this will help you. But I hope it does! <3
Thanks; I’m not really fussed by the “latest greatest”, and would like a simple method which provides:
Simply using window.imgzoom = function() { [..] } if loaded via plain ol’ <script src="imgzoom.js">
Exporting as a module if loaded via WebPack or whatnot and don’t pollute the global namespace.
I think I got it correct now; but with the plethora of different systems and whatnot it’s hard to be sure (never mind what WebPack on its own is not exactly easy to “just get started” with).
How so? What does it get you that tree shaking or dead code elimination doesn’t? Those techniques have been standard in any frontend build pipeline for a long time - before ES6 modules IIRC. I know one of the supposed benefits of the syntax is that it makes these things easier but I mean… Browserify and Webpack parsed require()s out of the AST just fine before Harmony modules.
(If your goal is maximal page load speed, you already need to be using a build system to uglify your JS and, more importantly, bundle packages together - request-response cycles cost a lot unless you want to go all in on HTTP/2, which has its own issues…)
Sorry for the late reply. If the problem is that require() is dynamic, then the solution is don’t use require() dynamically. I don’t use WebPack but I know Browserify has never supported require() calls that couldn’t be statically parsed. You just made sure not to do that, even if it would work at runtime in Node. This worked just fine before ES6 modules and did not require (ha!) new syntax.
You should read my post again - you’re misunderstanding and missing the point. If you have, for example:
var foo = require('foo');
Browserify will parse this just fine. That’s what I mean by “using require() statically”. On the other hand if you do something more dynamic like:
var modname = 'foo'; // This could be dynamically set conditionally, from config, etc.
var foo = require(modname);
this will not work because (at least IIUC) the problem of what module the program is going to run is undecidable. (WebPack does not do this either, so is WebPack also a non-starter in your opinion? There’s a lot of misinformation about Browserify but it can do everything WebPack can do.)
The main point that I was making though, which you ignored to focus on Browserify, is that the first example above is just as good as the new module syntax, and it does not require the entire ecosystem to move to brand-new syntax for no reason. It is a strict subset of already-widespread syntax/semantics, statically parseable, and worked just fine in Browserify and WebPack long before ES6 modules. It is, AFAIK, entirely semantically equivalent, meaning that there is no expressive power or ease of use gained or lost by moving to the new module syntax.
Of course, you can’t use the second example without some tricks. If you want to make your module compatible with module bundlers, don’t do things like the second example. You might have to rewrite the few modules that work like that so they’re compatible, but that’s not a valid argument, because the alternative is to rewrite every module. And for what?
New JavaScript syntax is not magical, and it’s not automatically good just because it’s new or because it’s in the core of the language. Languages are designed by regular people, and people make mistakes or have tunnel vision or any number of other things. ES6 modules create problems for the ecosystem and largely don’t do anything that require() didn’t already.
I understood your point. My point is that ‘Just don’t do XYZ and you’ll be OK’ is basically the same as ‘You’re holding it wrong’. There is a reason a new syntax was introduced, it was to rule out any possibility of dynamic requires no matter what tooling is being used. I agree with you that ES6 modules are not exactly a utopian solution, but they are a step forward for efficient bundling.
The reason I focused on Browserify is because you did–as an argument that the old require syntax would work statically as long as long as you used a tool which enforced using a dynamic syntax (require) statically. But like I said, that is a non-starter for a language ecosystem.
I’ve found Pika Pack (https://github.com/pikapkg/pack) to be the best tool for “I just want to publish this bit of JavaScript and not think about CommonJS, ES modules, UMD, or the 5 billion other JS module formats”.
Here’s an example library I published. You can see that it published in multiple formats, but the package.json configuration is pretty minimal. Pika isn’t perfect, but it’s better than writing your own Rollup/Webpack config.
Seems more like a perspective on the release format and documentation of a particular package. The argument may be that this sort of thing is endemic to the JS ecosystem and I agree that NPM et al could do a better job of discouraging releases like this, but I think since so many people are releasing JS packages it’s also a numbers game.
I’d hazard a guess that for every package where you have an experience like this you have 20 well documented packages, not using the experimental modules feature and compiled to ES5 code so you can use them almost anywhere.
I had this same experience with a well known, popular package that I’m 100% sure is used in production in many places. I eventually I found the root cause: an unlisted dependency on some tool that apparently every JS programmer worth their salt has installed already. I submitted a PR to fix the issue, and promptly decided to resume avoiding JS.
I forget exactly. A typescript type definition package for webpack, maybe? I’m not a JS person, so forgive me if the terminology is bogus, but it was something like that. Whatever it was, a lot of other packages pull it in. I installed some linter-esque tool in an attempt to diagnose my issue and the cryptic compiler errors vanished right away. Without that hint, my limited (nonexistent) knowledge of ES6 modules and whatever else the compiler was complaining about would have never gotten me anywhere.
How do you publish a package, never once testing a clean install in an isolated environment? It broke on the “hello world” example.
I recently had to write some JavaScript, and this was my own experience too. I chalk a lot of it up to my own inexperience with the ecosystem, but I also think that there’s a fair amount of accidental complexity. When I use modern JavaScript, with async/await, promises, anonymous functions &c. it feels a lot like it is trying to be a proper dynamic language like Lisp, but it is hindered by its syntax and its legacy.
Honestly, I would rather write Lisp or even Scheme.
Isn’t it funny that when I think about writing web project I would much rather use PHP than JS (I am not kidding).
JS is a crazy ecosystem and it is hard to defend it. Of course, vanilla JS used for it’s purpose is… not that terrible (although still WebAsm is superior).
I am sorry if my opinions might cause disagreements, but JS is an ecosystem that has evident problems and saying ‘people just do not understand’ does not quite cut it.
I work every single day in NodeJS and PHP. I will tell you one thing, if I am going to build any web service I am not going to reach for NodeJS. I always thought it made more sense to use tools like PHP-FPM and NGINX to get a web application off the ground than NodeJS, the Express.js package, a process manager for the service, and NGINX to proxy into.
I do a lot of AWS Lambda work though and I have seen first hand why the IO on NodeJS is so highly regarded.
I like writing code in both, and achieving the specific business goals with both, but I see they have their own strengths.
I am sorry if my opinions might cause disagreements, but JS is an ecosystem that has evident problems and saying ‘people just do not understand’ does not quite cut it.
This seems valid. While neither the language nor the ecosystem are without controversy, it would be far easier to defend the language than to defend the ecosystem. However, both are rapidly improving—I’m excited to see what Deno will do to the ecosystem.
With such I am always worried with adding standards routine. Of course, if JS issues will be solved and the ecosystem stops being an annoyance and gets straightforward, then I will retract all my points as being dogmatic is not beneficial to anyone.
Last time I’ve tried to deal with ThreeJS I had similar problems…part of the frustration is that there are a lot of libraries that kinda assume “of course you’re using a full build pipeline for the frontend!”, when the task at hands merits maybe a <script> tag with an IIFE.
That’s true, although the non-npm usage of JS is vanishingly small these days unfortunately. And from an outsider’s perspective, they’re definitely the same thing.
Having done the go-round with typescript for a CLI in the last 6-9 months, my frank opinion of the ecosystem is that you couldn’t pay me to work on it. Literally. I won’t pursue jobs that involve serious use of node / js. I also did a front end in React a few years ago. Today, if someone wants me to prioritize it for a major long term project, that’s not going to happen. Much more interested in more principled systems - Scala, Rust, etc.
Before someone remarks on “you just didn’t know the system”- I’ve attacked similar projects in size and complexity as a newbie in the following languages/ecosystems:
Java, Scala, Rust, Clojure, Haskell, OCaml, C#, Common Lisp, Python, and Perl.
I also recollect well my early use of Visual C++ 5 and Visual Basic 6.
The JS/Typescript ecosystem npm is explosively worse. It’s not just bad. It’s disastrously, horrifyingly, terrifyingly bad, a fractal of bad that is a juddering horror of self-justifying waste, stacked on itself like a tower of fail. It is so bad, yet so widely justified. I leave the rationale and the consequence analysis to the thoughtful reader.
This is funny to me because it’s a complaint about npm and TypeScript, not so much JS. The initial complaint is that it’s not obvious how to install and run a package, but is it any better to install and run packages from any other language? In python, you’re using virtualenv which is the least intuitive way to manage your project of any language. In ruby, you’re using gemlock files which are better, but still not immediately obvious. I’m not going to bother with languages like Java, C++, etc for the purposes of this “one liner” problem, but they have their own issues in ecosystem for a beginner as well.
My first thought while reading this, though, was “why not just tell them to use const functionName = require('packageName'); and be done with it? You don’t need to use ES module imports. Especially if it’s a one-liner. Everything after that becomes an issue of “wow this package is really poorly done” and nothing to do with JS itself. I mean, if anything, it’s a failure of TypeScript devs who assume everyone is always using TypeScript (why is this package not distributed with plain JS?).
If I were to try to guide someone else (who is also not familiar with the language) on how to spin up a Scala app with a dependency and run it, I’m sure we’d run into similar confusions and issues.
I understand when people want to point out real deficiencies with JS, but this has really nothing to do with the language itself. There isn’t even any JavaScript here aside from import { functionName } from packageName.
CLIs are no more reified than GUIs are. The arguments only exist in a strong sense for shell-like programs but not CLIs in general, and - although it is arguable - I would say that shells and GUIs are still both equally reified. For instance, this may make sense for zsh but depending on the person it may not be true as much for tee.
The argument made by this article is based on the article’s subjective criteria which is being provided as “this is what it means to be reified”. Of course, this goes into the question of what consitutes a CLI as well. Is npm a CLI or are we only talking about shells here? Is a shell suddenly not reified if I disable the features that “reify” it in these examples - even if that is to my liking?
This article is simply making a specific arguments that they think GUIs aren’t reified because of an overly-qualified definition of what it means for something to be reified.
This is a good read and a good point.
It’s also the first time I’ve encountered the phrase “start a localhost” and it made me cringe.
So accurate, and I’m glad Lea had the patience to put it into writing. I’m much more inclined to write off the entire ecosystem as some expletive.
This is generally why I push juniors towards learning Elm instead of JavaScript these days. There are so many edge cases in today’s JavaScript. So many inconsistencies. So much magic one just has to know. So much conflicting information and constant churn. I feel this pain every time a junior asks me for help with something that won’t work as they expect, which these days is effectively every day.
Juniors are surprisingly good at finding logic rules that are internally inconsistent in programming languages.
There’s been a push lately for people to write “simple Haskell”, and to be honest I think we more desperately need a push towards simple JavaScript. That or just abstract it away entirely and allow it become the bytecode of the web.
This sounds like English.
JS has two clear strong points: everybody knows it and it’s the lingua franca of the web. Just like how everybody knows English and it’s the lingua franca of international commerce.
The way it is going, we will use JavaScript forever.
Yes you could learn Elm. But when you quit your company 2 years from now, it will likely be better to have +2 years of JS than 2 years of Elm.
I would argue against that.
I think it’s no coincidence that one of the most popular technical book series for this language is called You Don’t Know JS.
Well they know it the same way most people know English. Incomplete and error-prone but most of the time still good enough.
I think “incomplete and error-prone” is what causes user experiences the likes of which is described in the article. For an experienced programmer, that might mean giving up on some library or language. For a novice, that might mean reconsidering their interest in programming.
It sounds a bit like C, in fact: A standardized cross-platform (ha!) language with odd corner cases everyone seems to augment with libraries to smooth over the fact it was never fully portable from the beginning. It keeps being used, so it accretes more libraries around it, making it harder to switch away from, as even if you’re writing in a different language, you need to accept that the rest of the world speaks an API designed around That Language the moment you talk to something from the outside world.
Sure, if by that you mean “everyone claims to know it, but when they need to use it, many fall flat on their face, or resort to some half-assed translation system that just complicates matters”.
You push juniors towards learning Elm, a little known language, with smaller community and fewer learning and documentation resources, and no proven longevity (just google “leaving Elm” for crying out loud)? As someone who had to pick up JS over the past year and uses it at their job, any newbie picking up Javascript ES6 and following good programming practices should have little problem. The ecosystem is a different story, but most “edge cases” and “gotchas” come from inexperience with the language. Recommending they learn some random language won’t help with a PEBCAK problem like that.
[Comment removed by author]
I’ve been writing JS since the late 90s and know multiple other languages. I still wouldn’t recommend a junior dev pick up Elm. Your reply is extremely condescending.
But why? Why do you think a language with an inconsistent API, confusing casting rules, and confusing scoping rules is easier for a beginner to learn than a language that has none of that?
Many of the “leaving Elm” genre of posts seem to focus on a Stalin-esque cult of personality of the lead developers combined with hard breaks incompatibility with no transition plans because they were told what they wanted was wrong and they shouldn’t have that.
As someone who was in a classroom where the class was trying to figure out API breaks with a replacement because of some old materials versus the latest version of a tool, that was annoying enough; at least I helped the others figure it out. If your language broke compatibility with zero intent on making your application change to something better, it would probably be disheartening for a new developer.
Can you be more specific on this point? I won’t suggest Elm is perfect or that its developers are infallible, but most complaints that I have seen are essentially people who are sad about no longer being able to use a private API that they shouldn’t have been using in the first place.
It’s about practicality. JavaScript has been around for nearly 30 years and is bigger than ever. The ecosystem is only bad if you know nothing about it and try to dive in like the OP talks about, but that’s the same with every language. I don’t know what the ‘inconsistent API’ is meant to be, and I don’t think the scoping rules are very confusing at this point with ES6/let.
JS is easy for beginners to pickup because they can go into their browser console and start writing it. No other installation necessary. Elm is a niche language that has a very small community and likely won’t ever pick up steam OR will completely cease to exist within a few years. Because of the attention JS gets, it gets new features that people want, better APIs, faster runtimes, and all the TLC you could ever ask for.
[Comment removed by author]
You are taking words out of context to try to argue against that rather than what I actually said.
So a few things here:
lethas been recommended overvarfor years now. You don’t need to worry aboutvarhoisting if you follow standard coding practices, but it is good to learn about hoisting regardless. Most folks who are in JS beyond a few months know what function hoisting is (or at least have a general understanding that you can declare a function wherever within a file and it will still be available to you even above it). I thinkvarhoisting is confusing for new folks and that’s the whole reason its usage has been deprecated.When you refer to
thisbeing confusing, that’s true. But with the introduction of fat arrows and.bind(), it’s really not much of an issue. Again, this is taught as the recommended way to do things, and it’s always highlighted as a notice/warning.People can do stupid things with any language. I don’t see how this argument says anything about JS specifically.
I agree with you, and especially from the context of a beginner. Yes, if you start with some old book on JS you’re going to be dealing with a world of
varandthisand discussions of how prototypes differ from classes. I’ve coded through all of that during my career.The modern JS my team writes is almost entirely functional. We never write
var; we don’t modify prototypes or create classes;thisbarely ever shows up in new code. We use theObjectandArrayhelpers a lot (.values,.map, etc…). Callback hell is long dead, andasyncandawaitkeep code readable and will get you a fairly long way (you will end up needingPromise.allandPromise.allSettled, most likely).Would I take a newbie and ask them to maintain a JS app from 5, 10 years ago? Full of jQuery and maybe written half in Coffeescript? No, that’d be horrible. But I would feel fairly okay about getting them up-to-speed in ES6 first, and maybe suggesting they look to lodash first for extra helper functions.
[Comment removed by author]
const and let don’t hoist the same way as function and var. The way that function and var hoist is confusing because it brings it up from the bottom of your file or function and puts it at the top level, defining it as “undefined” to start. let and const do NOT do that. Let’s show an example here:
This will give you a ReferenceError exception because it’s never defined.
This will give you a ReferenceError exception because you are trying to access it BEFORE initialization.
This will log
undefinedwithout an exception.You are just reading articles without understanding what they even say.
letandconstdon’t hoist the variable up and define it, but they DO let the program know that they are defined within the scope later. I don’t know how you can even remotely say these are similar.[Comment removed by author]
You were saying 2 of those 3 produce the same hoisting functionality, which is clearly (and quite obviously) NOT true.
You making false statements (and clearly not understanding how the language works) is not a discussion. I’m pointing out where you are wrong. It’s not about opinion.
I’m someone who first learned JavaScript back when most sites still used terms like “DHTML”. Call it turn of the millennium, because I’d have to go dig a bit to find the exact year.
I wouldn’t push Elm on new developers unless I had literally no other choice, and even then I likely wouldn’t. If I were looking to teach someone a more-predictable/less-warty language that compiles to JavaScript, I’d push them in the direction of TypeScript, not least because of the broader community and ecosystem for a new developer to take advantage of.
[Comment removed by author]
Within the context of both the earlier comments in the thread, and the rest of my own comment’s text that you chose to omit from your quotes, I can find no way in which a good-faith interlocutor would choose to attempt that interpretation of what I said. As such, I wish you luck in your further endeavors but I will not be engaging with what you’ve done here.
[Comment removed by author]
Ok. If it pays well enough and I still enjoy it, maybe I’ll be writing JS in 10 years. How likely do you think it is people will be writing Elm at the end of that decade? At my job I also use Nim and Python, and Python and C when working through university. For fun I write in the languages I work with, as well as various Forths.
I hope you try picking up a few more manners. You might not come across like a dick :)
Is Nim as popular as Elm?
Probably not, but I’m not telling juniors to learn it over Python.
Why? I don’t know Nim and I don’t know how it compares to Python, but why is a language’s popularity a factor in a junior’s journey in learning how to program?
This is bad logic. If we follow that logic, then we could ask why we are teaching children how to program with Scratch and not C.
It’s not though.
Scratch is meant to teach children the ideas around how computers works in a fun way.
‘Juniors’ already know how computers work. Now what they want is expertise in a language that would get them a paying job, at this role JS is far superior. It is basically the language to know in that regards.
Perhaps we’re talking past each other, in that we have different ideas of what “junior” means.
The juniors that I have mentored have no prior understand of types, functions, control flow, etc.
The curriculum they typically go through involves cargo-culting some JavaScript libraries.
Gaining a more thorough understanding of fundamentals like why you can evaluate
'foo' + 1in JavaScript gives a junior a better foundation for further autodidactic learning, and I believe it also gives a junior better leverage in the labour market.okay. I assumed juniors mean graduates of a computer related degrees with minimal experience.
Doesn’t look like nim or elm show up in the TIOBE top 50:
https://www.tiobe.com/tiobe-index/
Despite being a Haskell fan, I don’t find Elm to be an attractive target. Sure, it’s simple, but the JS interop is really messy, some aspects of setting up elements just don’t scale well, and I’ve seen far too many complaints about the core team’s behavior to assume it’s just a fluke.
Yes, JavaScript has a ton of weird stuff going on. However, it’s still the standard, and learning it is beneficial—even if you don’t like to use it personally—because at minimum you’ll be seeing a lot of it. The edge cases in tooling are a mess but there are improvements lying around if you scan a bit (e.g. Parcel 2 is looking far more promising over Webpack’s config soup), and most of the type system weirdness is “solved” by using TypeScript (which makes me sad since it’s unsound, but it also has some incredibly powerful type system features that many other languages don’t).
I want to be clear that the point of my comment was not to fetishise Elm.
The point is that all of JavaScript’s inconsistencies makes learning how to write programs with confidence immensely more challenging.
JS interop is not part of learning how to write programs, and some people’s reaction to how the the language designers reacted to language feature requests (which usually added a greater surface area for potential runtime failure) is also not part of learning how to write programs.
Minor aside: I don’t see how Elm’s FFI is “messy”. The port system works the way I would expect it to. It might feel more cumbersome than running some IO unsafely, but effects are hard, and this is the price we pay for a smaller surface area of potential runtime failures.
With 8+ years of JS (and TS) experience, and a smattering of Perl, Java, C, C++,C#, Elm, Ruby (Rails), Elm, Haskell, and more. I’d rather write all of those other languages combined every day than write more JS. The community always feels like they revert to whataboutisms and “it’s the language of the web!”. When it comes to writing a server, it’s perfectly acceptable to use any of a variety of languages. When it comes to writing for the browser it’s JS or nothing. Suggesting Elm is akin to suggesting cannibalism. I’d suggest Svelte, but most people think it’s JS. Why can’t the web front end be as diverse and accepting as the back end?
I see this kind of thing in the industry time and time again. I have always been bewildered at the tremendously high degree of tolerance my industry peers seem to have for suffering and frustration in day-to-day work. Time and time again, I have seen and experienced horrifically poor UX with some given
$tech,$toolor$frameworkwhich the industry has accepted as okay (or heck, even good or great) for what I can only assume is fallacious reasoning like popularity, appeal to authority, or tradition. Some examples: OAuth, JWT, [devving with] PayPal, AngularJS, yarn, Docker.When I find some tech that is easy to use, which just gets out of the way so I can just get stuff done, I really enjoy and cherish it. A couple examples: Ruby (N.B.: not Rails), and Vue.
It’s mostly that these kinds of things don’t show up on the radar when you’re looking for a place to work, and once you’re there you find out that the tooling is torturous and, if it happens that you cannot improve it, you either put up with it or bail out.
Wow, that’s a new level of wtf. I wouldn’t chalk that particular error to Node - mislabeling source files is pretty much an “developer is gravely mistaken” error.
The more I think about it, I wonder if the github author first took a node project skeleton then dumped or rewrote a section in typescript and didn’t update the README.
A mislabeled typescript file put erroneously into a stale project skeleton is hardly a fair experience, except for “how a developer with a stale readme can cause pain”.
My guess is that it was Flow rather than TypeScript. They have very similar syntax for type declarations, but Flow was mostly written with a .js extension, whereas TypeScript will issue a compile error if types are embedded into a .js file using the typical syntax. (You can use TS with types in a .js file, but only in comments.)
That still merits a WTF from me. Why do the Flow developers think it’s okay to appropriate the extension of a different, closely-related file type?!
Because the ambition was to have Flow as a superset of JavaScript, which would allow teams to gradually introduce static typing to their existing codebase.
I’m not going to pass judgment on whether or not I think this is a good idea. However, this was devised by some of the highest-paid programmers in the world (since they work[ed] at Facebook), which I think validates the points about the JavaScript ecosystem that Lea Verou was making in her article, and the points that I’ve made elsewhere in this thread.
You’re right to be horrified, but it’s not the developer’s fault, I’d bet. The reason it’s
.jsextension (if it’s TS and not flow) is likely to be the difficulty they had in configuring their build toolchain, which is a constant thorn in the side of all of us JS devs with everything constantly shifting underneath us. And almost every single npm package in existence is filled to the brim with content that has no business being in the built+published artefact. NPM the tool makes publishing the correct content incredibly difficult, if you’re doing any sort of build-time tooling at all.[Comment removed by author]
“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 (I stole this analogy from someone describing Ruby on Rails a few years ago).
A few days ago I wanted to publish a little “progressive enhancement”-type script I’ve been using for years as a module so other people can easily use it with WebPack and whatnot. That’s much easier said than done, as there is a lot of conflicting and confusing information out there. Publishing to npm isn’t too hard, but making it available as a module and keeping
window.imgzoomfor non-WebPack users proved to be hard; I’m not entire sure what the “best” way to do this is, or what exactly I need to support; is just ES2015 modules enough? There’s a lot of conflicting information out there.Just searching “publish JavaScript module” and trying to make sense of it all is rather hard, it is for me anyway as I’m joining half-way through season 6. I have no strong opinions on the tooling as such – 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).
Several people in the HN thread were quick to point out that “but language X also has problems!” Aside from being a boring whataboutism, in my experience “quickly doing something” in other languages I’m not familiar with is typically quite a bit easier.
This is absolutely a fair criticism. I’ve spent a lot of time in the JS ecosystem and I find that usually the best way is to just completely ignore all the hype and just stick with season 1-2 of the show. Mostly I just assume the new shiny is unnecessary and move on with it. (Note though that I basically do JS on my own time, so if you’re in a company with people who try to keep up with all the new technology, this might not work out.)
Another way to think of this is: the vast majority of the JavaScript ecosystem is composed of early adopters. Not being one will save you a lot of energy. There’s a difference between keeping up with the times and being an early adopter that jumps on unproven technology and gets burned/has to work to solve problems that didn’t exist in the old stack, but the JavaScript ecosystem is largely unaware of that difference.
As an example, take your question: what format do I publish a module in? You’ll find lots of excited blog posts and documentation telling you to use Babel and ES6 modules and the new syntax, and here’s the 5 different modes Babel has to compile ES6 module syntax to, and by the way you probably should be using TypeScript too. All of that is noise. As far as I know, the only really compelling reason to switch to ES6 module syntax is that “it’s in the spec and it’s the future,” and that is no reason at all. It doesn’t really have any practical benefit. Traditional Node modules that use
require()are Good Enough™, and all the new stuff works with them because there’s so much existing code. ES6 definitely has lots of useful new syntax, and maybe it’ll benefit you to learn some of it. But don’t feel obligated to rewrite everything in the new syntax, because ES5 is Good Enough™. All you’re doing is creating a problem for yourself that has to be solved by learning how to use Babel.tl;dr:
require()anyway so why bother catering to someone else’s need for novelty? Let them figure out the problems they’ve created.edit: honestly I’m not sure if this will help you. But I hope it does! <3
Thanks; I’m not really fussed by the “latest greatest”, and would like a simple method which provides:
window.imgzoom = function() { [..] }if loaded via plain ol’<script src="imgzoom.js">I think I got it correct now; but with the plethora of different systems and whatnot it’s hard to be sure (never mind what WebPack on its own is not exactly easy to “just get started” with).
Well the practical benefit of ES6 modules is shipping less code to your users so their page loads are faster.
How so? What does it get you that tree shaking or dead code elimination doesn’t? Those techniques have been standard in any frontend build pipeline for a long time - before ES6 modules IIRC. I know one of the supposed benefits of the syntax is that it makes these things easier but I mean… Browserify and Webpack parsed
require()s out of the AST just fine before Harmony modules.(If your goal is maximal page load speed, you already need to be using a build system to uglify your JS and, more importantly, bundle packages together - request-response cycles cost a lot unless you want to go all in on HTTP/2, which has its own issues…)
Because ES6
imports are static, while CommonJSrequires are dynamic and thus harder (if not impossible) to tree shake properly.Sorry for the late reply. If the problem is that
require()is dynamic, then the solution is don’t userequire()dynamically. I don’t use WebPack but I know Browserify has never supportedrequire()calls that couldn’t be statically parsed. You just made sure not to do that, even if it would work at runtime in Node. This worked just fine before ES6 modules and did not require (ha!) new syntax.Well I don’t know much about Browserify but if it didn’t support something that Node did, that would make it a non-starter in my opinion.
You should read my post again - you’re misunderstanding and missing the point. If you have, for example:
Browserify will parse this just fine. That’s what I mean by “using
require()statically”. On the other hand if you do something more dynamic like:this will not work because (at least IIUC) the problem of what module the program is going to run is undecidable. (WebPack does not do this either, so is WebPack also a non-starter in your opinion? There’s a lot of misinformation about Browserify but it can do everything WebPack can do.)
The main point that I was making though, which you ignored to focus on Browserify, is that the first example above is just as good as the new module syntax, and it does not require the entire ecosystem to move to brand-new syntax for no reason. It is a strict subset of already-widespread syntax/semantics, statically parseable, and worked just fine in Browserify and WebPack long before ES6 modules. It is, AFAIK, entirely semantically equivalent, meaning that there is no expressive power or ease of use gained or lost by moving to the new module syntax.
Of course, you can’t use the second example without some tricks. If you want to make your module compatible with module bundlers, don’t do things like the second example. You might have to rewrite the few modules that work like that so they’re compatible, but that’s not a valid argument, because the alternative is to rewrite every module. And for what?
New JavaScript syntax is not magical, and it’s not automatically good just because it’s new or because it’s in the core of the language. Languages are designed by regular people, and people make mistakes or have tunnel vision or any number of other things. ES6 modules create problems for the ecosystem and largely don’t do anything that
require()didn’t already.I understood your point. My point is that ‘Just don’t do XYZ and you’ll be OK’ is basically the same as ‘You’re holding it wrong’. There is a reason a new syntax was introduced, it was to rule out any possibility of dynamic
requires no matter what tooling is being used. I agree with you that ES6 modules are not exactly a utopian solution, but they are a step forward for efficient bundling.The reason I focused on Browserify is because you did–as an argument that the old
requiresyntax would work statically as long as long as you used a tool which enforced using a dynamic syntax (require) statically. But like I said, that is a non-starter for a language ecosystem.I’ve found Pika Pack (https://github.com/pikapkg/pack) to be the best tool for “I just want to publish this bit of JavaScript and not think about CommonJS, ES modules, UMD, or the 5 billion other JS module formats”.
Here’s an example library I published. You can see that it published in multiple formats, but the package.json configuration is pretty minimal. Pika isn’t perfect, but it’s better than writing your own Rollup/Webpack config.
Seems more like a perspective on the release format and documentation of a particular package. The argument may be that this sort of thing is endemic to the JS ecosystem and I agree that NPM et al could do a better job of discouraging releases like this, but I think since so many people are releasing JS packages it’s also a numbers game.
I’d hazard a guess that for every package where you have an experience like this you have 20 well documented packages, not using the experimental modules feature and compiled to ES5 code so you can use them almost anywhere.
I had this same experience with a well known, popular package that I’m 100% sure is used in production in many places. I eventually I found the root cause: an unlisted dependency on some tool that apparently every JS programmer worth their salt has installed already. I submitted a PR to fix the issue, and promptly decided to resume avoiding JS.
What was the unlisted tool?
I forget exactly. A typescript type definition package for webpack, maybe? I’m not a JS person, so forgive me if the terminology is bogus, but it was something like that. Whatever it was, a lot of other packages pull it in. I installed some linter-esque tool in an attempt to diagnose my issue and the cryptic compiler errors vanished right away. Without that hint, my limited (nonexistent) knowledge of ES6 modules and whatever else the compiler was complaining about would have never gotten me anywhere.
How do you publish a package, never once testing a clean install in an isolated environment? It broke on the “hello world” example.
I recently had to write some JavaScript, and this was my own experience too. I chalk a lot of it up to my own inexperience with the ecosystem, but I also think that there’s a fair amount of accidental complexity. When I use modern JavaScript, with
async/await, promises, anonymous functions &c. it feels a lot like it is trying to be a proper dynamic language like Lisp, but it is hindered by its syntax and its legacy.Honestly, I would rather write Lisp or even Scheme.
How about clojurescript? That’s a lisp with pretty good support for JS.
There are a bunch of other lisps that compile to JS, too: https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS#lisp-scheme
Isn’t it funny that when I think about writing web project I would much rather use PHP than JS (I am not kidding).
JS is a crazy ecosystem and it is hard to defend it. Of course, vanilla JS used for it’s purpose is… not that terrible (although still WebAsm is superior).
I am sorry if my opinions might cause disagreements, but JS is an ecosystem that has evident problems and saying ‘people just do not understand’ does not quite cut it.
I work every single day in NodeJS and PHP. I will tell you one thing, if I am going to build any web service I am not going to reach for NodeJS. I always thought it made more sense to use tools like PHP-FPM and NGINX to get a web application off the ground than NodeJS, the Express.js package, a process manager for the service, and NGINX to proxy into.
I do a lot of AWS Lambda work though and I have seen first hand why the IO on NodeJS is so highly regarded.
I like writing code in both, and achieving the specific business goals with both, but I see they have their own strengths.
You can run a Node server without an nginx proxy. I just deploy a Node server in a Docker container and you don’t need the process manager or nginx.
This seems valid. While neither the language nor the ecosystem are without controversy, it would be far easier to defend the language than to defend the ecosystem. However, both are rapidly improving—I’m excited to see what Deno will do to the ecosystem.
With such I am always worried with adding standards routine. Of course, if JS issues will be solved and the ecosystem stops being an annoyance and gets straightforward, then I will retract all my points as being dogmatic is not beneficial to anyone.
Last time I’ve tried to deal with ThreeJS I had similar problems…part of the frustration is that there are a lot of libraries that kinda assume “of course you’re using a full build pipeline for the frontend!”, when the task at hands merits maybe a
<script>tag with an IIFE.It’s all so tiresome.
From an “insider”, take my word it’s far worse than you think it is.
This article should be titled “Today’s NPM, from an outsider’s perspective”. There isn’t even any code in the article.
That’s true, although the non-npm usage of JS is vanishingly small these days unfortunately. And from an outsider’s perspective, they’re definitely the same thing.
Having done the go-round with typescript for a CLI in the last 6-9 months, my frank opinion of the ecosystem is that you couldn’t pay me to work on it. Literally. I won’t pursue jobs that involve serious use of node / js. I also did a front end in React a few years ago. Today, if someone wants me to prioritize it for a major long term project, that’s not going to happen. Much more interested in more principled systems - Scala, Rust, etc.
Before someone remarks on “you just didn’t know the system”- I’ve attacked similar projects in size and complexity as a newbie in the following languages/ecosystems:
I also recollect well my early use of Visual C++ 5 and Visual Basic 6.
The JS/Typescript ecosystem npm is explosively worse. It’s not just bad. It’s disastrously, horrifyingly, terrifyingly bad, a fractal of bad that is a juddering horror of self-justifying waste, stacked on itself like a tower of fail. It is so bad, yet so widely justified. I leave the rationale and the consequence analysis to the thoughtful reader.
For the consequence, would you use one of the Clojure or Haskell implementations for web?
Depends on the task, the consequences of bugs, the duration of the task, the people maintaining it with me, and the people maintaining it after me.
Lack of documentation and presentation. The ecosystem itself, once familiar, is quite straight forward.
This is funny to me because it’s a complaint about npm and TypeScript, not so much JS. The initial complaint is that it’s not obvious how to install and run a package, but is it any better to install and run packages from any other language? In python, you’re using virtualenv which is the least intuitive way to manage your project of any language. In ruby, you’re using gemlock files which are better, but still not immediately obvious. I’m not going to bother with languages like Java, C++, etc for the purposes of this “one liner” problem, but they have their own issues in ecosystem for a beginner as well.
My first thought while reading this, though, was “why not just tell them to use
const functionName = require('packageName');and be done with it? You don’t need to use ES module imports. Especially if it’s a one-liner. Everything after that becomes an issue of “wow this package is really poorly done” and nothing to do with JS itself. I mean, if anything, it’s a failure of TypeScript devs who assume everyone is always using TypeScript (why is this package not distributed with plain JS?).If I were to try to guide someone else (who is also not familiar with the language) on how to spin up a Scala app with a dependency and run it, I’m sure we’d run into similar confusions and issues.
I understand when people want to point out real deficiencies with JS, but this has really nothing to do with the language itself. There isn’t even any JavaScript here aside from
import { functionName } from packageName.CLIs are no more reified than GUIs are. The arguments only exist in a strong sense for shell-like programs but not CLIs in general, and - although it is arguable - I would say that shells and GUIs are still both equally reified. For instance, this may make sense for
zshbut depending on the person it may not be true as much fortee.The argument made by this article is based on the article’s subjective criteria which is being provided as “this is what it means to be reified”. Of course, this goes into the question of what consitutes a CLI as well. Is
npma CLI or are we only talking about shells here? Is a shell suddenly not reified if I disable the features that “reify” it in these examples - even if that is to my liking?This article is simply making a specific arguments that they think GUIs aren’t reified because of an overly-qualified definition of what it means for something to be reified.
Possibly a bug with this website or something, but I think your comment was meant to end up in here: https://lobste.rs/s/sjtxdi/clis_are_reified_uis
Whoa, what the heck? I’ve never even seen the post that this is supposedly in reply to…Thanks! O_o