sounds like the same experience I have with pretty much every language I'm not used to.
I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error.
repeat the same with xcode and any project in c, c++, objc, swift
okay how about ruby? oh I have old ruby , hmmm , try to install new ruby, seems to run, but it can't find certain gems or something. oh and this other ruby thing I was using is now broken ? why do I have to install this stuff globally? You don't but there are several magic spells you must execute and runes you must set in the rigtt places. Oh ... I think I got that setup but it getting this new error.
I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off.
Nothing ever works like a sane person would expect. When I do get a working typescript + webpack setup it’s almost entirely by accident. I stumbled upon something that works? Just avoid touching it at all costs.
Recently I wanted to load an AMD module in Deno and just about gave my self an aneurism before giving up hours later.
I have worked in dozens of languages over my career, and not encountered as much of a clusterf*ck as JavaScript anywhere else. I have never worked with anything before where so few people had any idea how it actually worked and just prayed that it continues.
This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a <script> tag, or a block of <script> tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output directory and my package.json, so that shouldn't be a problem (yeah, right...).
I've written JS professionally for probably 12 or 13 out of the last 22 years, but I skipped the first couple iterations of frontend bundlers and tooling (kept rocking it old-school and just including plain .js files with script tags) until React, so I seem to have missed that intermediate phase, and now I cannot find it. I've lost probably 3 to 4 hours to trying to figure this out, last couple times I looked.
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" entry.
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.
> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off
Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays.
There are also countless boilerplate project with webpack setup already so you can get reference from there.
> It's literally the name itself "node"_modules, it's designed to be used with node.
That’s the problem. It’s not JavaScript. It’s not any part of the ECMA standard, it doesn’t work in runtimes other than node (read: the browser) yet it lives in the .js files making them not truly JavaScript. You have split the language.
The syntax isn’t part of the language and was designed in such a way that it cannot be polyfilled. This lead to a thousand packagers that would not be necessary at all if a sane syntax had been chosen. The creator of node himself has said making node incompatible with the browser was one of his biggest mistakes.
> There are also countless boilerplate project with webpack setup already so you can get reference from there.
That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.
If anything, it's not the fault of javascript, it's on node. However finding the popularity of it means that somewhat it's more suitable for many devs than the alternatives.
Well I can understand it. As I've used the previous generation of jQuery, knockout, etc, nodejs and it's tooling makes things easier to scale, even with bigger overhead cost.
EDIT:
> That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.
Copy, make it run well, modify, learn is how I learn things. Without working example, it's magnitude times harder to learn something. The fact that people copy and use without trying to understand things is their fault, not the hundreds of boilerplate code.
Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.
Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.
Typescript IS a different language than Javascript (for good or for bad), meaning you are compounding the issues with Javascript ecosystem with the issues with Typescript compilation.
Most of my code today is very straightforward, start a project, add type: module and 90% of the packages will work. If it doesn't, I either pick one of the 1M+ alternatives, try to decipher the issue (often is changing the import format or entrypoint), or avoid using a package for the problem I was trying to solve if trivial enough.
> 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 fault of the language not having a standard library.
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 used for. A screwdriver isn't a good hammer, either.
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.
>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.
Why should the language provide that? What other languages provide an equivalent to that? left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website, because HTML has tables, CSS and other elements for that.
> left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website
This is just not correct. It’s for padding a string with any character, for example adding leading zeroes to a number for display purposes. There are plenty of reasons to want to do that in a browser.
Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess.
It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attacked us yet so no-one ever will[2]", "it's tracktable to untangle the dependency hell in your head because there aren't that many crates (yet)", and of course "we all know this history like the back of our hand, because we've all been around since v0.1 alpha."
I'm picturing "10 years later" when some junior developer at MegaCorp Inc desperately tries to figure out why the legacy Rust 2018 version he's forced to use in 2032 can't compile some privately hosted crate that's needed for an enterprise project. It'll probably depend on a specific version of a crate that was yanked because some transitive dependency had to be yanked because that guy was a Russian kid that sold access to this popular crate for $500 to Israeli spies. Of course now the patched crate requires Rust 2030 or whatever, breaking fifty seven of the two thousand transitive crates being pulled it, so good luck to him with disentangling that mess and making this work.
PS: I wish I was making this story up, but I basically just changed Angular to Rust for a real thing that happened to me, like... a month ago. There is no fundamental difference to how Rust does packages, it's just younger so the mess hasn't accumulated to Angular's levels of madness. Give it time...
[1] Except for that spat with the core team.
[2] That we know of. Ignore the guy spamming popular, single-word crate names and shovelling in 99.9% C/C++ code with the thinnest possible Rust wrapper. Surprise! Your code is now more C++ than Rust.
Yanking crates does not get rid of their code; you can still depend on them in your crates, you just can't upload those crates to crates.io.
Editions are not lock-in; the entire point of the edition system is to allow the version of Rust that exists in 2032 to compile every prior edition in the same project at once, and only single crates at a time have to be 2030 edition.
Before making any change that could possibly be breaking, the change is tested on every single crate on crates.io, as well as on a great many GitHub repos that aren't, in order to make sure there aren't any regressions (referred to as a crater run).
You are right that the problems you describe would be problems if Rust was implemented the way you're implying. That is why Rust was not implemented the way you're implying, but rather implemented specifically to avoid these problems.
You're description of the versioning issue doesn't make much sense to me, at least assuming you're talking about editions. Editions are guaranteed to be supported indefinitely, and different crates can have different editions while still being entirely compatible with each other. So a 2032 compiler should be entirely able to continue compiling the 2018 project, even though the depended-on crate is now using the 2030 edition.
The way you describe yanking also seems a bit confusing. If the original project had a dependency that was yanked for security concerns, then the original project was already compromised in the first place. Even then, assuming the lockfile was checked in, then it should still be possible to download the yanked file (plus the compromising code, although the act of downloading a yanked file produces a warning, I believe). If you mean that the project was working fine (no compromise) and then a later version of the dependency was compromised, then no changes are needed at all - the lockfile will always ensure the exact same version is downloaded.
If you genuinely think you've found a situation that isn't solved by the edition mechanism, or by the judicious use of lockfiles for all projects, then I'm sure the Rust team would love to hear it (although I can't speak for them). But from what it sounds like, you're describing issues with the Node ecosystem and assuming they also apply to Rust, despite a number of differences in how the two ecosystems operate.
I don't think the Rust team are unaware of supply chain attacks, so you don't need to warn them. It's just that there's no easy solution. Or do you have some easy solution they aren't doing. Just to pre-empt you, namespacing doesn't solve the issue and manually vetting authors/crates is not something the Rust community wants.
I have, but to be honest I've forgotten a lot of the specific debates and their finer points.
I don't have a single, definitive, clear solution -- as pointed out by others -- nobody does. It's not a simple problem.
That doesn't mean that steps can't be taken to improve the situation, perhaps dramatically in some cases.
1) Enforced MFA to publish a crate -- credential theft is semi-regularly seen as an attack vector.
2) Strong links between the "source ref" and the specific crate versions. An example of this done super badly is NuGet. All of the hundreds (thousands?) of Microsoft ASP.NET packages point to the same top-level asp.net or .net framework URLs. E.g.:
Links to "https://dot.net" as the Project Website, and "https://github.com/dotnet/runtime" as the repository. This couldn't be more useless. Where is the Git hash for the specific change that "7.0.0-preview.4.22229.4" of this library represents? Who knows...
3) Namespaces. They're literally just folders. If you can't code this, don't run a huge public website. This is more important than it sounds, because wildly unrelated codebases might have very similar names, and it's all too easy to accidentally drag in entire "ecosystems" of packages. Think of the Apache Project. It's fine and all if you've "bought in" to the Apache way of doing... everything. But imagine accidentally importing some Google thing, some Netflix thing, some Apache thing, and some Microsoft thing into the same project. Now your 2 KLOC EXE is 574 megabytes and requires 'cc', 'python', and 'pwsh' to build. Awesome.
For example, in ASP.NET projects I avoid anything not officially published by Microsoft and with at least 10M downloads because otherwise it's guaranteed to be a disaster in 5-10 years. Ecosystems diverge, wildly, and no single programmer or even a small group could possibly stitch them back together again. Either it's a dead end of no further upgrades, or rip & replace an entire stack of deeply integrated things.
4) Publisher-verified crate metadata / tags. You just cannot rely on the authors to be honest. It's not even about attacks, it's also about consistency and quality. All crates should be compiled by the hosting provider in isolated docker containers or VMs using a special "instrumented build" flag. Every transitive dependency should be indexed. Platform compatibility should be verified. Toolchain version compatibility should be established for the both the min and max range. Flags like "no-std" or whatever should be automatically checked. CPU and platform compatibility would also be very helpful for a lot of users. The most important one in the Rust world would be the "No unsafe code" tag.
This would stop "soft attacks" such as the guy spamming C++ libraries as Rust crates. Every such crate should have been automatically labelled as: "Requires CC" and "Less than 10% Rust code".
Similarly, if a crate/package changes its public signature in a breaking way, then the publishing system should enforce the right type of semantic versioning bump.
Essentially, what I would like to see is something more akin to a monorepo, but not technically a single repository. That is, a bunch of independent developers doing their own thing, but with a cloud-hosted central set of tooling that helps gain the same benefits as a monorepo.
I'm expecting a lot of arguments along the lines of "that sounds like a lot of work, etc..." Meanwhile Mozilla had a large team for this, millions of dollars of funding, and did not do even 0.1% of what Matt Godbolt did in his spare time...
Good answer. Here is one more, and I got to say I am really unsure why it isn't done this way: Check each update to a crate for the usage of a TCP / HTTP / UDP stack usage. There is absolutely no reason a crate for math (for example) should be introducing any of that in its code. If you catch something like this, you can be 99% sure it's malware.
Or even better, make crates request permissions for what kind of functions they can call, similar to the chrome plugin API. A graph crate doesn't need encryption, file opening or netstack permissions.
Transitive crate "permissions" would be amazing. To know at a glance if a crate does networking, filesystem access, IO, etc.
Someone could always roll their own IO, but self reporting and automated detection tooling (to catch those that slip through the cracks) would bring this percentage way down.
Maybe the language could even evolve "unsafe" for IO, even if just as a flag for users. That way it would all be incredibly easy to audit.
Packj tool (https://github.com/ossillate-inc/packj) analyzes Python/NPM packages for risky code and attributes such as Network/File permissions expired email domains. It uses static code analysis. We are adding support for Rust. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down: examples https://packj.dev/malware [disclosure: I’m one of the developers]
One of my thoughts (see my profile) is "library mesh". You could register your code (or the parts that integrate) as a reverse dependency on what you depend on and they should build your code as part of their build to see if anything breaks.
Refactoring breaks everything - just look at Python 2 to Python 3. Part of the problem is having a bill of materials and having accurate tracing of the ingredients of a build, such as reproducible builds. But the time investment in these is hard work.
Computers are good at cross referencing. If you indexed everything in a graph database. It should be a simple graph Search to find dependencies of a git commit hash, binary sha256 installer file. And a web of sha256 relationships. And mapping between them and commit shas. It would be useful for security too but also interested in things being robust and reliable. Like you say it's a monorepository but not one.
Tooling is what's needed
The python packaging experience and ruby bundler and npm and other version manager experiences simply leads to common breakage.
> Similarly, if a crate/package changes its public signature in a breaking way, then the publishing system should enforce the right type of semantic versioning bump.
A common following-up question the Haskell people used to say when that was being discussed there is, if your build system can do that, why do you need semantic versioning for?
Still, it's better than doing nothing. There's nothing similar to Stackage or Backpack on Rust, so it would be a clear gain. It's just that you can go further.
I work with a lot of .NET Framework legacy code. Those nuget packages have even more useless links, I’ve had both official packages 404ing (to be fair, making their own links 404 is a specialty of Microsoft, for documentation they have the opposite approach as for windows, nothing should be backwards compatible -.-) but more often link to some modern .NET core (or .NET 6 now I guess) and thus be completely unrelated.
Yep, the Rust team and even the wider community are literally just ignoring this problem under the justification of "it's too early to care about these things yet".
Rust has been designed specifically to avoid these problems, under the justification 'it's never too early to care about these things'. I wonder what on earth you have been reading.
You are probably right, but there are differences. Languages like Go and Rust are much easier to get started with since they have better tooling, and more importantly, the tooling has a smaller and more regular surface. This is immensely important. Granted, they occasionally have unnecessary and stupid quirks, but they tend to be small (in terms of cognitive footprint) and contained.
In my neck of the woods, Python is the major source of time spent trying to get other people's code to run on my machine. The path of least resistance for Python developers tends to produce code that requires you to go through an easter egg hunt to make it run outside the original author's machine.
Yes, you could write Python utilities that are easy to install and run, but people don't. And the last bit of that sentence is the one that actually counts. "Could have" doesn't actually count in an engineering context. If the consumer has to assemble and repair software before getting it to run, the developer isn't being very professional.
I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift.
Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number of times various SSL libs are included in a single large and messy application), but it usually just works.
I had a similar experience with Rust when I first tried it a couple years ago. Wanted to make a web server which returns Hello World, and then this crate doesn't compile, this official example from the README throws a compilation error, that crate is the wrong version, etc etc. I tried again today and got it done in 2 minutes, so it seems things have improved.
MachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in).
Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.
Yes it's a problem, but because you (as a library maintainer) are responsible for what you are embedding, you should keep an eye on the dependencies and test them with each update. This creates a hierarchy of responsibilities, as opposed to a flat mess that is Linux .so or Windows .dll approach.
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 wrong way. C can at least tell you "this does not link" (so it was found but is binary incompatible) - in my experience if you copy and paste a node import line in the browser the browser will just say "this does not make sense to me." C gives more breadcrumbs.
I also think that once you get outside the C-likes, the story is universally better. For all of its packaging flaws, it's easy to get python packages for development.
Every time I want to make something in Javascript I'm frustrated all over again by how I need to know details about the Javascript ecosystem that I have no way of knowing at this stage (like: getting to hello world can require a working knowledge of WebPack). It's just no where near that bad other places.
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 the same to me.
> 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.
Hello world in JS doesn't require WebPack in any environment. This JS file will run just fine in both the browser, node, deno, whatever:
console.log("Hello, World")
There's absolutely nothing to stop you or anyone else from writing a JS file, importing it into an HTML file, and hosting both on GitHub pages. With ES modules you can now split your code into different files that import each other, and it all just works. No build step, no webpack, just JS files behind a server of some kind.
Meanwhile, if you're interested in using someone else's code, the CDNs are all still there. Vue, JQuery, lodash, and many other libraries are available for import directly into your HTML file.
A lot of people in this thread are conflating "all the tutorials tell beginners to do things the hard way" with "JavaScript is now a harder language to get started with than it once was".
There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.
One shock if you go back and forth between Javascript and, say, Java, is adjusting your library evaluation criteria.
It's not weird for a Java project to include a library that hasn't had any updates in 4+ years. Sometimes those sorts of libraries are even considered the standard for whatever thing they do.
Meanwhile in JS you have to assume a library with no releases in the last 6 months has already bitrotted to death.
I don’t think it is that impressive, though I have the most experience with Java, where a fat jar on a random, obsolete website displaying some university material will just work.
To make your comparison with fat jars closer to the point, imagine you got the source code from the owner of that old obsolete website, and need to use it in your newest Java project, with the bleeding version of Java, gradle and all the stuff.
The Go 1 promise[0] says that the language spec and set of core libraries will be backwards compatible. I maintain a few dozen go projects, some of which are 10 years old, and while upgrading from i.e. 1.4 -> 1.18 has been relatively easy, it definitely has not been zero work. There are changes in the tooling, dependency ecosystem, deprecated dependencies that should be replaced, runtime behavior differences, things like that. But the language itself and stdlib is totally stable.
I'm also sympathetic to the author but don't really see it as a problem. NPM modules are not apps on the App Store. They aren't intended to just be run by regular people quickly. The steps described in the article show someone hitting Node.js with a hammer until it gets closer to doing what they want without any understanding of what is going on. Which is fine, that's what people do often, but it isn't a failing of the tools when this doesn't work.
I don't expect to walk in to a workshop and find the welding tools intuitive to use with no training, and I don't expect npm modules to be intuitive to an outsider either.
I think C and C++ are a fair comparison in that their build ecosystems also a bit of a mess. I offer 3 counter-examples: Rust, Python, and JS-without-NPM.
edit: After reflection, I think Python straddles a middle ground. If you use modern packages and Python 3, it can be a smooth experience. If you use older (improperly-specified) packages, or FFI-wrapped-libs, it can turn into a mess too.
This is yak shaving. I mainly but not exclusively encounter yak shaving when, against my better judgement, I venture into the Opensourcelands. 10x more of it there, at any rate.
My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tutorials (unofficial blog posts) on internents, none of them work.
Front end dev work is broken.
Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.
And even then, browsers will probably respond differently.
After a recent FF upgrade, it balked at JS that worked fine for years ... on occasion, not always ...because: navigator.onLine === true, internet.connection === false.
Always wanted to learn about webpack - doesn't feel good using CRA (create-react-app), needing to configure webpack, ejecting CRA, and then being the "owner" of the config without knowing anything about it - thanks for the impetus.
The best part: all of the utils in the tool chains "evolve" and so your one script has to be regularly modified and kept up to date. A project that "just worked" but has been on ice for several months, will now not even build after you pull updates etc. It's infuriating. I used to work on a front-end team, and a good 20% of our time was spent babying the build chain, I kid you not.
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".
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 correct.
That "one link out of thousands" is the first page of the official docs for pretty much the only complex bit of getting started doing frontend.
If people are getting stuck because they're trying to get into something by following a "Frontend stack in 10 minutes!" blog post that introduces 10 dependencies and aims to skip all the actual learning bit in the interest of "getting up to speed" then they fucking deserve to get stuck.
There's only thousands of answers because everyone is too stupid to just go and read the obviously correct one and thousands of people try and exploit that for some industry cred or something.
I agree with this view, but not everything is black and white. Webpack is hard because it's a tooling, and a big and complex one at that. And usually it lacks resources other that official documentations in which can be used to learn/debug it.
However your view is also correct. They're too overwhelmed with the capabilities and complexities of webpack that they missed how there are hundreds of working webpack configuration for react etc, that they can use as reference, or how easy it is to be configured when you follow the tutorial and know what is babel, loader, presets, etc.
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.
Ok, I see where you're coming from. I'd call that "tedious" and "taking up a lot of time I'd rather spend productively". ;)
But snark aside - good point with the reference to Parcel.
I haven't had time yet to delve into the new generation of JS tooling that have come up in the last few years, but yeah - its approach looks much saner. (vite also looks promising.)
Its' just...sigh maybe I'm just a bit jaded WRT to project age/maturity. I mean, it's only 4 years old! At least it has a V2 already. ;)
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.
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.
> Once you understand how they look up modules from which to import things you need, you are set and can deliver a working program
Sure, being restricted to a single paradigm can simplify things in this regard but it comes with its own set of problems. I've used build systems and package managers for C/C++, Nim, D, Python and a number of others and they all come with their own headaches, learning curves, bugs, and WTFs. Software is never perfect, documentation is incomplete and inaccurate and sometimes shit just doesn't work the way you need it to. You can write terrible code in any language, if you need proof just do a filtered search on GitHub for your language of choice and page through some of the projects. I don't think JS is any more at fault than the rest, it just has more people learning it and hacking things together so you see more of it. It's not the programming language's fault if you write bad code, that's always up to your own proclivities and time constraints so I don't think we should try to pin it on the existence of such and such a module or library or the design of the package manager.
The hugely positive side is that there are a large number of people in the JS ecosystem actively trying to solve these problems and also educating others on how to solve their own. It's a bigger tent than any other programming language I've used, more active, welcoming, less judgemental and more beginner friendly. For people just beginning programming I'd still recommend starting with JS for those reasons.
You're kidding, right? Just going through the Concepts of webpack doesn't even scratch the surface - and will arguably leave many unsuspecting devs more confused than before, by e.g. still insisting on calling itself a "module bundler". You're a build system, ffs!
You cannot learn programming just by reading. Try using it in practice. The concepts part should be enough to get you started for a simple vanilla JavaScript project.
If you need more (e.g. TypeScript/JSX/CSS support), You will need some third-party loaders or plugins. webpack itself is just a JavaScript bundler.
So it's "You just need to go through the webpack Concepts section"...except if you want to actually do some work with it.
See, that's the thing:
If like OP you are an experienced developer freshly coming to web frontend development, the Concepts pages of the webpack docs will tell you very little that you'd find unfamiliar. It's stuff that you've seen a variation of in countless other build systems. (At least that's how it was with me all those years ago.)
But as the docs themselves say: "Plugins are the backbone of webpack". And that's where Pandora's box opens...and where the designation as "just a JavaScript bundler" becomes ridiculous.
JS tooling has come a long way in the last couple of years, Vite for example is so much better than everything that came before. Esbuild is incredible and clearly the future of all JS build tools.
The trouble is that to people who are only just outside JS ecosystem it’s not very accessible. If you are a PHP, Python or Ruby developer who cut your teeth in the era of jQuery or earlier (prototype.js & script.aculo.us!) it can be quite difficult to make the transition.
Combining the modern JS environments with platforms like Django, Laravel or Rails often means having to install and setup from scratch a full Node/NPM toolchain in parallel with your backend toolchain. I believe this is some of the reason for such a disconnect between the the “backend” and “frontend” unless you go 100% JS. I think it's pushed a lot of devs who used to think of themselves as "full stack" towards the backend.
I’m trying to fix this with Tetra (https://www.tetraframework.com) for the Django ecosystem, the plan is to eventually bundle a esbuild/postcss/sass/less toolchain along with built in tools for installing JS dependancies so you can completely live within the Python/Django environment. It will manage all the complexities of JS tooling for you.
The vast majority of developers don't want to think about tooling, they just want to build something quickly and get it out there.
I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing?
Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recently and it is lovely - no need for a bundler/compile step. There are concerns about load performance if there ends up being many modules, but you can do on-demand module loading via vanilla javascript (import returns a promise IIRC) for when that happens.
I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads
It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem
I'm not sure what the solution is, but I no longer use any packages which export only an es module.
I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things.
It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.
> Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?
They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification.
Normal exceptions for languages that have a spec based on a reference implementation.
That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation.
V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno.
Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8.
The Ecma International is basically naval-gazing at this point. They don't control JS, google does. Just see what happened when they added TCO to the spec and google didn't implement it.
JS isn't supposed to have only one relevant implementation, though, and still has two active implementations (SpiderMonkey). (And up until recently usually had at least three active. RIP Chakra.) That's absolutely a bug in the ecosystem that the Chromium hegemony has bullied its way into near monopsony.
It's good of Ecma International to keep standing up to that. It's better for the web.
> JS isn't supposed to have only one relevant implementation
I mean, alright, but the way things are supposed to be doesn't have any bearing on the way things actually are. And if you plan based on how things are supposed to be instead of how they are, you're going to experience a lot of pain.
> It's good of Ecma International to keep standing up to that.
In what way are they standing up to it? By keeping things in/out of the spec? My claim here is that the spec doesn't matter. If chrome implements something, people will use it, even if it isn't in the spec, and just let things break in other browsers. If chrome doesn't implement it, people won't use it, even if it is in the spec. You don't see poly-fills for chrome.
The same could be said about individual browsers. With web standards there is precedent for doing the "right" thing rather than just going along with whatever one product has already implemented and calling it a standard.
E.g. there were recent posts here on HN about WebSQL (already implemented in Chrome so many hundreds of millions of users) being replaced by a design agreed upon by all interested parties rather than just what Google wanted for Chrome and Gmail. Indexdb may not be what everyone wanted of course, but that is beside the point.
There is a place for experimentation and trying stuff out, but just shipping something first shouldn't mean you get to dictate future standards or be guaranteed backwards compatibility or a zero-effort upgrade path. Standards should learn from and build upon earlier implementations and mistakes. They should not be slaves to what has gone before.
You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here:
Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something?
I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too).
It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around.
It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in.
> I've started doing it recently and it is lovely - no need for a bundler/compile step.
Same here, I'm also doing on-demand module loading, it's an enormous productivity boost for me as a developer because of the shorter feedback loop, zero time spent fighting/configuring the tool chain, and how powerful the debugger in the browser is when it actually works. It's also a massive performance boost for the resulting web page because of orders of magnitude less code, and small entry point/initial page load.
+1 for Deno. It seems like it's taking the good ideas that developed from the node+npm ecosystem while filing off the unnecessary complexity that's accumulated in the ecosystem over the years. I've worked with node+npm+typescript/babel/webpack/etc for years and know the ecosystem pretty well, but I get apprehensive when thinking of starting a new project with it because there's such a deluge of not-very-meaningful choices and piles of configs for using best-practices while setting up a project. Getting into using Deno has been so refreshingly simple in comparison, and it's made me enthusiastic about starting new projects or libraries.
I've had some game/mod ideas for a while that involves having players write real code to interact with games, and I would create some tutorials for beginners to get started writing code so they can use it. I love Typescript and think it would make a good language for it, but I absolutely dreaded the idea when I realized using it properly would involve having to onboard users to all the tooling of Node+npm+build configs+testing tools+eslint etc. Onboarding users to Rust properly almost seems simpler in comparison because of its integrated tooling even accounting for the fact that the language itself is so much harder to use! I mostly scrapped the idea for the time being because of this, but now that I've discovered Deno I've been reinvigorated on the idea. A beginner tutorial involving Deno can actually focus on using the language with a few libraries without having the user get sidetracked into being distracted by a dozen other tools.
ts-node introduces its own bugs and ergonomics inconsistencies on top of node. I've used it on multiple projects in the past and ended up removing it as a dep when I've been able to.
Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.
> I've never heard of people putting typescript into a .js file - is that some node thing?
Node won't load TS files by default at all. You need complicated plugins like ts-node and few people know/setup ts-node, and I believe ts-node still expects Typescript code to be in TS files. It's likely accidental babel "bleedover" in that at this point even non-Typescript babel presets will strip Typescript types without warning.
Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is at. And this issue would have never been solved for normal people - the only reason this barrier was ever breached for this person was due to their large twitter following. Most people don't have that luxury.
So, if you think it's hard for someone who is already a programmer - think about how needlessly complicated the entire ecosystem and everything surrounding it is for the average person. It's no wonder many people basically view anything past the surface level of computers as dark magic, and we call people good with these magical devices "wizards".
Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past.
The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest at all (and live in blissful ignorance) or be so into this type of stuff that you might as well just make it a career. In between these two extremes lies a valley of frustration and needless complexity, where everything is always breaking and changing because we found out what was used 2 years ago is actually bad but THIS TIME IS DIFFERENT! because now we found a solution that is totally going to work forever this time. It's exhausting to even think about.
Many people got their start programming with something like messing with simple Visual Basic stuff. I, and I'm sure many others who are reading this, started with a TI-83 and a desire to cheat on my math quiz. I know that I'm going a little off the rails here, and this has become more of a rant than anything meaningful, but I really, really hate how there's quickly becoming no space for that sort of thing - nowhere for people formerly uninterested in technology and programming to get their feet wet, nowhere to make a quick application to accomplish a small task, etc..
I've been programming on the web since 1997. All the techniques developed since then still work. I still have a couple of "web 2.0" websites I've developed running at work... because while I nominally have all the language skills, I only dip my toes into the chaotic world of "the latest JS best practices" a few times over the years and have not been able to justify the effort of keeping up when it is changing at a higher frequency than I have needs. If someone drops me into a functioning project I can adapt quickly, but starting from scratch has become virtually impossible in any reasonable period of time anymore.
This really only hurts with UI stuff. Other JS I can write just fine; pure Javascript in the browser has gotten pretty powerful, it all but has jQuery built in now, you've got XPath, a templating language (simplistic, and needs a bit of XSS care, but adequate for small needs) and a lot of other useful things all just sitting there, but if you want a big widget setup there's a huge learning curve to get there, even for an expert programmer.
For the novice, "classic web" would still be a very powerful thing to learn that isn't too hard, but it's hard to find those references now underneath the pile of not quite functional tutorials, broken install instructions, entirely different languages creeping in (Typescript), etc. It's a total disaster for someone trying to learn this way.
I have quite a few non-technical colleagues who know just enough Python to Get Shit Done.
My father (a writer) taught himself R for research purposes and is productive with it.
Universal Paperclips has a super-basic JavaScript codebase[0] but was a really popular game.
Thing is, if you search "how to do X in Python" you're going to get a bunch of resources aimed at professionals because they're the ones looking for that stuff most of the time. That doesn't mean the resources are prohibitively complex, they're just for people solving a different problem.
I think he's a good contrast to the "great computer scientist, but not a JS person" in the linked article.
He initially built Universal Paperclips to learn JavaScript. It's a cool thing, a lot of people played it, and it doesn't rely on an incomprehensible ecosystem. It's two HTML files, four scripts, two CSS files, and an image.
You don't _need_ all the stuff people complain about to do cool things with JavaScript. Especially if you're just getting started with the language.
I agree. You just need to actually be a good designer :) When you have a fun and clear vision for what you want to build, it's hugely motivating and you're way more likely to finish
That's not what the linked Twitter thread is talking about, nor is it how I interpret "make a quick app for yourself, or make something small to share with the world" or "make a quick application to accomplish a small task." Those things are eminently achievable without having to embrace the level of complexity that's so popular in professional software development.
And I actually think the level of capability you're talking about is within closer reach than most people realize. Certainly it's much easier now than it was even 10 years ago. Probably not something that a non-programmer can accomplish on day 1, but I'm not sure there's many crafts that can be learned that quickly.
By "distribute," I didn't mean as a commercial product. I meant just sharing with other people. There is a huge difference between being able to tinker with Python/R and being able to make a package usable by strangers.
- to personal or ad hoc codebase for non-tech workplace
- to packaged code to cope with namespaces + type hints + general best practices
- to code that reads like good code from the major open source project
is long, but the slope is easy. There are no discontinuities. Basically anyone who can use Python to glue together networkx/sklearn etc. can eventually write software tools that are useful and stable enough to distribute.
If we have a middle class in tech, we also have the "temporarily embarrassed millionaires" pretending to be the top claiming everyone below them isn't good enough for something as simple as creating a few endpoints and vibechecking rather than checking skills.
And this extends all the way to the job market, where you now need 3 years of experience for a skill most people know how to use in about a week tops, and only lack the exposure of that skill used in a corporate setting. Where people will parrot "you need 3 months to not be a liability! (or more)" when those individuals will easily earn themselves back in the same timeframe. For projects where all you really do is create endpoints, process the most basic of information and expose it in certain ways. For reference, most people in STEM majors need to learn more difficult stuff in a shorter timeframe, with less help.
I had an interesting conversation the other day with our delivery manager and two other developers from another team, who had a wildly different than me assessment of a recent candidate.
Their argument was that he didn't know this and that and how is it that I deemed him worthy?
I interjected by saying that during these 30min I get to ask questions I don't have nearly the time to check one's skills throughly. And the same is true for them.
The most I can achieve in this timeframe is check whether the person won't be actively harmful to the project by e.g. being a charlatan or just malicious.
This was news to the delivery manager and they didn't approve of that.
I refrained from replying that our rates vs the market don't really put us in a position to be picky.
But I did tell them that I worked with "net negative" people(with examples) and it's really not about the skills at the moment of hiring.
It astounds me that software dev, historically seen as a field with and for "poor communicators", somehow believes its interviewers can do what top psychologists consider almost impossible to do. Same happens across almost every industry, but really, tech? "Cold hard logic" tech somehow became "yeah we can totally psychoanalyze someone in 30 minutes by talking"?
Worse, the lack of structure across the entirety makes it more of a lottery and a guessing game which is more or less sold as one's personal (in)capabilities. It's far more harmful than people make it out to be.
Or perhaps the interviewers are under-experienced, under-perpared and/or under-trained?
True story: I had an interview a couple of weeks ago. I was interviewed by two people who were younger than me, and relatively less experienced than me.
My CV has a number of links to repos for various side projects and such. Best I could tell, neither of them looked, at least not more than a minute. Not a single "Your ____ repo looks ____ let's discuss a bit..." Instead I got ovetly basic questions, some of which didn't map to the role / opportunity.
Furthermore, I could only find one of them on GitHub and it was routine stuff (e.g., wedding website). Apparently, neither understood I was interviewing them as well.
I'll never get that hour of my life back.
I have a phrase:
"How you hire is who you hire."
It's sadly funny how many outfits still don't get that.
My theory: most hiring absolutely doesn't matter (from the interviewer's side).
Most people will either have the skills needed or the capability to learn said skills. Weeding out obvious poor cases is easy, the remainder is semi-arbitrary weeding out of true positives in hopes of weeding potential false positives. Much of higher education alone does a good job at pushing people to learn difficult things in a short timeframe, with little incentive beyond "getting that paper".
Also, hiring is a lot like parenting, but the bad aspects magnified at least a few times. As you say, barely anyone knows what to do. No one has experience. Almost everyone claims to be an expert (not verbally, but they do act like it). Non-obvious bad choices often go undiscovered; as above, most picks themselves aren't bad (they just aren't great), or something else is blamed instead. Pride, neuroticism and personal bias play huge parts in the decisions.
Worst of all, no one actually reads the studies showcasing most of what hiring managers do have close to zero correlation to anything. I'm really just waiting for a mass study where two companies do an initial vetting, then company A throws darts at a dartboard and company B does the whole job interview shtick, and compare the results 2 years down the line. And maybe add a company C which actually does what studies suggest.
> Best I could tell, neither of them looked, at least not more than a minute.
I once interviewed a guy with a nice, short 1-pager résumé—not from lack of experience, just a solid, terse document. Not just out of school. Had three or four tech jobs in his history.
He listed one research paper near the bottom, that he'd co-authored in grad school.
I found the paper, skimmed it, and asked him about it in the interview (a lot of times in interviews I just ask candidates about stuff that it seems like they'd know about, that I don't know about, to satisfy my curiosity—I have no idea whether this is good or bad interviewing technique, but my intuition is having someone teach you about something you don't know, that they do, is probably at least as good as asking them to tell you stuff you already know) and he told me I was the only interviewer who'd ever brought it up at all.
My resume is quite similar. On the bottom, I have a link to something that I'm quite proud of under a small heading titled, "Ask me about it!" I've been interviewing passively / casually for the last 18 months. I've spoke to a couple dozen different organizations in that time. I've had exactly 1 person ask me about it. I've thought about removing it from my resume with the thought that maybe people are just put off by it.
Put off? Or lazy? At the end of the day the relationship comes down to "fit". Time and signals are very limited. A bad decision by either party is costly in a number of ways. You threw them a softball and they...couldn't be bothered?
Moi? I'd leave it. Them not looking tells as much as if they do.
I think it's a good approach. My position is: we're considering a possible long term relationship. We both have an interest in this meeting. That is, I hold as many cards as you do.
Those that see it otherwise? That to me a culture red flag. It's an easy swipe left.
I've found that unfortunately it's most often people at the peak of the Dunning-Kruger effect who volunteer to do interviews, so hiring decisions are ultimately made in part by those who vastly overestimate the scale of insight they can get from those relatively short conversations.
I had people get visibly angry during interviews where I was the candidate when I called them out on giving me a problem to solve, that they obviously had in their project and spent weeks on figuring out, while I was somehow supposed to do that in less than an hour.
Oddly specific interview questions are a red flag to me, because they indicate someone had a strong opinion on what's the "proper" way to solve a given problem.
I've gone through this before. The end result was that I was quite literally dis-invited from interviewing candidates. I left that place shortly thereafter.
I've started programming around 10 year ago without any Visual Basic code. There are so many more resources nowadays to get started programming, back in the day there was no way in hell you'd get something like repl.it where you don't even need to install anything.
What stops you from creating the most simple html page and playing with CSS? That counts as programming to me, there's also scratch for people who are completely new and want to learn.
A big issue is that 10 or 20 years ago the steps for creating a webpage were simple: just open notepad (or whatever) and put some HTML.
Today you "gotta" install node, yarn, webpack, react. Then you gotta make a package.json and configure webpack. Or replace webpack with something called "crap". At least that's what all the "for beginners" tutorials that everyone recommends says! Nobody ever said I could just use notepad!!!
But that's not exclusive for frontend.
20 years ago you'd get a random server with Perl. Probably free. 10 years ago you'd get a random server with PHP. You would use FTP and notepad to learn the ropes.
Today you must install some advanced editing software with some plugins, use a terminal, install some runtime or compiler, get some packages, which won't work, so Google tells you to use "sudo" so it works, but that's very suspicious. Stack Overflow says shouldn't be "sudoing" by the way, this is dangerous, you should actually install this "version manager" thing here to install the first tool you installed, so maybe uninstall the first tool, although there's no uninstaller. Oh, and you need this "package manager" tool that install the version manager in the first place. Then you gotta learn to deploy. At this point you're already too old for this shit.
Desktop apps? Good luck with that.
OF COURSE there are simpler solutions, like just making a website with HTML as you could before, or Jupiter Notebooks. But few people today will stumble on that by accident.
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.
3rd party JS code used to be snippets you were expected to copy-paste into your own code, or whole files you were expected to save and then load with a <script> tag before your own code.
Now there are like 50 ways to import JS code, most of them don't work most places, a lot of the code itself won't work in a browser at all (node-only), and a great deal of it is a pain to get into a browser if you're not fully bought into Node and probably also serving the whole "app" from Node.
It's about as easy to write your own JS in a browser, now, but it's vastly harder to start using code from the overall JS ecosystem.
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.
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 little or no interest in the web. Telling them to start with html + css is kind of like telling an aspiring painter that it's easy to start making sketches with a pencil and paper.
>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 HTML and CSS, stir in an endless bunch of half-baked support libraries built by people that just learned JS last month and you get the perpetual hell of the JS ecosystem.
And now that it has been adopted by startups and traditional companies, it is here to stay for a while.
Half of my development time when dealing with a new JS project is un-fucking some JS dependency that I never wanted that lives deep in the bowels of npm_modules.
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.
Maybe but it depends on what you mean by "back in the day". Because back in the day a lot of computers came preinstalled with some version of a BASIC interpreter, And some machines literally booted into basic by default, so programming became just a natural extension of the users daily computing process.
However, If you're referring to 2012 as back in the day, visual basic was by far and away completely deprecated by that point, if anything people would've been using Visual Studio community edition to do net programming and maybe visualbasic.net
This has been a professional concern for me for many years. I lead grad students with no programming experience into making their own tools for research and sharing. I've completely given up on learning a programming ecosystem and building programs from scratch. Rather, I work within applications that can be scripted to a task. I envy the engineering students for whom Matlab is enough, because that seems to be the closest modern equivalent of Visual Basic. Mathematica is sort of there, but much harder to learn and not easily shareable.
Yeah - I work with Python for my main work dealing with weather & climate data but things still throw me off. It feels like every example I run into is an easy to follow "20-steps + 10 packages + 64GB cloud server instance" process when all I want to do is to download some historical temperature data to CSV.
I think you sum it up well. That gap extends to more than JavaScript.
When I was four I could operate our TV: turn on, choose channel and adjust the volume. One device. One remote control. Bach then four year olds could also operate phones and record players. When I was five me and my friends could operate a tape recorder, copy music, record music, create tapes and physically share with friends and family.
There's space in tools like Godot, which has a relatively stable API, tight and helpful integration with its custom scripting language as well as support for both C# and C++, solid docs, first-class support for 2D, the ability to export to mobile as well as web and desktop, and the ability to toggle between a continuous rendering mode suitable for games and a reactive rendering mode more suitable for apps.
GameMaker, too, has a very stable API for its proprietary scripting language and, though it is made with 2D gamedev in mind, can work just fine for simple apps for personal use.
Or you just ignore all the shiny new things and go with older technologies that work like a charm. I for one, still write code in jQuery, and don't plan to switch at least for the next five years.
Yep exactly right. Do as much as you can with plain HTML, CSS and JavaScript. Learn the basics without depending on any packages. And only then maybe add a package if it really absolutely is worth it compared with writing a bit of extra stuff yourself. Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed.
I’m pretty sure you can still write some js and load it into the browser or node. The issue is that 10 small instructions become a hundred (thankfully) and so if you read the wrong article you will be lost.
If this guy was told to use `require` instead of `import` it would have most likely just worked. The instructions were wrong so he failed.
Even back then though you still needed to RTFM. The first time I wanted to do a bubble menu (the one that follows your cursor, focusing an item of the menu) I was redirected to Flash.
On a related note I think this is what is sort of wrong about the raspberry pi as tool for teaching beginners: the first thing the user sees and interacts with is Linux. In the 80s on a bubber key spectrum as far as I can recall it booted straight into a basic prompt / repl (or whatever the right term is). Even 8 year old me could start programming. Compare that to trying to get anywhere with Linux as a beginner.
I think in this particular case, the problem was just picking the wrong tool for the job. Python is the primary language used for data science these days, but it is not particularly designed for it. It is a general purpose programming language. If they had chosen something like R, their path would have been a lot smoother.
Smoother but not smooth. I once, not by choice, taught R to humanities grad students who had never programmed before. The wailing and gnashing of teeth over the course that semester was considerable, and I have stoutly refused to ever do it again. The irony of it was that they really didn't need to do anything that couldn't be done in Excel.
> We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself
it seems Excel is the last place like this - to make small pseudo apps, but it comes with its own fair share of problems (mostly calculations or Excel as a database, no sharing)
I think VBA used to be the thing, but the one inside MS Office is "technologically" stuck around year 1996
Well, not really. The no-code tool of the 90s was Access or maybe Excel. VB was useful exactly because it was code, but simplified. One thing the Microsoft stack really nailed was a smooth(er) on-ramp. There was a big gap between VB and C++ which is partly what motivated the development of C#/Java but otherwise, you could start with Excel or Access, move up to VBA and build an actually useful app that delivered business value. Then you could take those skills and move to VB6 and build "real" apps that you could ship to users and charge money for, build whole businesses around. You could learn some Win32 using VB/Win32 interop and then progress to C, and from there, to C++, or later from VB to VB.NET and then C#.
The web stack sort of killed all that. You can start with HTML and get some results pretty fast but you'll very rapidly hit the limits of what can be done there and suddenly be hit with this giant wall of complexity. NodeJS helps because now you can use the same language on backend and frontend, but even getting to the point where you have a frontend and backend requires mastering a heap of tech with appalling usability (like UNIX). And the modern JS ecosystem is sufficiently complicated that you'll hit problems like the ones described in the article.
One way to fix this is to bring the VB6 model back, by making desktop apps great again. It can be done. There are toolkits that make it easy to write standalone cross-platform apps (e.g. JVM languages+JavaFX, Flutter, the new C# stuff, Qt, etc). There's no fundamental reason distributing desktop apps must be difficult, it's just a neglected area of tooling.
And that's a nice segue to my current startup, which is tackling exactly that problem. We've produced a tool that makes distributing desktop apps as easy as distributing web apps is (or easier!). It takes the output of your build system (if any) as inputs, and builds self-updating packages for Windows, macOS and Linux without needing you to actually have any of those platforms. It can also fully sign those packages itself (without needing macOS or Windows), or self-sign them in which case you get a `curl | bash` type install experience and the PowerShell equivalent for Windows. Finally it produces a simple download HTML page that detects the user's OS and gives them a nice big green button to click.
We've talked to one well known tech firm that wants to integrate this into their products and a driving reason is, in fact, educational. They have a lot of new programmers who use their developer tools and who learn with a desktop toolkit because it's easy to get things on the screen, there's one language to learn, it's all cleanly following the principles they're taught in class (like objects) and so on. But then they hit a wall when they want to show their friends and family what they're doing, or graduate to actually getting real users. Smoothing that on-ramp should help a lot.
At the moment the tool is in private beta, but if you want to try it email me (address in my profile). After public launch it'll be free for open source projects, licensed for commercial projects. Thinking about a feature that automatically bundles source and adds a "view source" button to the apps, to help students who haven't yet mastered uploading code to GitHub.
> the only reason this barrier was ever breached for this person was due to their large twitter following
I feel like their approach to solving the problem actually does represent how most people deal with it - they ASK someone. There are hundreds of massive programming discord servers, with extremely engaged tutors, helpers, and resources.
If you want to learn to program, you'll need guidance, and I think that's OK. You won't go buying any old welder and some metal and just start welding (or at least it won't go very well). You'll seek out people who already do it, get advice, or maybe even seek an education in it if you are really aiming for the long term.
Programming looks like it has a low barrier of entry, because you don't have to commit to much. To weld you need to buy (or rent) a welder and material, to do carpentry you need to buy at least some basic tools, to work on your car you need a car, to be an architect you'll need to pay someone to build it, etc.
For programming, you seemingly only need a computer (or even just a phone), which most people have access to. This apparent lack of need for commitment makes it look like "it shouldn't be that hard", but that's IMO a complete misunderstanding.
This is why I'd prefer hiring people who have at least somewhat of a formal programming education. In my university, for example, we learned how to use git, linux, write JS, CSS, html, c++, php, do SQL, manage and design databases, and generally just learned a lot of "background knowledge". With that, it's trivial to pick up almost any tech afterwards.
For anyone else trying to get into programming, join a discord or reddit, or slack, or matrix, or IRC community, which is focused on what you're learning. It will save you weeks of trying.
Have you ever actually tried to do this? Programmers are extremely opinionated people. If you somehow manage to get past the barrier of "pretending to look smart so you can even ask a question without getting flamed to hell and back (hello, stackoverflow!)" you will be met with people suggesting different things, which quickly devolves into a giant argument about which thing is better and why this guy is so stupid for liking that thing over this thing and it becomes absolutely impossible to get anything done.
And again, there is a baseline expectation of knowledge that people have which is far, far too high. Even if, by some miracle, you get someone telling you to type "xyz" in the terminal, I doubt anyone has enough patience for the next question of "what's a terminal". This is the baseline understanding we need to allow for and the vast majority of tech enthusiasts, programmers, and others just don't get that.
Yes I have tried to do this, and I do this kind of "helping others" a lot on discord.
StackOverflow is about the worst helping platform. That's not the kind of platform I was talking about, I was specifically mentioning discord and reddit. r/cpp, r/c_programming, and some discord servers like the "programming" discord are great.
I see what you're saying, but that is NOT the experience I've had at all on most communities other than StackOverflow. I really urge you to actually try it and have a look.
I'm one of those learners and this is true to an extent. But there's fantastic people in r/learnprogramming for example. Even better than the Discord of the self-paced bootcamp I'm doing...
But the complexity is real. I'm learning Django, which is supposedly easy, and it's a completely different beast than learning the in and outs of a language. And Django has good documentation, for some libraries it's a mess.
Meh, I'm following the path they tell me. You're probably right tho, but I guess they want to make me employable.
I feel that I will use Django for personal stuff in the future too, so althogh it is comples I have enough drive to get through it.
I can't be many hours on it though. Programming was much more motivating when I was learning the basics, I could be coding all day with no problem. I loved the challenges they sent me.
Setting aside Django and learning it as a beginner, the job market for Python as a whole is a bit odd. It's great for grad students coming in from other disciplines but pretty harsh and credentialist towards the more typical self-taught web dev profile.
That said, both the concrete things you pick up with the language and the meta skills you pick up fighting with frameworks, libraries and dependencies will come in useful. Keep learning and you'll be more employable. Best of luck! I've been there.
>I doubt anyone has enough patience for the next question of "what's a terminal"
Have you spent time trying to teach people stuff?
Most people have no idea whatsoever how to learn things. Instead of asking "what's a terminal?" and getting a grunt in response, they won't even ask.
Learning things greatly outside your expertise needs a huge time and effort investment towards grokking the basics of the subject.
Most adults are goal-oriented, which means they won't do the hard work of really getting the basics, nor even think that maybe they should be asking, reading and writing down stuff they don't know that won't immediately help with their goal, but is fundamental to not end up bumbling about cluelessly.
The standard behaviour is like trying to solve differential equations without knowing what a function is. Just trying stuff works if what you are trying to do is piss easy, and it won't work if it requires any building blocks / isn't piss easy.
Instead of looking at a term they don't understand and grinding until they understand it (which is often a recursive endeavour), they are just trying to make it work.
>With that, it's trivial to pick up almost any tech afterwards.
The fact most of the market does not align with this at all kind of shows to me the contrast between "passionate people willing to help get stuff done" and "a brutal corporate market where everything not perfect nets you a fat zero, despite projects being way more samey and boring". The job market for juniors is absolutely brutal and it is already expanding to other levels to a point where if you mess up or don't have the "right experiences", you're still effectively a junior still according to the market. Through no fault of your own. Couple that with a "we're looking for i+1 experienced people to do i-1 work" mentality and the number of corporations which don't do this being extremely limited.
On top of that, tech also has a large "trial-and-error" part to it which most people should be willing to acknowledge. If we're not mutating upon existing solutions, we might as well just package the existing thing into an instant solution. The mutating on existing solutions is the difficult part.
This thread for me looks like a narcissistic attention seeking rather than real process.
She could simply start learning on datacamp - i went back to it after many years and it's perfect. Low level of entry, "box where you write python code and it runs", you don't have to install pandas, but course will teach you to do it if you want.
She began this thread from saying that she started a few courses... Hard to believe. Or she didn't wanted to pay for it to get them at a professional (in educational terms) level.
She wants to analyze her data - cool, but seriously, it's like any ignorant person would say that they want to do anything that requires some expertise... I want to build a car, why it's so difficult?!?! Twitter help!
Read the rest of this persons twitter, or their website for that matter.
No I don’t think there is anything enlightening whatsoever about their experience “trying” to learn to program. They spent 10 minutes installing the interpreter, and then got upset for their social medial followers because they weren’t immediately able to write software to do something useful with their CSV.
I cannot think of any other discipline where “I bought a woodworking shop and then couldn’t immediately make cabinets 10 minutes after walking inside” would be considered insightful towards anything other than the person writing it.
There are SO many people who spend their time trying to help others program. Literally thousands of them. “Aella” could have spent an hour watching any of their videos or reading any of their tutorials instead of this.
I think the problem here is that there's so many tutorials, articles etc telling people that if they want to do data analysis then the best way is to use Python without making it clear that this advice is predicated on you already having a programming education. If you start with a CSV file and want to do some analysis, without knowing programming, then you need to using a spreadsheet app, but this context isn't being reliably given to people. Instead they absorb a background assumption that "real" data analysis is based on programming and immediately drown when they try it.
It's no different in woodworking. I'm constantly turned off when I try to start by the fact that basically every easy-to-find woodworking tutorial assumes you have 3-4 different power saws already ready to go in your garage. It's hard to find content that gets you started with basic tools on small, inexpensive projects.
Experts in any field are usually terrible teachers because they don't understand anymore what it means to be a beginner.
(As an aside, I'd love suggestions for woodworking content that does start small.)
Would be very easy to make with basic hand tools. In fact, what might be fun is to just look at the picture of that, and try to reverse engineer the parts for it. (I teach woodworking classes, and this is actually an exercise I make the students do in one of the classes).
This is a handheld saw, but it's a very nice one, and could absolutely be used to make many, many things out of wood. You can use it for almost anything, and people do.
Honestly, reading the thread from my perspective (as a self-taught amateur) I get some of the frustration, but also see that the tweeter was their own worst enemy.
The basic basics - how to install Python, handle modules, and maybe execute scripts, would have been dealt with in the first few minutes of many beginner tutorials - and would have handled all of their initial teething frustrations.
And while I get the desire to build something real (I don’t think I’ve ever completed a full tutorial as I always dive off into what I wanted to make in the first place) not even being willing to sit for an hour to learn the basics is far beyond ‘goal oriented’ - and is obviously seriously limiting and self-defeating.
If using Photoshop is driving, programming is building an internal combustion engine vehicle. You cannot expect to just randomly google for car-making tutorials and get an SUV done in a weekend. Heck, you can't even expect to be able to build a very simple combustion engine from basic principles without a lot of study.
I'm not saying this is Aella's fault or anything, it's fair to have wrong expectations, but calling this "needlessly complicated" is not fair either.
If I had to take something away from that Twitter thread is how marvelous is that someone without any programming experience has been able to programatically manipulate CSV data in a couple of days.
I also think that Aella had abstraction mismatch. Python does not know what CSV is when she tries to "Okay, cool. I want to upload a csv, the data I want to analyze". It sounds to python identical as if you said "Make me a sandwich". You need to explain to python what a "sandwich" is, using abstraction that python understands. In CSV case this work is done by pandas.
So for that first you need to LEARN what abstractions python has and how to use them to build higher level abstractions.
It's like being angry at hammer that it cant be used as surgical scalpel. "it's a tool, so it should do what i need"
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.
Not every programming project is a project that takes hundreds of skilled engineers. Not every programming project needs to deliver a product for others to use.
What Aella wants to do is something pretty simple, and it's frustratinc that this is so hard.
> What Aella wants to do is something pretty simple, and it's frustratinc that this is so hard.
What Aella wants to actually do and how she describes what she wants to do may not have any relationship to each other. So we've got a potential X/Y problem.
Then there's just the jumping in assuming Python is like Photoshop. You can "learn Photoshop" just by playing around with it. You won't be a graphic designer after a week of goofing around but you can make a cool logo for a web page or touch up photos you took with your phone.
What Photoshop is to a selfie, Python is not to a CSV file. Even "CSV file" is ambiguous because that can actually mean a lot of different things.
The difference between the Aella case and the story in the OP is Aella is assuming Python is Photoshop for CSV files. The OP knows JavaScript is a language and has a notion of how npm is supposed to work. Aella got bit by ignorance and stubbornness. The OP got bit by terrible tools.
> What Aella wants to do is something pretty simple, and it's frustratinc that this is so hard.
It's not that hard.
Doing it like a Real Data Scientist is hard, but also completely unnecessary for a beginner non-programmer. That doesn't stop well-meaning folks from advising that approach (install pandas, Jupyter, anaconda, etc.) and overwhelming people.
The Python standard library is batteries included. IDLE exists.
I think the problem is that there are so many options, some more accessible to newcomers, some less. For example, I think Thonny is a nice entry level Python "GUI"
But it's really hard to find what to start with from a google search.
> I think the problem is that there are so many options, some more accessible to newcomers, some less. For example, I think Thonny is a nice entry level Python "GUI"
And I think users tend to grow out of entry-level tools pretty quickly so it's hard for any one option to become universal.
> But it's really hard to find what to start with from a google search.
That's true, but I think it has a lot more to do with the quality of educational material for beginners than the simplicity or complexity of available tools.
>I don't wanna learn how programming building blocks work as I use them to build a lil rando pile, I want to learn how they work as I use them to build the actual house I want.
Well, unfortunately some things are difficult, and knowing fundamentals helps you with those difficult tasks. I also don't complain that I can't learn to fly a plane by starting the engine with zero knowledge and learning while taking off. The author then goes on to say that in four days they learned everything they wanted to do, without any programming background, so I don't understand why these tweets are written in such a dramatic way
This was my thought too. When learning to drive, I don't really care about what the clutch is or does, I want to know how I can go from my house to the shop, or my house to my friend's house. But I understand that I need to be aware of the components and processes that go into driving a car. I can't just sit in it and expect it to whisk me away.
That Twitter post seems a bit whiny. The expectation that a general purpose language, basically a huge professional toolset would be readily obvious to a non professional who doesn't even grasp the concepts of variables in imperative programming.
If I would step in a wood workshop I don't expect I'll be able to produce much without first aquiring some basic skills.
The OP thinks that being Goal oriented should give them magic abilities to understand the tools without learning them. A Very odd expectation...
This doesn't absolve Python though, the whole dependency story is rather bad and the language have many warts. But, The ecosystem can never be simple enough for someone like the OP while still be an OSS distributly developed general purpose seelanguage.
The person in that twitter thread clearly has some issues beyond learning Python, their response was extremely angry, dramatic, and entitled. "Angry tears welling up" is not a reasonable response to learning anything, especially when not having a deadline and just learning it for fun. To me this reads more like a mental health breakdown live streamed on twitter than of something that actually says anything about Python. I wouldn't be comfortable interacting with them at all
> I think my genes are wonderful, I’d like to see more of them in the world, and I don’t have any immediate plans for reproducing myself.
> If you’re interested in using my eggs to reproduce, I’m down to discuss this in exchange for payment for my time and fear of needles. I have ancestry, health testing, and family history I can share.
> Contact me at aellasinbox@gmail.com; sometimes my responses go to spam, so be sure to check spam!
> a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person
This is always true, but I think it's a slight misdiagnosis here specifically. The problem isn't over-estimating competence but under-estimating complexity.
I've watched a bunch of very smart, highly-competent people bounce off JS; that's not a fault with them but with the ever-changing and overly-complicated ecosystem.
On the thread: Author has unrealistic expectations. They should pick up a Python intro book and work through at least the first couple of chapters. In the time they cluelessly floundered around they probably would have had most of their outstanding issues cleared out.
An astonishing number of people here are missing the point. Doing something like "making a small script to analyze CSVs" has become a massively complicated undertaking requiring you to follow random guides that might be 6 months old (practically half a century in these circles), install random programs and dependencies using other random programs and dependencies that you don't even understand, and do many steps that seem like completely nonsense.
Yes, it's incredibly complex. It doesn't have to be and a lot of it is completely unnecessary, driven by the tech world's inability to stick with literally anything for more than a few years before collectively deciding it's all trash and you should REALLY be using this brand new thing that only half works instead. It doesn't need to be this hard, and that's what I'm trying to say. Using this to shit on the person for thinking their simple task would be simple is completely missing the point - if anything, it proves it.
The author of the tweets doesn't seem very interested in learning the basics. They want to open Python and magically start processing CSV.
That's not how that works. CSV processing is an easy task if you know the basics and read the manual. The author wants to skip the boring parts that are essential for the easy part of their objective. They get frustrated with terms they don't know and tools they haven't heard of but seem unwilling to read up on their problem, instead copy pasting stuff until it works and then looking up what went wrong afterwards. Yeah, you're going to have a terrible time learning anything if you're not willing to understand the basics before throwing your frustrations at them until they work.
If I go into a sculpting class saying "I don't want to learn about materials, I came here to sculpt my own version of Michelangelo's David" then I would be told to shut up, sit down, and start learning.
Just because someone can't get their instant gratification doesn't mean there's anything wrong with the field of programming. If you're goal oriented then you'd better be willing to learn every single requirement for reaching that goal or you won't succeed.
I think the fact that the author managed to learn how to process their CSV in four days is a testament to how far we've come. It took me weeks to get to that level on my own with the manuals and offline tutorials I downloaded on the school PCs.
Manipulating csv has become way easier than it was.
You have:
1. Spreadsheets where you can import this data and manipulate it visually
2. CLI tools made especially to work on csv, with fancy colors, shortcuts, examples
3. Visual tools for data analysis like google data studio, power bi etc. Where you basically dragon drop the data and pick charts
4. RStudio where you can load your data using file->open and then copy some simple commands to work on it
5. No-code tools where you can copy paste the data and add functionality by clicking through tutorials
6. All kinds of online notebooks where you don't have to install pandas...
swear to god if one more person talks about the specifics of this illustrative case, and then goes on to explain how they are so silly and should have used tool "xyz" my head is going to explode
You don't need to use any tool, it's a general purpose programming language, so "making a script to analyze csv" requires you to learn the basics of programming and what csv is.
It's not unnecessarily complex, but expecting people to handhold and teach you programming for free when you haven't shown any commitment to learning is silly. If you were to do this, you will essentially be writing programs for clueless people for free and they just move on(they may not learn anything).
If you want to learn programming join a bootcamp or a hacker group or get a formal education(where people will be paid for this).
Python does not know what a CSV file is. It doesn't know what a JPEG is. If you want to work with these things you have to tell Python what they are. If you want to use a library to do that you need to know how to install a library such that Python knows what it is and where it is.
You can play around in Photoshop because and get decent results because it already knows what a JPEG is. All of the tools are built around working with 2D images and share a set of abstractions. You might do a shitty job but you're not likely to break your image or be unable to do anything.
Python is not "Photoshop for CSV files". It's not Photoshop for anything. So you must learn some basics to use it an Aella decided learning was stupid and she could just copy and paste her way through the process.
A rational person confronts by terms they didn't understand in some instructions would take a step back and realize maybe they were missing some fundamentals.
For this profile, a fully integrated environment like Squeak/Pharo or Racket would be a better option. Perhaps even just Emacs! :-)
I won't disagree with you about the needless complexity, but OTOH programming does have a certain level of essential complexity, and profanes don't realize that "just upload the CSV" is fundamentally not an easy task; think about what you'd need to do if you were to do it from scratch in assembly. Lines in a text file is not something "the computer" or many OS have a concept of. I think a few developers could ragequit.
Of course, there is the "batteries included" solution - that is gluing together libraries with a simple language. Here I would rather see something like Lua rather than Python because OO is already an interference for normies. This is doable, the particular failures of Python here (or any of the languages I've mentioned) are to blame on Python's ecosystem (perhaps being too normie-friendly is a curse, because you sometimes end up with poorly done tools and libs - I see it in Lua too).
One last word: I learned programming from books alone with Basic (back in the days when phones had wires and I didn't have to shave). The books provided the source of simple games that I were to type in (Basic was a CLI but you could list and edit lines, better than the "Python Box" :-), test and then hack. This is a much easier approach than starting from scratch, and by the end of the Twitter thread it seems that this is what this person eventually came to - people would give them a basic program they could hack.
> I don't wanna learn how programming building blocks work as I use them to build a lil rando pile, I want to learn how they work as I use them to build the actual house I want. If what I'm learning isn't connected to a payoff, then I lose the stamina to wade through the problems.
> It's no wonder many people basically view anything past the surface level of computers as dark magic, and we call people good with these magical devices "wizards".
The dirty secret is that, due to the consultant effect, that feeling tends to owe its existence to those "wizards" who are happy for things to remain that way (and go around making it so where it's not already).
I am going to help make people free through computers.
I will not help the computer priesthood confuse and bully the public.
I will endeavor to explain patiently what computer systems really do. I will
try to answer people's questions kindly, or explain that I do not have time.
I will not treat any question as a dumb question, since there is no such
thing.
I will not give misleading answers to get people off my back, like "Because
that's the way computers work" instead of "Because that's the way I designed
it."
I will stand firm against the forces of evil. I will speak up against
computer systems that are oppressive, insulting or unkind, and do the best I
can to improve or replace them, if I cannot prevent them from being bought or
created in the first place. I will fight injustice, complication, and any
company that makes things difficult on purpose.
I will do all I can to further human understanding, especially through the
new visualizing tools of interactive computer graphics.
I will do what I can to make systems easy to understand, interactive wherever
possible, and fun for the user.
I will try not to make fun of another's favorite computer language, even if
it is COBOL or BASIC.
> vastly overestimate the competence of the average person
Computers have gotten vastly more complicated to program than they used to be.
The reason for this is, other programmers are not really motivated to make it easy.
It is also wise not to underestimate the fact that intentionally incompetent interfaces make it all a ball of puke. Most programmers are puke surfers these days, maybe not so much in in the embedded world so, but for sure up front in the ''mainstream'' of javascript/web development.
> Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at.
Sorry, no it does not. It shows me a lot of people are perfectly competent but lack the motivation or proper expectations. Once the person gets more into the data analysis, I'm sure they'll realize why tutorials just don't show how to do data analysis.
And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag.
It still does today, making prototypes easy to write, training very simple, and yet, it plays well with the more complex ecosystem.
Now of course, VueJS has Vite, which makes all the complexity of Webpack goes away, removes the slowness of compilation and has sane defaults.
Still, npm remains. I'm now used to it, but I understand that if you come from another language, it's not attractive.
It's funny to me that most people consider JS packaging better than Python packaging.
Both are troublesome, just for different reasons. E.G: using different versions of node is much harder, espacially on windows, or for the same project, than different versions of python. And installing compiled extensions is a way better experience in Python than in any other high level language. On the other hand, node_module is easier to use than the average venv.
> And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag.
This is exactly, what I noticed positively about VueJS and advertised as a good feature for integrating this specific "web component" framework into a project. You can add it as simply as one used to add jQuery to any project. However, others thought of including script tag as "not proper" (even though I told them, that in the end it would all be a script tag anyway ...) and it was decided to use another framework, which is way more complicated to integrate in any statically rendered / server side rendered and template based website.
Simply putting VueJS in a script tag is not a problem. One can cache it easily and one can use noscript tags at places in any page templates. All is fine.
Now this inspired me to the great idea that we all should move to microservices in the browser, running as concurrent background tasks along a managed message bus, as soon as possible… (Functional programming and modules are dead, browser microservices are the future! We may even launch our web app in a fleet of redundant windows/tabs, by the this greatly improving stability!) ;-)
Also, include WebRTC for distributed remote partitions! (For redundant peer to peer backup, call your Ma and ask her to join your session as a distributed backup peer. If your computer dies, she'll still have the data. Now she really shouldn't close that window until your gear comes back from service…)
I always go into these things hoping the outsider will be an Amish farmer or professional welder, but it always turns out to be just another programmer.
I am "just another programmer" (more familiar with PHP and Go than with Node however), but when some Node module in some project I have to work on starts throwing the kind of obscure errors mentioned in this article, I sometimes feel like an Amish farmer...
I know a construction worker, a recruiter and a mechanical Engineer, among other random professions, that moved to JS without much trouble. It somehow seems overwhelmingly that it's other fellow devs that have trouble with getting started JS.
TBF right now JS is in transition from commonjs to ESM, and we all believe for the better, but this transition period does yield some strange issues like the article said, for instance I hope/expect that "Warning: To load an ES module [...]" will be default in the near future so we won't need that warning anymore.
Also knowing JS enough, if I see "SyntaxError: Cannot use import statement outside a module" coming from a package I'd know that the package is wrong, at which point I would just try to find other of the 2M+ packages, open the JS file to see how it works if I'm really interested, open an issue or assume the project is just broken (which just happens, not all packages are well built).
The difference likely is that they didn't do what these people did - try to use some package from scratch. It's much easier to take a sample and extend it, especially if you can join a team and hop onto their running, fully-fledged project.
The JS tooling story _is_ convoluted, and most people just don't touch that stuff, or when they do, they start from a working place, and just make small tweaks.
A little longer than that. Everything went to shit basically as soon as Node hit the scene—not sure if it can be blamed for it, exactly, but the timeline fits.
I was hoping a young Amish farmer goes on his rumspringa to decide if he wants to continue on as Amish farmer, he likes the modern world well enough but is so scarred by the JavaScript experience he runs back to the safety of the church, never to stray again.
I know a few people whom keep up on tech trends, even though it has nothing to do with their job.
I follow programming trends, basically through HN, and self study. (I have wasted a lot of money on programming/Computing books.), and I'm basically a Jack of all Trades in life.
I'm a mechanic certain years. I'm a contractor certain years. I'm a Electrician when I am very low on money. I'm a Watchmaker whenever someone asks me what I do. (I hate that last sociatial question. When did it become copacetic to ask for job status, and finances. I guess it came with the Selfie. (I didn't use a question mark on purpose. Too disenfranchised today to care.)
I do miss the days before relying on bloated JS libraries.
I miss the LAMP days for my personal websites.
There was a free server I used to use, but forget it's name.
It allowed full domain names without their branding. Like mysite.com, instead of mysite.com.branding.
I know Git, Google, and Amazon offer a free page, but I just don't like learning their way of putting up a site.
As you can by my verbage, I'm not a professional.
But for some reason I try to stay current on certain aspects of this industry.
> I'm a Watchmaker whenever someone asks me what I do. (I hate that last sociatial question. When did it become copacetic to ask for job status, and finances. I guess it came with the Selfie.
It significantly predates the selfie. Tyler Durden mocked the question in Fight Club before smart phones existed, and it was already very old then. I'd bet money you could find films and books in the '50s that document that question (I think I know of a novel that does, but I'd have to double-check to be sure). I bet the only reason it'd be harder to find in 18th and 19th century literature is that so much of that was by and for aristocrats. Pre-industrial-revolution, perhaps it was an uncommon question.
It makes sense in a world where most people spend the best 40+ hours of their week working a job for wages, lose another 5-10 good hours to commuting to that job, and the rest of their waking time is spent desperately catching up on neglected housework and recovering from that 40 hours. It's only outliers who are bugged by the question, or see it as presumptuous. These outliers usually have settled for a lot less than most people are willing to (materially, and maybe family-wise—this'd be your Tyler Durdens, your actually-poor-and-not-just-slumming-it bohemian sorts or members of Fussell's "Class X"), or else have found themselves in a situation where they're much richer than most people but don't have to work all that hard for it (some of the Fussellian upper-middle, especially later in their careers, plus your usual trust-fund kids).
You don’t really have to get an outside’s perspective. I’m a literally JavaScript developer with a long career and I’m still incredibly annoyed by the state of JavaScript tooling. Fixing those errors on larger projects isn’t exactly a walk in the park either. I constantly find broken packages because people simply don’t understand how Node ESM work.
Every build tool has had a decade to figure ESM out and they still all suck at it. Rollup is the only “somewhat” savior because it’s “almost” ESM-only.
Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful.
Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.
ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-mostly dev since 2013, and I've had enough of ESM ideologues.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
ESM _is_ the future, but not the present, and I wish people would stop foisting it on packages before its ready.
I use JS/TS every day. I tried to understand the intricacies in module/import issues. Just reading about it gave me a headache, and tempted me to just rewrite my entire project in Rust.
The compatibily issues with NodeJS dependencies (aka CommonJS modules) and ES6 modules is one of the most painful parts of Javascript today. But at the same time, I wonder if it could have been avoided. Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it. So it's understandable that NPM made some mistakes in the beginning
> Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it.
They drew a lot of inspiration from the Ruby ecosystem and its gems. It was even a lot of the same people contributing. Somehow, they ended up with a much worse tooling story, though. I think a lot of it stems from the browser/server divide they had to contend with and the worse common library.
That's funny, every time I think that I should invest a bit of time to actually learn JS, someone comes along and says "a mess in JS at the moment". I can hack something to a working state but I never feel I have a full grasp of what's happening... But I grew up on assembler 35+ years ago so all this magic is unnatural. :-)
The problem is that most devs expect agility but many modules live for 10 years+ based on whatever they were based on back in the day with no real desire to rewrite it with the latest package management thingy.
So then we end up with a mix of old and new and the promise of "moving to a bright new world" that just won't happen. As another poster said, since we know that package management is a pain, we should be able to solve all of these issues when we create a new language eco-system, not rush to get the exciting part released with "hello world" and wait for the problems to roll in later.
Interestingly, nuget as a philosophy isn't terrible but there are extreme performance issues and crazy things like not tying a package to a specific feed so if you install it, it asks all of the feeds if it has a copy, most of which will 404. Updates usually take an age but once they are installed, it usually runs OK :-)
It's the thing with every tech ever, first you need to know (way to many) intricacies, and then the tools evolve and you don't need anymore... I remember having to fight sound cards and modems on linux once, or (slightly more recent) days of having to manually install and set up every single service for local dev environment, which basically required a linux administrator level of skills from a developer, plus a lot of time and patience - and nowadays you just type a single command and drivers work, docker is up with your project ready, you're done in minutes... it's the normal path of evolution for these things...
> It's the thing with every tech ever, first you need to know (way to many) intricacies, and then the tools evolve and you don't need anymore
In an ideal world, sure. In the world of software dev tools, not always. We've regressed from Delphi and Visual Basic that allowed anyone with some data to pop up an application quickly to use that data, to the current state, which every popular language in industry (and even some unpopular ones like Rust or Haskell) make it well-nigh impossible to do very simple things.
We've gone from empowered computer users writing programs to solve their own problems to helpless computer users who cannot write programs to solve their own problems.
Sure, you may point to Excel and derivatives, but those existed back in the 90s too, and VB/Delphi existed as an intermediate point between problems that are simple enough to solve in a spreadsheet and problems that need less than a tech expert.
Maybe this is why salaries are sky-rocketing: we've collectively made everything so much harder to get into that fewer people are able to solve their own problems.
That's not how I feel, to me honestly the things got significantly easier and quicker in last 10 or so years (I primarily work in js and php now)
Sure it's not the same as it was with Delphi or VB that would install (and in case of VB also build into exe) everything you might ever need, but e.g. it's still a lot simpler than VC++ used to be back then - just figuring out all headers you need to include to compile an empty app was a horror - so it was definitely not like everything was "simple stuff" friendly back then. And doing web dev in those early days was far more complicated to setup...
Nowadays IME once you figure out how to setup the tool chain - and there's a plenty of boilerplates and starter kits for that - you more or less just rinse and repeat that every nest time. Sure sometimes package managers go berserk on you, but otherwise my experience is that - once you've figured it out - it all just magically works... but it does take some initial effort and time to figure it out properly.
And if it's really simple stuff that I need to finish quickly, I just skip the whole package managers/ build tools deal, and write a script, include and link what I need manually and run it from CLI/browser just like it's 1998 :P
Is there a steady move to ESM within the node (rather than browser) ecosystem? Because it seems that CommonJS is used for new projects by major companies.
I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through).
Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard library, and its not guaranteed that a Node package will also run on the browser.
Deno tries to fix it. But I think everyone should ask themselves: is it really worth it? The backend and the browsers are two different environments with different needs. Why making novices think that the two are interchangeable, just to disappoint them a few moments later?
Ryan Dahl recently said in a talk that *Deno deploy* and *Cloudflare workers* are just v8 runtimes, they are not Deno nor Node, with all the serverless trend it seems to makes sense, also now that we are going back to SSR (now that react supports it officially) we can combine it with SPA (check remix.run for nested routes, nextjs is also working on that) and lastly hydration, so you can now serve plain html, that will be hydrated when the page loads all the JS, it seems like a win win for all those sites/apps that needs/uses React and the users (you will see the content faster than before, just like good old days).
Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great.
Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting.
If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good.
My issue has probably more to do with npm than with Node itself.
I can totally relate to this, even after working professionally with Angular for 3+ years and generally with JavaScript for way more than that.
I recently set up a quick JS project from scratch that needed a few different npm packages and ended up spending more time understanding the >three< different ways I had to use to import the different packages (because the returned errors were utterly useless), than actually writing the business logic...
This is a problem with all kinds of programming for new learners - actually writing some code is easy. But getting a development environment configured to actually allow you to start writing that code requires a ton of tacit knowledge.
I find this to be the biggest hurdle to new joiners. When I was first learning in my grad job, my company did a terrible job of addressing this and threw us into a test project with no support and expected us to navigate Git and React through our own wits and poor ability to Google. What Microsoft is trying to do by introducing live coding environments into Github is a fantastic step forward.
As a consequence what one should actually strive for, if one is aiming to become a professional software developer, is to have a good process for mastering these types of “configuration” tasks. Understanding why language ecosystems are organized the way they are, understanding the trade-offs involved etc. I believe, will make you a significantly more productive developer.
It’s where I see a lot of junior developers plateauing. They keep “banging their head against the wall until it works” instead of carefully unpacking why things are breaking in order to update their mental models.
There's no mastering configuration tasks, because it's all arbitrary unilateral decisions made by randos and committees of randos. There's no logic to finding out which arcane formatted strings need to be placed where in which text files in which directories, otherwise every single thing fails out of the gate. I used to complain about having to spend my time on this even as a senior.
This is exactly my issue with all this modern JavaScript / Node-stuff.
The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow.
Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.
If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools.
Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to do effective things in Javascript these days as it is very capable on its own.
I usually do use Vue and Quasar via UMD (?) directly in the browser together with http-vue-loader, which makes it bearable and is pretty powerful as well, but then there's a lot of handpicking with libraries like dayjs (when used with plugins) or TipTap which then just doesn't scale, so you need to start to use some tooling. So you fall back to the recommended tooling and then it begins.
Python is a mess too! There is pip which works great(if you’re lucky), but then the scientific community moves to a different variant of cinda like every two months, which just isn’t necessary usually and way more complicated than just using pip
Oh yeah I personally dislike python a lot because of all the pip and easy_install and anaconda nonsense that exists (existed?). It is a shame that python for some reason became the defacto ML language that people use - I do not really understand how that came to pass (sure there are lots of libraries that help with ML now, but that is a bit of a chicken-and-egg situation)
Try http://deno.land - think of it as sequel to node (written by same guy who created node, aiming to fix mistakes of the past - e.g. deno does not use NPM)
Don't code with JS on the server side at all. There's no real advantage to having JS both on the server and in the client, and there are plenty of alternatives that actually support the features Typescript and the like pretend exist in JS, but really don't.
That sounds like that should have started with "Don't code with Typescript on the server side at all" instead. If Typescript is pretending things unsuccessfully, you might as well stick with plain Javascript. (It wouldn't surprise me if Javascript ultimately lived longer, just like Smalltalk actually outlived Strongtalk in the end.)
Deno, as someone mentioned. Also, Civetweb embeds Duktape. Also, txiki.js embeds QuickJS. So there's at least three other options with varying features. You should try Deno first, though.
I'm not a fan of node, but python is horrible in this regard, especially with package management and environments. I'd take "make random js code work" to the python equivalent any day, which is already a bigger challenge nowadays because of the chaos caused by the ES module transition. Other challengers are C++ (because people get creative), C# (1000 different runtimes and library support) and Java (I don't know where to start).
I have a love/hate relationship with Go but this is the area where it shines.
Agreed, but as for Python, it doesn't have to run in both CLI and the browser, where both are entirely different environments. You don't need to transpile-and-typecheck from Python-with-types to Python-you-can-run. And yet, there are enough complaints about trying to get other people's Python to run on one's own machine, even in this very comment thread.
It is so true. I have seen experienced developers pull their hair out for a day or more trying to get a basic build system working, or to import a simple module.
I have been that developer.
I have been that developer, tried to communicate the lessons learned to other developers, and ended up finding out they couldn’t learn from my mistakes and had to reinvent the wheel with many hours of frustration anyway.
I develop in Node and Sveltekit regularly and the chances that on any given day my flow might be crushed by random madness is unacceptably high.
I feel like the point of the article isn't so much "how do I solve this specific issue" as "this is the general state of JS packaging", and the solution you present doesn't work in the general case of larger, less trivial dependencies
But the thing is, the general problem of packaging is a complicated system, and the current solution developed are there to solve those complications (which adds more complications unfortunately).
However, the article wasn't about this general problem of package management. It's a problem of somebody wanting to test out some code, and went down the rabbit hole without understanding what they're doing (not a slight at them - it's hard to know what to do).
Ideally, you don't go down that route, because testing out some code doesn't require solving the packaging problem.
I think they (as in author and the friend) need some expectation adjustments about how easy it will be to get some random code package published for free on the web to work, regardless of the programming language.
In other news I am quite annoyed by the confusing range of hardware and how difficult they make it to bolt a fencepost to a wall: There are masonry bits, high speed steel, different sizes, different anchors. And then getting the right length screws. I seem to do it all right but the post keeps slipping out.
Eventually there will be dropbox-like disruption of both node.js and diy hardware, but until then just do the normal 10-20 hours of mandatory training (like udemy courses) to get the basics down.
I have had plenty of issues trying to get packages from Rust working. Half of them depend on external libraries and its up to you to work out what package for your distro satisfies the compile. And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult.
I don't blame any of this on Rust. You can be expected to be proficient in the tools as these are not end user products designed for someone with no training.
Bit of an exaggeration. Some do. I would say more than with Go, but waaaay less than half. Maybe like 1/10th. OpenSSL is the most annoying.
> And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult.
I don't understand this. Of course you have to work out how to use a third party library in your code. Do libraries in other languages magically integrate themselves?
It's still mostly the same. Nothing much has happened in the JS space in the last 2 years that would make all this easier.
The JS ecosystem suffers from a huge issue of duplication. There's multiple module systems, multiple ways to make a function, multiple ways to make a class, multiple ways to make a variable, multiple ways to loop over the array. Some of those exist in other languages as well but it's pretty bad in JS.
The problem is a language where you can do anything but where every day something has changed and the new something is the new cool. Now you have to ditch what you learned + the libraries to migrate to this. Or you have to use babel.
The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import.
Aside from that JS is a great language. No, just kidding it's a mess.
The whole issue of JavaScript is that the standard library is worthless, so people have to write additions to keep yourself sane as a developer.
This makes it seem that there are 5 billion ways to do something, because there are.
Just use TypeScript, it will fix all the issues you have with the language itself. Typing + build time errors + import/export syntax. If you want to run some this in the browser, and don't use Vue or React, it will still require manual work to setup webpack + babel
I still hear this hypetrain argument a lot, but only on hacker news. This hypetrain you have been talking about is however not the case anymore. JavaScript + TypeScript have been stable for the last 3 to 5 years, the only big change in FrontEnd development was that people have been pivoting to server side rendering.
As a fullstack dev, the most hypetrain stuff I see is with infrastructure. Docker? Kubernetes? Terraform? Combined with 15 different ways to do the same thing in AWS but worse, no thank you.
Typescript doesn't solve any of the mentioned issues. You can't use CommonJS modules if you are targeting ES6+. And you can't use ES6 modules if you are targeting CommonJS. The only thing really useful about Typescript is types + generics (to some extent).
If you install any library that's either only ESM or CommonJS, you can't run your program. It simply doesn't work.
I rarely, if ever, have to reach for anything outside of the standard library for computation/algorithms. ES6 added most, if not all, the building blocks to build 99% of the computation you'll ever need. What's missing that you'd deem as worthless?
> ES6 added most, if not all, the building blocks to build 99% of the computation you'll ever need. What's missing that you'd deem as worthless?
Not the same person, but date/time manipulation is one area I've encountered that's incredibly frustrating (especially when timezones are involved) without libraries like moment. Cross-browser functionality only compounds the issues.
> The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import.
It's possible it's more confusing on backend node, but on my current frontend project I can import any module without caring what type it is. Yes, I have to pick one import syntax, but I'm not sure why I'd want to mix them.
You don't realize what's required for all that to work properly. Webpack + Babel at the least. Expecting that a beginner developer will have to learn these to write even simple programs is absurd.
I set up the project myself, so, yes, I do know what's required. :)
For this project, `vue create my-project` and choosing TypeScript was sufficient.
I've done it before by configuring webpack and babel by hand, and yes, that can be a pain. I certainly wouldn't recommend a beginner start with that, but the existence of complicated options doesn't disqualify the simple solutions.
Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.
No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.
Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.
Not quite sure why you shouldn't be able to create a proxy service that serves NPM packages in a form that Deno can consume if you feel the overwhelming need to use NPM packages. (I don't, personally, but tastes differ, I'm sure.)
I've spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads
It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem
I'm not sure what the solution is, but I no longer use any packages which export only an es module.
Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something?
Sure the interoperability between things that do and do not (pure ES6) require a build/bundle/whatever, and between JavaScript and TypeScript may remain an engineering challenge, but that's not for the ES6 modules spec to solve, right?
I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern.
It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
It says quite a bit that when I got started coding (with minimal access to the internet) and not much experience understanding "cryptic" error messages, I was able to compile the Linux kernel and bootstrap gcc without a native compiler on Solaris.
My day job used to mostly be Python. It can be a confusing ecosystem. I teach it to students and I can see the trouble they have. Other languages are different. With C projects, I can mostly get them to work. In fact, it's not too hard to even compile nodeJS from scratch. I've even had some amount of luck fumbling in the dark with languages I'm not familiar with to submit pull requests.
Javscript is a whole different ballgame though and I fully sympathise with John. It's very counter intuitive and even when I've been in the thick of it, I've had to squint quite a bit to make sense of how the ecosystem operated.
At an old job we affectionately referred to the process of setting up the environment and getting started as "figging" (short for configuring). It's the worst part of any dev's job exactly because it's not programming.
The examples in the article are all realistic, but I'd like to add something important: This is using the NPM ecosystem and JS dependencies.
A language's tooling and ecosystem are arguably part of the language itself for practical purposes. So, the article is a fair assessment. I'm making this distinction because you can use JS in what it accels at without invoking build tools and dependencies: As an imperative language making DOM manipulations without the IO-induced latency of querying a server and waiting for a response, JS gets the job done.
> I'm making this distinction because you can use JS in what it access at without invoking build tools and dependencies.
Theoretically, yes. Practically, no, because almost all javascript code is written in typescript, packaged into modules and distributed on NPM nowadays. There's the tiniest inking of a "vanilla js" movement out there, but otherwise all of the libraries and tutorials and advice assumes that ecosystem is a given.
I know how javascript works, I was writing javascript before JQuery was a thing.
The problem is, there's no ecosystem around plain javascript anymore. You either write everything yourself or, as OP discovered, have to work with NPM packages.
Here is what I did when I had to create a fairly complicated web application with no prior experience in web development (but 20+ years of developer experience in other environments): I started by learning the basics: HTML, CSS and JavaScript. Without relying on any build systems or packages. And only then adding a build step or package if it really absolutely was worth it compared with writing a bit of extra code myself. It worked like a charm. I completed the project in a few months with very few dependencies. And the build “system” was simple. Which should be kinda obvious when you think about it: Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed. So the less you rely on external tools/packages, the more stable your code will be. And the more you understand the basics, the more you are able to fix problems with code you didn’t write yourself. The downside of course is that you have to invest more heavily in the basics (HTML,CSS,JS) but that is a good thing. The time you spend becoming an expert in fashionable build tool X or package Y is a waste of time. Something else will be more fashionable tomorrow so your hard earned expertise is wasted. It is a bad investment compared with deeply understanding the foundation (HTML,CSS,JS).
There are learning Javascript resources targeted at non-technical people and children interested in learning how to code... one of the more promising that make it easy to start coding and experimenting with code is p5js (https://p5js.org/learn/) a Javscript port of the wonderful Processing framework... beautiful and simple APIs to start coding...
I'm mostly a designer and I've been trough the same experience trying to learn the ropes of modern ES6 javascript development and this matches my experience fully.
On the same note, it took me days to wrap my head around:
- The small differences managing modules ( even simple stuff like inclusion paths using "~" vs "node_modules" vs ../node_modules" vs...) between build environments (Webpack vs Parcel vs ...) or even between different configurations for stuff like webpack and babel.
- The module format used by different libraries. Some use only the es6 module format, some use the CommonJS standard, some use both, plus a few oddball packages that are still released as global JS libraries.
- Specifically on the last one, I've yet to find a way that let you use global packages in webpack that works all the time. Sometimes you have to declare them as globals (jquery), a few other times you have to just include the js file, and in a few cases (p5.js) nothing seems to work properly. Parcel seems to require some extra plugins for this that I've never been able to configure properly.
- I've tried doing some REST requests using fetch and no matter what, It always seems that there's something completely wrong with CORS and the Access-Control-Allow-Origin parameter. I've tried using both a local dev environment and a remote host, with docker and bare metal, using nginx and apache using the required headers, with SSL certs and without. Obviously I'm doing something wrong, but it never feels like there a consistent logic in what should be the right configuration to avoid such issues. For every guide that suggests you to do X there's another that says you should be doing the opposite of X.
I guess a lot of languages struggle with the balance between Communism and Dictatorship. If you allow genuine communism, people don't agree on things, stuff gets built to different levels of quality, some of it maintained better than others etc. You end up with the problems we see in lots of package management.
On the other hand, if you have an individual or team who dictates how stuff gets developed, what is an acceptable level of functionality, getting rid of stuff that is not maintained etc. then it is possible to build a much more reliable package management system but perhaps get less people getting involved because they can't just offer what they feel like but only what is accepted!
I think some languages suffer less because they really invested in the standard library including a tonne of stuff avoiding the need for external packages. .Net, Go and Python are like this I believe.
i wonder if this kind of pattern emerges natuarlly from a community of experts.
think of how you need lawers who studied for years, to understand whats going on with laws and regulations
a similar pattern most certainly emerged within the german tax system.
maybe the complexity of the health system is (in part) a similar pattern.
i hypothesis that a community of expert will reiterate on the rules that are present within the community, over and over, until only experts who studied the topic for years can even begin to deal with it.
perhaps there is even a self regulating mechnism. you need to understand a system to a certain degree in order to contribute. at some point the group who can contribute consists soley of experts who studied their field for years. those experts will then contribute and make it slightly more complex. the complexity raises but only to a degree that allows a group of experts to "catch up" with the complexity in order to contribute themselves. if it gets "to complex" it runs out of contributers
It is not only javascript, the entire world of programming lacks things that just work like other non-programmer’s apps do. Most people are smart enough to automate their everything when given a set of decent tools, but instead they have to rely on smartasses who speak 90% buzzword religion and only get a vague idea of what the requirements are, cause they are mostly specialized in being themselves. I hope this “industry” will break under its weight some day and we will realize that our daily topics are irrelevant to homes and businesses. Modules vs non-modules vs node vs browser is a bullshit that should not exist, but it does, for stupidest reasons. One of them is being “amazed” by obviously average-to-questionable parts of our stacks.
You'll see both on must-read lists for design and design thinking. But many of the concepts - sometimes in an abstract sort of way - apply to engineering.
Krug's is relatively short and easy read. Norman is broad and thorough. Both deserve their tag of "highly recommended."
from an insider's perspective, javascript is better than it has ever been. ES6 has fixed all significant shortcomings 8 years ago, and at this point you don't even have to transpile it
the "community" however is as shit as ever, but you can easily ignore it.
Package management just breaks package management and software distribution most of the time. It just shouldn't be used, when not necessary.
Just put your things (and the dependencies) into a single downloadable folder.
Especially with javascript, it is one of the most stable things ever, everything written in the past 27 years just runs on every device, on every environment, without any problem. Heck, you can't even navigate yourself into troubles, i bet if you reverse some javascript files, browsers still will figure it out. Try that with any other top TIOBE languages.
If you take the credo of don't reinvent the wheel to a fanatical extreme, your best practice devolves into a ritualistic appeasing of the wheel gods to bestow wheels upon you.
Just spent an hour this morning helping a customer's 2 js devs do a hello world setup because of the first one. And even as someone experienced here, it still took me 10-15min to untangle the core issues. (In this case, enabling esm as in the article, instructing babel to preserve module imports, and then some whackamole of individual imports.) Every individual step made sense in isolation, just not in aggregate.
Beginners just run angular/react/vue cli and restrict themselves to first-class compatible dependencies that can be installed with one loine. This way, quickly creating something useful that is good enough is easy for the novice.
But yes, the plumbing the cli controls and sets up for you is insanely complex and overengineered.
No doubt: The standardization of modules in Javascript was a real screw up.
I hope the people involved are embarrassed enough to figure out how they are going to avoid fails like this in the future. (But I suspect they pat themselves on the back and each other it was a total success.)
I think it's a very bizarre assumption to think that running some code you found on the internet will just do exactly what you want right out of the box. That almost never happens.
Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver?
As if you were able to instantly run whatever code you found on the internet back in the C++ days. It's bizarre. Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like toxic false entitlement open source maintainers are typically showered with.
>Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver?
Node.js is giving the author bullshit. They were not unfamiliar with the field. They knew what a package manager was, they already had NPM installed. They were familiar with the architecture of the web and one of them had a CS degree.
>Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like more of the toxic false entitlement open source maintainers are typically showered with.
I find the premise that the bar should be set artificially high just to keep people out to be toxic, especially with a language like javascript that's intended to be accessible to everyone. Generations of people learned how to code by studying (and ripping off) source code on the web, but now those people have grown up and surrounded themselves with shibboleths and want to pretend they're in a rarified air where high spec engineering expertise should be required just to get past the gate. And that's all most of the JS ecosystem is - gatekeeping.
We're not talking about linking some arcane C program here, we're talking about a scripting language so simple it doesn't even know what integers are - no not even modern JS does - designed to be written in Notepad and run in a browser.
Yes, this should have been simple, or at the very least much simpler than it was. Yes, it should be possible for someone who isn't a full stack developer to be able to run javascript code, even with a package manager, even random code they find on the internet, with minimum effort. Yes, it's actually easier to link and run random C++ code than it is javascript at the moment. Yes, that is a bad thing.
Well, I disagree with everything you say (especially calling this gatekeeping). You simply are unwilling to learn about the tools you're working with. I'm sorry we couldn't work it out. Best of luck!
I can see what you're saying. I agree and don't think it's ignorance, which is why I'm calling it false entitlement. It's all open source software, maintained by humans just like the rest of us. I'd say, go do something about it if you care so much, instead of complaining.
We just need all this tooling to go in the browser.. which is where it always belonged. That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly.
As for my own rant, simply the fact that Microsoft, of all places are the ones who run TypeScript and now the proposal to add TS to native JS.. is part of the issue. MS has zero imagination.
JS needs native typing and it shouldn't be done by MS, and it should be a limited subset of TS with no particular intent to be compatible with MS's TS. Then and only then JS becomes its own thing again.
>That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly.
It's not getting there, it was ALREADY THERE. Javascript has always "just run" in the browser.
We don't need any of this tooling. Typescript isn't necessary. NPM isn't necessary. None of this is necessary. They're useful, yes, but they shouldn't be mandatory. The simple act of testing some code you found on Github shouldn't require any of it.
TypeScript and C# are both great languages from Anders Hejlsberg. The Danish know how to design a language, C# developer was Mads Torgersen. Microsoft employs them so they want it used more and people like it.
Fun fact: Anders Hejlsberg also designed Turbo Pascal, Delphi which were huge in their day.
I agree though, JS needs to just run in the browser. All the tooling is really a leaky abstraction or unnecessary guts that get in the way. Rant: Webpack is an abomination to anything simple and clear, many dev hours are lost on it.
I still think if ES4 hadn't been cancelled for ES5 we'd be in a better place. It had amazing typing, event handling and was very clear, essentially looked like TypeScript. Browsers could have easily supported ES3 and ES4, we'd have a more solid browser "just works" setup.
> Webpack is an abomination to anything simple and clear, many dev hours are lost on it.
Check out Vite. It's basically Webpack with sensible defaults. Still the same bundling paradigm but it's been so much easier for me to use. Also way way easier to add plugins in Vite.
The author encounters four problems trying to approach a programming task:
1) A problem common to every programming language (feature introduction/deprecation compatibility conflicts w.r.t. import/require)
2) A security issue around browser filesystem access (not-JS related at all: HTTP content-type sniffing)
3) A usability issue with the VSCode IDE (not JS related)
4) A bug in a single JS module
Concludes this is all the fault of "modern Javascript", gives up.
> What hope do actual novices have?
Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them.
Don't get me wrong, there's A LOT about the modern JS ecosystem that could be improved from a UX perspective, but... it's not these things. I don't think any of the 4 bullets above are avoidable: (1) is a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features ever. (4) is human error - it happens. The others aren't JS-related at all.
> Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them.
There's a lot of assumption packed into this statement.
Those speedbumps used to also not be there—they were put in recently[1].
Also, having read through your comment first and then read through the article (fully expecting to find what you describe), I'm compelled to say that your summaries grossly mischaracterize the substance of the complaints actually mentioned by the author.
> a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features
Well, no. The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. They created the preconditions that led to the demand for their solution. This problem/solution cycle is rife in the NodeJS/NPM world. The only way to deal with it is to opt out[1][2].
> Those speedbumps used to also not be there—they were put in recently
> having read through your comment
It doesn't sound like you've read my comment at all: 3 of the problems I listed are not new at all. The one that is - modules - is a result of two colliding independently standardised implementations from one language (commonjs vs ecma).
> The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks.
I'd genuinely like to hear an elaboration on this. You may be right but just stating doesn't make it so (your two referenced articles are just people who dislike JS railing against it for its own sake, nothing really constructive)
> It doesn't sound like you've read my comment at all
Well, I did.
> I'd genuinely like to hear an elaboration on this.
You already alluded to it. NodeJS's take on modules (which are not CommonJS[1]) were never a good idea, and they were never standard, least of all in any sense that matters.
Too many people treat the NodeJS project and its associated silliness like it's the be-all and end-all of "JS". It's not. It's a single, standards-incompatible runtime packed with proprietary features leading to obvious pain points (like the module fiasco) that are foreseeable from a mile away.
> your two referenced articles are just people who dislike JS railing against it for its own sake
Wrong. I happen to like JS. It's why a spent a huge chunk of my time (before NodeJS was even a thing) making sure that there were high quality JS docs available on developer.mozilla.org, and it's why I wrote that post diagnosing the problems with the NodeJS culture that can (and should) be fixed to repair the JS onramp to be friction-free the way that it was before (and repair JS's image from the damage done by the NodeJS project, cf OP).
But it doesn't sound like you've read them at all (nor does it sound like you're able to meaningfully separate JS from NodeJS yourself).
1. Isaac S: the best thing for me, and for node, and for npm, was just to go off the reservation and focus on the things that I knew mattered. Ryan basically always gave zero fucks about CommonJS anyway. One evening at Joyent, when I mentioned being a bit frustrated some ludicrous request for a feature that I knew to be a terrible idea, he said to me, "Forget CommonJS. It's dead. We are server side JavaScript."[...] we went pretty far off the reservation in v0.4, with the whole node_modules folder thing, and loading packages via their "main" field. Maybe we should remove those features, I'm sure that Node users would appreciate us being more spec-compliant!
In terms of early days serverside JS, I was mainly a Flusspferd user (outside of earlier Rhino & lots and lots of awkward XULRunnering), so I do get where you're coming from. Node was absolutely the mainstream enemy in the early days, and for me strongly represented the antithesis of what the ecosystem should become, including CommonJS.
But that battle was lost and at this stage Node realising late is so so much better than Node never realising at all.
It's also such a familiar story across ecosystems. Node gets all the flack because it's the browser-similar language platform and browsers have been where it's at for a long time (and will continue to be). That's neither a flaw nor an asset though - other ecosystems deal with very large (different) problems despite not having as many challenges to overcome as JS does.
Given how little "getting" there's evidence for in your previous comments and how quickly you resorted to the most convenient strawman at the time (that I'm just some "people who dislike JS railing against it for its own sake"), this is doubtful.
I can't say I get where you're coming from—too difficult to locate the logical throughline in your comment and how it relates to (a) the specific issues raised in the original article, and (b) your original mischaracterization of it.
One thing in particular I hate about Javascript's platform is how much time you have to spend on learning the ever-changing tooling. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going.
The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore.
Python venvs and pip are easy enough to understand. Cargo and dotnet are also clear enough if you read their help pages. NPM and Yarn, however, only do a fraction of what you'd want them to do out of the box, forcing every tool out there to set up their custom system of helpers and tooling just to get them to run.
This is largely centred on browsers these days (ironically it used to be better for browsers and worse for server, now it's the opposite).
However I'll say two things in javascript's defence:
(1) No other language has yet taken on supporting server and browser environments simultaneously: it's unlikely to be easy for the first.
(2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers
> The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore.
No idea what you're talking about here though. Is this about NPM? What 6 different ways? What tooling extensions? This sounds like vague projection.
> Python venvs and pip are easy enough to understand
If only "understanding" was near enough. Good luck putting together a robust unattended install routine for anything python: does the user have existing venvs, should this script create a new one, where?, how should the user easily init it?, should it be a global init??, autoinit via bash or shortcut via bash alias? What about Elvish? What about fish? What about <Python is a horrible ecosystem, please don't get me started on its ills>...
> (1) No other language has yet taken on supporting server and browser environments simultaneously, it's unlikely to be easy for the first.
ASP.NET has allowed you to write purely backend code and add interactivity forever. Of course you can't get around JS in the front-end, but a mix of backend and frontend code existed long before Node got any popularity.
> (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers
I agree. Then again, the Node ecosystem always seems to be moving from one standard to another.
Regarding point 4: more people need to realise picking the right NPM package in the JS ecosystem is becoming a "must-have" skill, but the only way to find the right package is still to be constantly up-to-date with the ecosystem, endless google searches or hoping someone on Twitter can just tell you what's better.
FWIW, I work in security and this skill is becoming very well automated in that domain.
It's imperfect (and always will be), but there's a large overlap between manageable libraries and securable[0] libraries.
[0] In the software-composition analysis field, "securability" is not only about upgrading vulnerable libraries but also about how many vulnerable transitive dependencies you may have to upgrade in future.
The problems are all eminently avoidable, though. It's all death by a thousand cuts stuff.
1. Churn in something as basic as how modules work isn't common to every programming language, actually that's pretty specific to JavaScript. Java modules remained the same for 20 years, and when the 'new' module system came it's opt-in (you can pretty much ignore them and many people do because a 'new' module is forwards compatible and can be treated as an 'old' module as well).
2. They were only trying to use the browser because they had problems with Node and thought it'd be easier. The fact that there are security issues loading stuff written by the owner of the computer itself from disk is more an artifact of how browsers work and how they evolved than anything else.
3. The usability issue wasn't really with VS Code. It's that the default behavior of browsers on encountering stuff they don't understand is to ignore it and plough on regardless, so they got no error message and at that point were stuck. If they hadn't had Lee on hand their adventure would have ended here because Lee simply intuited what was wrong based on past experience. The fact that browsers routinely leave you looking at a broken page with either no error messages to help you, or a uselessly vague one, is a problem caused by (again) how browsers evolved, it isn't fundamental. More robust development environments don't have this issue. If something goes wrong you get an error, always, and it's usually helpful. You never just get nothing and are left wondering what happened.
4. The "bug" here is that you can't use TypeScript directly in a browser (why not? again, mostly complicated browser related tech politics that no beginner would understand), and the library in question doesn't advertise that it's using TypeScript properly. Even if the bug was fixed the user would still be stuck with TypeScript when what they need is JavaScript.
"Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them."
The guy wasn't a novice. He's introduced as " a great computer scientist, but not a JS person".
I think we're, as an industry, exceptionally blasé about usability problems in our tooling. These problems don't just waste the time of novices, they waste the time of people with 30 years experience, people who have been coding since childhood. The problems encountered in the article aren't the classic beginner problems like forgetting to add a semicolon at the end of a line. They're the result of accumulated lack of care for the overall developer experience. The root cause is a rampant culture of abusing tools for things they weren't ever actually designed for. JS modules are weird because JS was never intended to be a programming language for large scale projects, so it took decades for modules to emerge and then they were bolted on. Browsers refuse to do something as basic as load code from local disk because they were originally designed to render documents, TypeScript exists and requires extra work to execute because of the spec-driven approach browsers etc which in turn is due to their origin in rendering documents, etc etc.
The blog post is specific to JavaScript because these problems are specific to JavaScript and the way we (ab)use web tech.
> They were only trying to use the browser because they had problems with Node
(a) not problems with Node, problem. Singular. (the most common and well-documented problem with Node.) Which they made no attempt to resolve and just gave up on. Immediately.
> The fact that there are security issues loading stuff written by the owner of the computer itself from disk is more an artifact of how browsers work and how they evolved than anything else.
That was... precisely my point? So... nothing to do with JS.
> The usability issue wasn't really with VS Code. It's that the default behavior of browsers
Please re-read the gp as this isn't anything related to browsers. It's just a UI feature around display of folders. FWIW Github has the same (quirky, bad) feature in its directory navigation.
The "bug" here is that you can't use TypeScript directly in a browser (why not? again, mostly complicated browser related tech politics that no beginner would understand)
Oh my. It's not politics it's just age; TS is new. JS is OG. That's all there is to it here.
Putting aside any question of whether you might think browsers should adopt TS (agree), even if they did it would still have a different file extension.
The bug here is it's Typescript code with a JS file extension. TS is the file extension for Typescript. That's broken code no matter what way you frame it.
I don't like the annoyance of modern computing. Installing vagrant and Virtualbox and chocolatey on windows or apt get install on Lubuntu.
When you want to deploy you need to learn Kubernetes, ingress, Nginx ingress configuration, Kubectl. I've written ansible to bring up kubernetes and consul but it probably doesn't work anymore I suspect the kubeadmin has changed with the shim removal - I wrote a tool to automate everything chef, ansible, packer, aws, terraform (http://devops-pipeline.com it's a prototype and not ready for others to use but the idea of a repeatable environment stands)
It's so hard to get computers setup. When I get started with some source repository I dread reading the README.md due to it requiring a complicated build procedure.
And that's before you've even started reading the codebase.
Once you get something working you need to keep it updated and that's when things definitely go wrongm everyone refactors and changes interfaces so things stop working.
All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module.
Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js`
However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work.
Alternatively, if you wish to use the package.json info to launch node, use the package manager through `npm run start`
This isn't rocket science and honestly makes perfect sense.
Package management is basic stuff and Node really doesn't do it any different than Ruby gems or Pip requirements, etc..I think you and your buddy need to have a talk about the assumptions you're making with regard to the actual executable versus the package manager and re- evaluate your understanding from first principles.
Can't tell if you're being sarcastic or needlessly abrasive. Anyway, it doesn't really matter how supposedly intuitive something is if the actual experience of using it results in the pain expressed by the author's friend. It's called usability because it's about the user. FWIW I've been writing JS for 12+ years and I resonate a lot with the post. Taking random error strings and plugging them into google often takes you on a long winding path of hair-pulling until you eventually give up. It's painful. Anyone who thinks it's painless should reflect on where they sit on the dunning-kruger distribution.
The JS eco-system is in a very elongated (and necessary) growth phase, and right now it's still incredibly hard to "just make things work" if you're starting out. With each year that passes it gets more complicated. Having a fundamental understanding of it all becomes less possible; one must pick a framework and compiler and just stick to that otherwise you're lost in the woods. And heaven forbid you take a long sabbatical, because when you return everything will have changed.
I have been across the block, from x86 asm to front-end and back-end JS stacks 20 miles high with preprocessors and dependencies. I haven't ever always done JS. I've dabbled in everything, so that hiatus you talk of, I've taken it many times over. I know the hell well that you speak of when learning some new vertically stacked artifact like the JS ecosystem.
But I have no sympathy here because of the fundamental lack of cursory research or attempts done to grok what the node command does, versus the npm command. Jumping right in is a fine method but it doesn't call for complaints or a blog post. One should have an implicit understanding that jumping in without preparing, means a lot of stupid mistakes are going to be had.
Get used to going from first principles would be my advice. Elon Musk did a lot by following that maxim. The same technique cuts through all the ecosystem bullshit when you stop letting the confounding and confusion depress and unravel oneself.
"Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. You go into the first room and it's dark, completely dark. You stumble around, bumping into the furniture. Gradually, you learn where each piece of furniture is. And finally, after six months or so, you find the light switch and turn it on. Suddenly, it's all illuminated and you can see exactly where you were. Then you enter the next dark room..."
Andrew John Wiles
Dealing with these ecosystems is very similar to that. But all the dark rooms are similar to each other in spirit of shadows and highlights - so the more dark rooms one acclimates to, the less the future ones cause complaining, stress, or vitriol.
It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run
> Try teaching JS to someone with little experience
which is why js is not a good language to start teaching someone without experience in another language (including the ecosystem).
To learn js, it is necessary to learn about the module system that evolved from the browser (and the hacks made in the past, prior to having a module system). Then you must learn that node.js and npm, and optionally, webpack and/or other packing tools.
It's very convoluted, and unnecessarily complex. However, this complexity isn't entirely one entity's fault. I think you'd find similar complexity in java, in the early years, around the dependency management ecosystem, before the advent of maven 2.
Of course, you can just skip all of that, and go with the old C/C++ model, which is just copy/paste the code into a file in your project. For someone looking to test out some code they randomly found, this is probably the most recommended route imho.
The article is making the whole thing sound arcane and unreasonable when the distinction between package managers and runtimes has been the case for decades.
Expecting package.json (a package manager file) to alter the behavior of node (the executable runtime) shows a lack of even first principle knowledge of computer languages, runtimes, or package managers.
I don't feel bad in the slightest, because math feels like shit too when you first get into it. But the reasons are mostly sound, so complaints are mostly just whining.
> shows a lack of even first principle knowledge of computer languages, runtimes, or package managers.
it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering.
The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.
> This isn't rocket science and honestly makes perfect sense.
it only makes sense if you understand all the differences between ES modules and node modules that exists purely for historical reasons. Node modules are not part of ES specification at first place.
The module stuff is a different story and that's its own rabbit hole. I don't think its the crux of the blog post or even my comment. The purported issue was that changing the package.json type to module didn't fix things. That expectation is beyond amateur and I don't think there's really anything to complain about if one expects to bootstrap into a new programming language with package management, without understanding the general paradigm.
I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error.
repeat the same with xcode and any project in c, c++, objc, swift
okay how about ruby? oh I have old ruby , hmmm , try to install new ruby, seems to run, but it can't find certain gems or something. oh and this other ruby thing I was using is now broken ? why do I have to install this stuff globally? You don't but there are several magic spells you must execute and runes you must set in the rigtt places. Oh ... I think I got that setup but it getting this new error.
....
I'm sypathetic it sucks but it's not unique to js