Today’s JavaScript, from an outsider’s perspective (2020)
lea.verou.me
lea.verou.me
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
It just worked.
And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off.
I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly.
That was as close as I could be to successfully complete 10 Years Reproducibility Challenge [1].
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.
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.:
https://www.nuget.org/packages/Microsoft.Extensions.Configur...
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...
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.
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.
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.
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.
There’s no downside beyond “it requires development time and maintenance” like any other feature.
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.
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.
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.
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.
Young languages are easy to get started in. Ruby used to be.
Though ruby has a separate problem of breaking changes. The back-compatibility crowd can run old code (e.g. java), but at the cost of their soul.
Rust is a new language, and it has the same complaints above.
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.
Don’t look at how things are sold, look at how they are. In this case it’s code, of course there’s complexity.
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.
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.
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.
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.
https://medium.com/@imior/10-things-i-regret-about-node-js-r...
> 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.
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.
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.
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.
npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm
npx should download and run the binary for you and npx is almost always installed with node automatically.
When I have to use build-tools I usually go for esbuild.
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.
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.
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.
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.
https://www.php.net/manual/en/function.str-pad.php
https://docs.ruby-lang.org/en/3.1/String.html
https://developer.apple.com/documentation/foundation/nsstrin...
> 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.
My code is a combo of lodash bits, datefns, helper regexes I’ve curated over the years, etc
Is there a standard library-like package that you import on most projects?
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.
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.
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 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.
console.log("Hello, World")
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".
Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.
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's why X is hard.
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.
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.
I don’t think that’s unreasonable.
What’s unreasonable is this culture in web dev that you shouldn’t have to read the docs!
Also Parcel is easier by a factor of 10, skip Webpack entirely.
So it isn't hard - it's just not easy and it's time consuming. Wait, what?
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.
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. ;)
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.
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.
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.
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.
That's why I like to use vanilla JS as much as possible. It will be maintainable years later.
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.
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.
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.
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.
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?
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.
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.
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.
It's good of Ecma International to keep standing up to that. It's better for the web.
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.
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?
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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 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.
Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.
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.
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".
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..
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.
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.
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.
- script without a main function
- 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.
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.
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.
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.
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.
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.
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.
"How you hire is who you hire."
And I have a new one...
"You're not only the interviewer, you're an interviewee as well."
Understanding these two basic are essential to a decent hiring process. Ignore these and you're just another fool in a sea of fools.
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.
Moi? I'd leave it. Them not looking tells as much as if they do.
Those that see it otherwise? That to me a culture red flag. It's an easy swipe left.
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.
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.
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.
Yes, I agree. That's exactly what I said in several parts of my message. However I believe you missed the point and didn't notice the sarcastic tone.
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.
... 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.
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
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.
Example: https://github.com/jwagemann/era5_in_gee#workflow-overview
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.
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.
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
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.
Defold is worth mentioning as well
IMO this is unfair characterization.
If using Photoshop is driving, programming is building an internal combustion engine vehicle. You cannot expect to just randomly google for car-making tutorials and get an SUV done in a weekend. Heck, you can't even expect to be able to build a very simple combustion engine from basic principles without a lot of study.
I'm not saying this is Aella's fault or anything, it's fair to have wrong expectations, but calling this "needlessly complicated" is not fair either.
If I had to take something away from that Twitter thread is how marvelous is that someone without any programming experience has been able to programatically manipulate CSV data in a couple of days.
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.
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"
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.
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.
But it's really hard to find what to start with from a google search.
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.
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.
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.
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.
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.
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.
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.
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'll see how it goes.
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.
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
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!
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.
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 saw would be fine: https://www.amazon.com/CRAFTSMAN-Hand-20-Inch-Finish-CMHT208...
If you can afford it, something like this will last you a very long time (probably a lifetime): https://www.amazon.com/DEWALT-12-Inch-15-Amp-Compound-DWS715...
If you really want something that will definitely last you a lifetime (or two): https://www.amazon.com/SKILSAW-SPT88-01-Drive-Bevel-Sliding/...
If you want something that is pretty good at most things, get this: https://www.amazon.com/SKILSAW-SPT77WML-01-15-Amp-Lightweigh...
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.
Another thing which you will use all the time (and I mean ALL the time, regardless of if you are doing woodworking or not) is a good set of handheld drills: https://www.amazon.com/Milwaukee-2697-22CT-18-Volt-Lithium-I...
If you want a long series of videos to watch, check this out: https://www.youtube.com/watch?v=mn4L_aJ1rV4&list=PLRZePj70B4...
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.
import csv
?
Data = open(“file.csv”, “r”)
For line in data.readlines(): Print(line.split”,”)
Blah1, blah2, "blah3, blah4", blah5
Maybe using a library is a better route.
Eventually yeah you’re going to run into something with characters you don’t like, but that’s just a teaching/learning moment!
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...
It has not became harder.
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).
I was replying to your: > Yes, it's incredibly complex. It doesn't have to be
It's not complex.
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.
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.
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.
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.
https://knowingless.com/get-my-eggs/
> Get My Eggs
> 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!
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.
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).
The Computer Lib Pledge (<https://archive.org/details/springer_10.1007-978-3-319-16925...>):
The purpose of computers is human freedom.
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.
So help me.
-- Ted Nelson
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.
> 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.
As a teacher, this resonates
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.
Just kidding, embedded has puke surfing too.
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.
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.
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.
How it feels to learn JavaScript in 2016
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Original old-man-railing-at-modern-tech parody:
https://www.brycewray.com/posts/2021/01/easy-peasy/
. . . and, as I note in the opening:
> I do **not** pretend this is in the originals’ amazing league.
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.
But then I realised I am interesting in things other people do as a job: cooking, CAD, gardening, wood work, music.
So people must be interested in programming as a past time.
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).
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.
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 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.
- Stockholm Syndrome: Programming is supposed to be needlessly hard for beginners.
- Denial: What OP describes isn't a problem because I already learned how to avoid it.
- Propagation: Try this even NEWER JavaScript library / paradigm / framework to solve all your problems (and totally not create a bunch of new ones).
- JavaScript Bad: See this is why nobody should ever do front-end programming.
- Acceptance: It shouldn't be like this.
- Over simplified summaries of complex viewpoints
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.
Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.
I'm still tempted some days.
It's beyond painful. It's infuriating.
https://jakearchibald.com/2021/export-default-thing-vs-thing...
In my opinion they should have dropped the whole "live reference imports" which is a completely new concept to the language.
Personally I would have liked inline modules definitions à la Rust.
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.
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.
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
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 :-)
See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
ESM _is_ the future, but not the present, and I wish people would stop foisting it on packages before its ready.
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?
If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.
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.
Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!
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...
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.
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.
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.
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 agree, and the runtime and browser is also a very nice framework for gui programming.
The last time I tried to do something within the Python universe it was pretty painful as well. So I can relate to the Twitter thread.
I have a love/hate relationship with Go but this is the area where it shines.
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’m not even sure what I think about it all.
See also: <https://news.ycombinator.com/item?id=22991033>
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.
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 think the reasons for it in JS's case are kind of reasonable though. Just annoying that it's taking so long to sort out.
I 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?
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.
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.
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.
Duplication isn’t required for these things to happen. All it does is fragment the ecosystem.
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.
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.
If you install any library that's either only ESM or CommonJS, you can't run your program. It simply doesn't work.
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.
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?
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
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.
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.
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.
You don't need any of those to invoke client-side UI changes.
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.
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.
The only exceptions I can think of are Io and Go (I heard that Rust also works, but I haven't tried that one).
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 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
That's not a justification for whatever they ran into, but I suspect is the reason for many of the issues.
If I thought I could just write some C... I probably couldn't and nobody would think twice about that.
https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Thing...
And a couple of books ago I read "Don't Make Me Think" by Steve Krug.
https://en.m.wikipedia.org/wiki/Don%27t_Make_Me_Think
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."
the "community" however is as shit as ever, but you can easily ignore it.
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.
every time i run npm install i am prepared to embark on a bunch of side missions.
But yes, the plumbing the cli controls and sets up for you is insanely complex and overengineered.
This would have been a problem on any ecosystem, even more, trying to do something for the first time in life is difficult whatever it it is.
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.)
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.
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.
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.
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.
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.
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.
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].
1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
> 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)
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.
Previously: <https://news.ycombinator.com/item?id=31331358>
> 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!
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.
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.
(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.
> He's introduced as "a great computer scientist"
Well colour me thoroughly unconvinced.
This is why I built https://pkg.land/ (beta), append NPM package name to the url and a list of alternatives will be suggested. See https://pkg.land/colors
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 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>...
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.
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.
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.
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.
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.
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.
Previous experience or just a basic understanding of what the commands read, touch, and do, would have avoided most of their confusion.
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.
from the article:
John runs node index.js
Node:
Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
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.
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 does when you use ESM, it checks whether there's "type": "module" in package.json.