Typical dramatic Hacker News user. JS is a great language and enjoyed by millions of developers.
It adds zero value to any discussion. It's nothing more than a desperate attempt to gain some internet points.
It's a popular language and it has flaws, but that doesn't automatically make it worthy of the amount of hate it receives here. This type of discussion has more in common with /r/iamverysmart than it does with valuable discourse that HN used to be known for.
"Learn less edition", or "2D remake"
So please stop with that strawman.
I'm just glad JS is as good as it is, considering it didn't have to be good. It could have been even worse and still would have succeeded due to its monopoly.
When an intriguing movie - or book - comes out, it's often intriguing because it's quite different. When you convert it to a common language - or Hollywood - it becomes less different. Reading "Working With Legacy Code" forced me to absorb some C#, but it also allowed me an opportunity to compare it with Java, which I learned at university.
What I understand from this is that people didn't really value Python as a pseudocode language. It was just fashionable at the time. Now it's Javascript's time. I wonder what's going to be next? Golang has a chance.
This book will force you to absorb some pure, functional JavaScript. There's so much more to programming than "what language is it written in".
literally no one believes this
I personally found js terrible before es6 and love it since then
But I’m happy for you that you like ES6. You all own the language now, so enjoy it. Us ES5 folks are going to have to rewind and fork so we can have a community again.
I used to be a snob about JS, due to the fact that in the 90s / early 2000s, it had major shortcomings and produced a lot of slow, crashy web pages. But when I learned modern JS, I realized that it is now a fully mature language equal to any other, and easily used in a huge variety of contexts [thanks in no small part to Node]
What about there being no choice when you want to do almost anything web related
WASM ain't mature yet.
Thanks, I'm reading it now.
Up until a year ago or so I hadn't really had to use it much, I'm finding it so bad I'm seriously looking at how I can get into an alternate career. Working with JS is a profoundly miserable experience.
I hate what this industry has become.
Now it's Javascript as that is the code base our client uses. The client runs a number of production factories and have an internal web app that is mostly Javascript on the front end for monitoring these production lines.
It's made me angrily punch my desk and consider just quitting on the spot on a number of occasions.
I don't know how anyone tolerates using this day to day and doesn't want to jump off the roof. It's absolutely idiotic.
https://medium.com/javascript-in-plain-english/typescript-wi...
https://blog.risingstack.com/building-a-node-js-app-with-typ...
Basically, you install the `typescript` package which gives you `tsc`. Then you configure Node to run your program with `tsc` through your package.json.
While callbacks aren't a great way of doing continuation-passing, at least we can credit JS with making continuation-passing mainstream.
In combination with the fact that JS actually does work pretty well on both frontend and backend, it is a language I use semi-regularly for prototyping, given its flexibility. Granted, if I decide to make a "real" version of the project, I'll probably do it with a more functional language, but I think JS doesn't suck too bad.
Not everyone has the same brain as you. People enjoy things you don't understand.
Though I acknowledge its immense utility, I feel like JS always tends to go for "good enough" solutions rather than "best in class" solutions. That is its own kind of quality, but there's good reason to dislike JS for people who focus on those particular qualities in a language.
But I’ve never been in a job where we had a shot at building a world class system. Maybe I just have bad luck, but at each place I have worked the problems in the codebase are obvious and the impediments are institutional not technical.
There are hundreds of problems I could list in our current codebase that are causing slowdowns, bugs, etc. None of them are because of the programming language. They are places where someone put a square peg in a round hole, where someone copied a bug over and over because they assumed the existing code was correct, where someone used a fancy feature of the programming language that made the program worse.
None of that goes away if we start using Rust.
So yes, I agree with you if you are within striking distance of making a perfect application use a nearly perfect language.
I’ve just never been in that job. I’ve always been in the “let’s fix some of this low hanging fruit, and make sensible use of the tools we have” job.
Transpilation as a norm means it’s kind of 50/50 whether the source code you encounter while debugging will even be readable.
Actually what I see most often, professionally, is that JavaScript developers stop believing they can inspect their application at all, and when something is wrong immediately just try to guess what’s happening. Then see if their imagined fix helps, if not try again. Basically guess and check. Which is a fine technique but it’s pretty bad if that’s your only way to debug problems.
I am able to code in ES5 sometimes on independent projects (without Webpack) and it’s a joy. The debugger works everywhere, in a consistent way. I have callbacks everywhere so asynchronous code is simple to trace and easy to understand. It’s great.
I am working slowly towards a fork of NPM/Node ecosystem that starts over before ES6. I think early JavaScript is actually a wonderful, fast, elegant language.
I would say that ES6 is so bad in terms of debuggability that you almost have to use TypeScript to make coding in ES6 bearable.
The other aspect of what you’re saying: that you have no static analysis tools so you HAVE to debug, is spot on. I think to build a great JS application you have to put an equal amount of effort into designing the test harness. Basically all the time you would have spent wrangling the type system you have to put into the tests.
And you can’t just half- ass the tests. They need to really accurately mirror your business needs, and really model the relationship between your app and your tests, in order to provide an equivalent static analysis value to what a type system would give you.
However one final point, which is that the fact that ES5 is so impoverished in terms of control flow and data modeling, I think actually helps solve all of these problems. If you limit yourselves to basically just functions and literals, you are forced to write really strong clean interfaces. I find myself being able to focus almost entirely on separation of concerns. Because I’m not dealing with fancy language features, and because I literally can’t afford to build giant complex modules and applications, it forces me to build small, simple modules that have very clear responsibilities.
That might seem like a limitation to many, but I actually find it helps me to avoid headaches before they happen.
1) Don't concatenate them in the first place
2) Use TypeScript
Pro-tip, if the world is going JS and you don't get it, it's probably you.
With JS (TypeScript) I can develop on every platform natively (React Native).
I can compile to native code. (AssemblyScript).
I'm not saying you can't do those things on other languages, but JS is becoming a powerhouse thanks to it's ecosystem.
Also, you see many other communities like Rust copying lessons learned from web developers (React/Redux/etc)
It pretty much just strips the typing out when "compiling".
All the JS problems have been solved in ES6+
There are many languages that have supersets.
If "native" means bundling a runtime and having your program pass serialized messages to a different thread where the actual native platform code lives, the same can be said for any language. You just need to build the wrappers for the native API – which is a lot of work but could be done for QBASIC running in DOSBox just as well as for JS running on V8.
x = 5;
(no var declaration). Extremely easy to do by accident. Lots of these will be left for backwards compatibility. In JS errors often go silent and I developed a strong dislike for any language that does that, including Vimscript and Lua (and I do like Vim).
We all know that is global.
Nowadays you use `const` or `let`.
Any JS developer will have a linter that will tell them incase they somehow made that mistake.
I'm not saying that it breaks the language, but it definitely is irritating, especially if you're not using a linter.
Also, I like knowing which variables won't be reassigned (const), and which will (let).
Mostly because JS is not the only language that I'll be working with at a time, and if I'm dancing between three or four and they have similar syntax, then mistakes creep in.
Personally, I favor languages that go "almost too far" in the opposite direction, e.g. Elixir. In Elixir, operator[] (a.k.a. the Access protocol) is generic across several types, but the semantics are very strictly constrained; not only does the access have to "mean" getting some kind of element from a container, but it's also only defined where it has a fixed O(1) time-complexity.
This sort of design being conventional in Elixir, means that you can usually predict, just from the lexical environment (a.k.a. "the code on the screen") what the runtime behavior will be of said code—which includes being able to "read off" a time/space complexity for the code—without needing to check how each ADT involved has implemented its generics, let alone having to check for implicit type coercions.