I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials.
It is good to see that the community is open to introspecting and improving even further
Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using.
I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I ended up not being able to get anything running. In the end, I had several hundred megabytes of libraries downloaded, a complicated configuration, and a non-working application.
Today, there are toolsets to get you started with everything and produce a running application, but it's almost totally opaque. I'm afraid to use them because the first time something breaks, I don't know if I would be able to resolve the issue.
I would still rather have a decent understanding of how things connect.
That was my biggest eyeopener when I started using React - the piece I know just the tippy top of the iceberg. While that's true with a lot of languages (it's not as though I know what's going on with the whole .NET stack) it seemed especially egregious. I had a site up and running quickly, but it pretty much entirely magic.
Do you teach JavaScript first just because of how fast it is to get it up and running (ie. "Just open your web browser")? If I remember correctly it was much more vexing than a lot of compiled / strongly typed languages as the errors in those languages came sooner. In JavaScript there have been times where it loads and runs, but nothing happens, and I had no idea why, which proved frustrating.
JavaScript is still what I use to introduce programming to new people, because for people who haven't done their dues learning how to use a command-line, the hardest part of getting started with programming is getting your computer set up to do it at all. And since everyone already has a browser, getting started with coding only requires showing them how to open the developer console.
Installing stacks like Rust, Erlang/Elixir, Go and maybe OCaml is so fast these days that you likely will not have halved your coffee by the time it's done.
I agree getting to the browser dev console is instant gratification but I don't view 5 minutes of installation as a punishment from Hell either.
Fair, but most stacks including the previous infamous ones are two or three lightweight installs away. The VSCode/Atom/Sublime generation of IDE replacements made that possible.
I come from an environment (.NET) where setup was a day or two of work but now is a matter of 10 or less minutes).
>also they frequently have good documentation and “getting started” tutorials.
I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app,
I seen it uses npx(not sure when this tool appeared) it also used tons of dependencies, in the end I created my app from scratch using only the TS compiler package and the react client library, no extra tools, magic, 1 month old tutorials that are outdated already, no install latest tool of the month etc.
That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.
What's unique to JS is how short the shelf life of documentation is compared to the past. 15 years ago if you found a tutorial and it didn't work, it meant it was either many years old or you could install one java (etc) version prior and it'd work again. It seems like a lot of JS docs go obsolete within months if not weeks.
Honestly, this is even a problem in "official" tutorials. I set out to learn some basic node a while back. The official docs then were out of date enough to not work to install node (nor were they off a trivial amount). I finally figured it out and PR'd a doc fix, but you shouldn't have to do that to try out a platform.
npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app.
Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.
It takes about 30 seconds since last week 'till the end of the next month. If you read older tutorials, you won't figure it out. By March, current tutorials will probably be out of date.
That's my issue (one of many) with the JS ecosystem. Things move so fast that just keeping up feels like a full-time job. I remember giving up on my first approach to React after I followed Swizec's tutorials and quickly hit into some issue with Babel (of all things) that was a week old and transitively screwed up a few months old React/D3 guide.
And, as 'simion314 said, there's way too much magic. create-react-app is a useful spell that (most of the time) makes you a working React app, but I'm not fond of a culture that encourages casting it instead of understanding what's going on and how to actually set up a React project.
This is why I refuse to use create-react-app. I can appreciate the convenience and have learned a few things from reading its source, but I need to understand the entire application I'm building from the ground up.
1 the right tutorial, instruction may not be on top on my search engine, a few months old instructions are too old
2 the create app thing uses tons of "magic", it encourage people not to understand how things work, all is fine until something breaks... here is an issue we hit at work
We have a project that uses gulp(the project is old, I did not started it so don't blame me if gulp is not the state of the art today). One dev added an uglify step to gulp and now the gulp watch t process entered in an infinite loop, I as the one with the most experience I worked on figuring it out, since the uglify step causes the issue I investigate this(I discover that some gulp modules the project uses are obsoleted because a cooler/better one was created but I did not started on upgrading the tools), I read on uglify, it's dependencies, I read on watch it's dependencies, read how it is implemented under the hood and in the end I realize that uhe uglify hstep had the side effect of making the process longer (I suspected that some temp files would be created or other things) but this extra seconds triggered an existing issue in our configuration file, the watch task was watching the output min files but it never triggered before because of a timeout it has(or something similar). In the end I ended up looking under the hood of this magic tools because a dev setup a .json config file wrong but the issue did not manifest until years later.
Conclusion is that magic tools work fine until they do not , then you have to look under the hood or try the reboot,update,change the tool and maybe it is fixed
For tomorrow I need to investigate why npm install package fails to install a package dependencies on a CentOS server, I read that there were some bugs and probably the fixes were not backported and I will have to mess around and understand what is the problem and fix it somehow.
It is good to see that the community is open to introspecting and improving even further