But the Javascript part is the one that always causes me hours-days worth of work into Rabbit holes. And by JS, I don't necessarily refer to the language alone. It's the entire ecosystem.
Oh, `npm install`? You just found out you got like 1000+ vulnerabilities. Alright, good thing it told me actually, let me update.
BOOM! Babel doesn't support this specification in this file anymore because it's nonsensical so you have to do something else now. Ok, BOOM! Babel deprecated that now, you have to try this workaround. Oh, wait. Actually, there is no workaround. You gotta downgrade your node version.
Ok, let me downgrade. Oops, that package isn't supported anymore on this node version. Oh, you need to replace this because it's no longer maintained.
I literally never had to go though this pain with any of my Elixir backend projects.
Fuck Javascript
You notice you have thousands of outdated dependencies and that's a bad thing?
I used to work a lot with python years ago, and the only reasons we didn't have this problems was because the packages management was so terrible that you didn't even notice you had to update dependencies or that they had vulnerabilities.
With a small number of deps where you skim the development DL, you know if there is a security issue or a cool new feature you want. Also it has more of the Unix C philosophy of don’t break stable APIs in new releases. So upgrading mostly just worked. (Stuff like deliberately breaking old SSL protocols aside). (Until python 3 of course.)
They also don't have thousands of projects depending on ridiculous packages like left pad because they actually have a standard library.
The surface of vulnerabilities and the brittleness of the entire ecosystem is the bad thing, not the warnings.
> You notice you have thousands of outdated dependencies and that's a bad thing?
This is a weird reply considering that the OP literally said those were a good thing:
> Oh, `npm install`? You just found out you got like 1000+ vulnerabilities. Alright, good thing it told me actually, let me update.
The bad things are in the lines that follow.
On the other hand his php project from 2011 still works, just as my perl stuff from 2006 still just works.
> Alright, good thing it told me actually, let me update.
Babel is the only way to use modern standard JS without excluding older browsers.
Because you mentioned Babel I suspect you actually didn't use JavaScript - but a language that compiled to JavaScript. And this complicate things a lot and is probably the root cause of your wasted hours. The time you save upfront by using some framework you pay back later in maintenance once new versions are released and things get deprecated. In JavaScript itself nothing will ever get deprecated.
I was writing PHP 15 years ago. It wasn’t a great dev experience and the tooling was awful. JavaScript today has stellar tooling in comparison, and arguably less warts in its standard library than PHP still has today.
I really disliked JavaScript until I read some books that helped me understand what it’s doing under the hood. These days I just don’t have issues with it. Yeah, the ecosystem thrashes a lot and the tooling experience can be bad in regards to that, but otherwise it’s impressive lately. Even without TypeScript, intellisense on regular JS enables extremely streamlined navigation of references and implementations, refactoring, project navigation, tooling integration, etc. Not to mention modern profiling and debugging tools for JS are incredibly easy to use and benefit from.
PHP wasn’t at this stage even 10 years ago. The debugging story was still xdebug and tooling was improving but not great. Composer was painfully slow and buggy - nowhere near as nice as yarn and npm are now.
Yeah JS has problems, but I don’t believe it’s nearly as bad as old PHP.
There are a lot of reasons to like JavaScript as a language and NodeJS as a particular implementation. The standard library (or lack thereof) is absolutely not one of them as things stand today. I'm not even sure what you'd compare between them.
If you meant to say "package available at the other end of npm install" instead of "standard library" I could see that being a different story.
Today, PHP offers a solid OOP experience, good gradual typing, a larger and saner standard library and code loading based on namespaced components.
Now compare today's JS to PHP back in the day. It has the exact same kinds of problems. Except with modern JS, you'll end up adding TypeScript, webpack, Babel and a dozen other tools as well as several hundred megabytes of libraries to paper over all of those problems. But by doing that, you make the build process and the code that ultimately runs in a browser completely incomprehensible and undebuggable for the average developer. And then you start adding even more tooling (source maps that barely work) to try and solve that problem...
I find it really unfair to compare es6 to php 15 years ago, es6 is really cute (the babel/transpiling part is peculiar, I admit it)
Doesn't mean I'm saying JS is inherently beautiful. But if you ignore the bad features and do a little setup, it has the potential to be wonderful.
Maybe TypeScript is great, but I just don't like the idea of depending on transpilers to not suck when creating the final code, and also having to debug that transpiled code, and then the whole transpilation step in between the standard command-S-command-tab-command-R workflow (this is also why I never use SASS/LESS if I don't have to).
Once JS itself has strict typing and real classes, and enough time has passed that I can be assured 95% of people using five-year-old browsers will be able to use it, then we can talk about the wonders of JavaScript. Until then I don't get why anyone would use it (or anything that transpiles to it) when there are so many better alternatives for server-side development.
Let's not even get started with Electron.
At the end of the day all I care about is if I build the products and solve the problems I'm hired to do. Beyond maintainability, the "engineering" stuff is a distraction we need to be careful not to obsess over.
Comparing assembly/C to JS/TS doesn't make sense.
...but different.
> Writing C is not like writing assembly...
...it's different.
Or you could just write the JS directly and be done with it.
How does this differ from trusting a compiler or interpreter?
Every language has to be translated to machine code in some way.
When was the last time you found a bug and it was the compiler or interpreter's fault?
At any rate, the big difference is debugging, as I mentioned above. How fun is it to debug code which you only kind of indirectly wrote?
I've not come across any bugs caused by typescript itself in the time I've been using it since 2014, and my point was that this is the same for c or any other language - how fun is it to debug assembly you only kind of wrote
Also there have been attempts before but nothing really stuck. How many non-Googlers use Dart?
Yew [1] is one of the early Rust frameworks for client side work. It allows for multi-threaded (!) execution and javascript interop.
Not many other languages make sense as you have to pack in the whole runtime, GC, etc. Rust is pretty well positioned for WASM, and it's going to take off soon.
Sure, they can, both via compile-to-JS solutions like Transcrypt [0], and via generate-the-frontend-with-backend-Python solutions like idom [1], Plotly Dash [2], and others.
[0] https://www.transcrypt.org/
Clearly, there are people that disagree with this value judgement, and the existence of that disagreement is an existence proof that Python for frontend is, in fact, a choice people can make, even if it is one you find unattractive.
I think theres legitimate reasons to compile Python to JS, but "JS is bad" can't be one of them, since you still have JS that you have to worry about. It makes sense for codesharing with server code or preexisting business logic.
Over the years I've debugged js compiled from various languages, and it's seriously a terrible experience: however bad you think debugging handwritten js is, reading and debugging generated js is strictly worse (and you will have to)
Or...maybe I won’t; I’ve used plenty of compile-to-JS languages (including what starts as “js” with JSX and modern features but gets compiled to plain, and more widely supported, JS), and I spend as much time reading and debugging JS in its compiled form as I do reading and and debugging .NET or Python bytecode instead of source, which is none.
It is, just as using compile-to-(or interpreted-by-a-runtime-in-)-native-code languages is a solution to “I don’t like raw x86_64 machine code for desktop applications”, even if you end up running machine code in the end.
> Also Dash is absolutely terrible, horrible documentation, horrible code.
“X is not a choice people can make” is a different claim than “One example of X is not something I personally would recommend”.
As to your second point, that's why I put it in parentheses, of course it doesn't refute your claim but if you use as example a technology that has awful documentation because of this two-language paradigm, and leads to garbage code both at the Python stage and the Javascript stage, to me it doesn't paint a good picture of the whole concept.
Even native languages like C/C++/Rust compile their language into binary format that the platform can run. It just so happens that the web runtime format is JS instead of binary machine instructions.
That’s what sourcemaps are for; you don’t have to debug compiled instead of source format on the web just like you don't on other platforms.
Sure you could. You can develop for the web in practically any language you like these days. People use JavaScript because it has native support for the DOM that nothing else can match. Until we get away from the DOM for application development, it will always be king.
Sure it does. DOM support is built into the very core of JS as a language, and that has shaped the entire history of its' development and subsequent API choices. It's not just a library that it happens to support, the way it would be with any other language.
That said, unfortunately, the language is much better expressing personal projects than picking up the trash in an untrained corporate environment like an over paid janitor.
let obj = {a:1},
arr = [1],
map = new Map().set("a",1);
// Iterating over an object keys
for (let x of Object.keys(obj)) {...}
// an array
for (let x of arr) {...}
// or a map?
for (let x of map) {...}