Programming languages are tools, what matters is if they do their job. And the current popularity of javascript means it works for most people.
But boy, how ugly and inconsistent it is. I wish I could like it.
I maintain systems written in Ruby, Elixir and PHP over the years. Every server side code written by me even as old as 5 years ago, works with very little modification required for today.
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.
So npm gives you warnings about vulnerabilities and that's a bad thing?
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.
Diff being you usually have like five python deeps for every hundred npm deps a d you can do the old school thing and subscribe to the security alerts for those deps. The difference in number of deps means you have the cognitive
space to understand them. Npm needed to automate because the numbers are too high. One of
python’s old selling points was “Batteries included”. And the idea is fewer large library rather than a bunch of tiny libraries.
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.)
Not OP but what I think they struggled with is fixing warnings.
JS projects are like a poorly built house, things are constantly deteriorating and need constant maintenance.
I've got a new nodejs project that a colleague wrote about 6 months ago. It's already completely broken and needed a lot of effort to get working again.
On the other hand his php project from 2011 still works, just as my perl stuff from 2006 still just works.
This doesn't sound foreign to me.
Node projects rely on a lot of dependencies (and so does their dependencies) so there is a lot of moving parts and it's prone to break.
I completely disagree. The TypeScript compiler allows you to specify a compile target against a version of JavaScript. That means you can write modern TypeScript and have it compile to ES3.
JavaScript is backwards compatible. What you wrote in JavaScript 10 years ago will still work today in all JavaScript engines.
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.
1: Trying to fix every vulnerability in any nested dependency is probably not what you want to do. In my experience only a tiny fraction has an attack surface and most are duplicates.
2: Webpack is a monster and updating webpack will always result in a lot of work. If possible use a well supported framework that incorporates Webpack, like Next.js or Nuxt.js. Updating will be a breeze.
3: Don't wait years before scanning for issues, update on a set schedule so it won't become a huge task once a critical issue is found.
Do elixir libraries just never deprecate stuff? Or just that their package managers never alert you about vulnerabilities so you can pretend like they don't exist and so never upgrade?
I write PHP for a living and every time I look at the JS world, I feel like they're exactly where PHP was 15 years ago, except with 20 times the amount of incomprehensible tooling.
I’ve worked with PHP and JS extensively and while I could almost agree from some narrow perspectives, I think JS is nowhere near where PHP was 15 years ago in any sense.
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.
> JavaScript today has stellar tooling in comparison, and arguably less warts in its standard library than PHP still has today.
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.
This may be a little off topic but your comment piqued my interest: I am currently learning JavaScript and I was wondering if you would like to recommend any of the books you read.
It’s been a while, but I really enjoyed the “You don’t know JS” series by Kyle Simpson. It explained a lot of the details I needed to understand in order to be proficient more consistently. Whether I was working on client or server side code, I felt like I understood my tools well enough to feel a lot more confident than I did before.
15 years ago, PHP didn't really support any programming paradigm very well, it was a huge untyped mess, the standard library was missing a lot of stuff, reusing code meant including individual files based on filesystem paths.
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 had the impression that beside gradual typing, ES6 solved most of the mess (cleaner apis, modules) which was happening at the same time PHP (and python) accelerated their growth.
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)
I started just despising JS. But with discipline and a well-configured linter, formatter, and ideally using Typescript, I've found it to become my favourite language.
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.
So many people are bringing up TypeScript here as an example of how JavaScript isn't so bad. I kinda feel like that's cheating. Like saying eggs are absolutely delicious when baked into a cake - you're praising something after it has been turned into an entirely different product.
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.
People occasionally rely on compilers. I don't really see this as much different.
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.
Well yes. But as the problem solver, there is nothing better than when someone has a problem, and you have a solution ready at hand which came from lambda calculus or distributed systems tricks or some crazy shit from On Lisp. That is why they are paying you, not to cranks out good dutiful straightforward solutions but for clever ideas that are simple to implement and operate. The engineering is both awareness and skill in following processes to get great cheap and effective solutions. Otherwise you end up with 20 million lines of
code and all the aesthetically sensitive people have have to leave the company.
Given that people are usually already using Babel, TypeScript isn't really any different than running a linter is. There's no additional transpilation step if you write your code in TS, but you can also run TypeScript to have it warn you of potential errors.
Because it's no longer the same language. You're not programming in JavaScript, you're programming in TypeScript, which happens to be compiled to something JavaScript engines accept. All the praise towards TypeScript does not necessarily apply to JavaScript. It would be like praising Assembly while you're actually programming in C.
AFAIK, the only difference between TS and JS is types. TS doesn't give you anything that's functionally different than JS -- only types that are stripped during compilation. You can't perform any logic on types at all (e.g. you can't have conditional logic based on interfaces).
With most things, yes, if the implementation for that feature supports your operating system, and it doesn't take long enough to be noticeable, and there's no weird caching issues at any given level, then yes, it's transparent in that case.
Or you could just write the JS directly and be done with it.
The code output by typescript is generally pretty readable depending on the target, and the source mapping works very well regardless. The debuggers in all major browsers and ides handle it fine.
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
This brand-new book on using Python (via Transcrypt) in the browser to build a React app may be helpful in that regard: https://pyreact.com. Just started reading it. Seems very good so far.
You can write Rust for the frontend right now. It's pretty neat.
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.
I use both JS and Python for work and not a day goes by where I don't wish history had taken a different course and Python had ended up embedded in web browsers.
There was a strange time in the dark days of IE6 dominance 20 years ago that you actually could write page scripts in non-javascript languages. VBScript was a big option that some people used, and IIRC there was a way to get python support in IE (and Windows) script host too. When I was first learning Javascript in ~1998 I remember all the docs showed how to do stuff in both JS and VB script tags: https://stackoverflow.com/questions/17483782/vbscript-suppor...
> If people didn’t like JavaScript for front end work, it’s not like they could just switch to python
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.
> It turns out that even if you accept "Python is great and JavaScript sucks" that "Python compiled to JavaScript" ends up even worse than JavaScript.
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 also have gotten DMs on Reddit from companies looking for devs since I commented on a thread 10 years ago about an obscure toy language: it doesn't mean thats a reasonable choice for technology.
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)
> however crazy you think handwritten js is, generated js is just obviously worse to try to read (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.
> That's not a solution if you end up with Javascript in the end. (
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”.
The issue is that writing code that goes through a JS-transpiler is more complicated than just writing Javascript, unless the language you choose is Javascript-adjacent, whereas writing code that compiles to machine code is infinitely less complicated than just writing machine code.
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.
Why is that not a solution? The concept of compiling/transpiling a language into the target language for the runtime is everywhere.
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.
Can’t easily write Django code in JavaScript either. In general it’s not like working programmers get to choose any programming language whatsoever for the hardware and platform they’re writing software for.
You don't have to use Django (you can choose one of the billion alternative CMSes), but everyone has to use a browser. Hell, Django itself has to write javascript.
>If people didn’t like JavaScript for front end work, it’s not like they could just switch to python
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.
>That has nothing to do with Javascript's merits as a language though.
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.
Yes, the language is sloppy. Like all things sloppy it’s more about knowing what not to do only after which the elegance is exposed.
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) {...}
I would expect, given you have described an operation on 3 different data structures using different words, that it would also demand 3 different kinds of syntax/denotation no? Your own language requires as much. Why not JS?
Well in python by example you use for x in myobject to iterate and that's it, no Object.entries(myobj) vs. mymap.entries , lua is even more consistent, ..
