I love where JS is heading, but perhaps its worth pointing out its a lot easier to rapidly advance a language that historically has been missing huge features.
On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. There are quite a lot of people programming in JS, many of whom may or may not deserve to be called good programmers but who nonetheless can produce functioning web pages, that would have to switch to a very different coding model to work with JS using these new features.
On the other hand, it's difficult to program your code when you know than any of your invariants can be accidentally stomped on by any other code that happens to run on the same page. It's also difficult to write libraries when everything's guts are exposed, even with red tape. Raymond Chen over at MSFT has an entire blog that could be titled "How Implementation Details Become De Facto Interfaces Due to Insufficient Encapsulation."
I think my final thought on the matter, is that when you think about it, it's really quite silly that we only have one language for front-end web development. It is, in fact, unacceptably silly. Like, seriously guys, what the hell? This is totally crazy. If you want to do server work, or non-web client applications, or embedded, or whatever else, you have a full array of programming languages. These run the gamut from ball-gag-and-leather-straitjacket static languages to walk-into-anyone's-house-and-drink-their-milk dynamic languages, from concise expressive languages to low-level bit-fiddly-ones, from parens to curly braces to significant whitespace to perl.
On the web we have JavaScript. Not that it's a bad language, it has its warts (what doesn't?) but it's actually a cute little language. But I don't have the option of using a language with static guarantees. Or deterministic memory management. Or asynchrony. Or macros. None of these are strictly better, they're all just personal preferences, but the point is, you don't have the choice.
That lack of choice is probably what's driving these against-the-grain additions to JS.next. They're adding more features to JavaScript so that it can cover some of the bases that it currently doesn't, and all the different directions it's being pulled in are understandably causing some stress. I think it's the wrong solution, but it's also the one with the easiest transition path. The ideal solution, is that we could use different languages from different paradigms, but how the hell do you crowbar them into existing browsers?
So uh... do I have conclusion? I dunno, language evolution is hard, let's go shopping.
I really like the evolution of JS over the past two decades. I strongly believe the evolution of JS revolutionized the web in a positive way and significantly boosted innovation by lowering the costs for application development. For example, every corporate app these days is a web app, which is much easier to manager from an IT perspective than OS applications. Shipping working code at scale has never been easier. In my relatively short career I've seen consumers and organizations adopt innovative new applications at an accelerating rate because of this.
Is it perfect? Definitely not. JS is so easy that it also makes it easy to write bad code. Higher-level languages also consume a lot more resources. Browsers become the defacto OS (good / bad?), etc. But in general I think JS has been revolutionary and the benefits far outweigh the costs from a functional perspective.
As for the article: jQuery receives to little praise imo. At the time it was truly revolutionary. Suddenly you could make your websites interactive with just a few lines of code, and it worked in every browser! This inspired an entire generation of web developers.
This. The tooling and development environment for JavaScript has improved by leaps and bounds. As an early adopted I found JS to be a pain in the ass. These days I dare say it's one of my favourite languages.
I really like this JS-free future we have ahead of us. I mean, I needed to format a date as text recently, and JS can't even do that without downloading some library... The sooner we'll be able to use real languages on the front-end, the better.
JS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed.
Not any more. Not even close. The amount of stuff you have to deal with immediately is far larger now.
I actually miss the days when people added this kind of stuff to their transpiler of choice (e.g. coffeescript) and just used that - it doesn't need to be in the language, because it can never be removed from the language. Let fads appear and die outside that barrier, not inside.
I would like to think that the next big change will be the slow but steady replacement of JS/TS by one or more much better languages. Even with the current relative calm in front end web development, JS is still a terrible language for almost everything that matters. TS is a noble effort to put lipstick on a pig that achieves some useful benefits, but only at the expense of adding even more complexity, a sometimes clumsy syntax because of the JS legacy, and an illusion of being safer than it actually is again because the decision to favour JS compatibility means you can break the type system.
Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
I would love to see a nicer language replace JavaScript as much as the next guy, but it seems rather unlikely especially given the changes that ECMA has approved in the past.
I am really hoping that some day, we will be able to do front-end devwork that isn't just an abstraction of JS/HTML/CSS.
But to be even fairer, JS has evolved into quite a nice language to work with over the last few years and I'd hope that developers who've used it in the past would take the time to re-evaluate it.
Yes, I've been developing websites since before JS existed, so it does in fact make me happy that JS has made some progress related to developer productivity in 20 years. Are they adding other baggage? It seems so, but the addition of a standard library is a things well past its time.
I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake.
People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.
With the javascript community fixing most of it shortcomings, I suspect in a few years JS/TS is going to be way far ahead of any programming language in term of users.
I've worked in JS for around 12 years now and welcome this change of keeping JS as a scripting language but incrementally retiring it for performance-intensive general-purpose applications.
To my eye, JavaScript has three applications:
* A GUI-building language: A language and ecosystem we use to build UIs, where code runs on the end user's machine, served over the Web or as desktop applications using a compatible API (e.g. Electron).
* A scripting language: An approachable high-level C-like language.
* A general purpose programming language: A server-side or developer machine-side programming language for computational tasks like linking dependencies, transpiling code, type checking, orchestrating tasks.
At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord.
At the second, performance doesn't matter anyway, so making JS capable of this just makes it approachable for folks who learned the language for the GUI-building purpose.
It's at the third application that the fundamental limitations of JavaScript---the programming language---really show. These are things like the lack of true multithreading (technically possible with significant limitations around shared memory and messaging and high overhead with Web Workers), lack of low-level primitives to fine-tune performance, and the ease with which authors can accidentally write extremely slow code. So much of this (TypeScript compilation, NPM package resolution/linking, Webpack bundling) in the modern Web ecosystem is regrettably still done in mostly JS.
I hope the JS community rallies around one general-purpose language to offload these tasks to as well as a uniform shim layer like Ruby's C extensions so we don't end up with a chaotic mishmash of different technologies. If nothing else, it would be nice to have a good excuse to write not-JS every once in a while!
I basically agree with you here. However, JavaScript is a better language than most people think. Ignorance and trying to treat it like something it isn't is responsible for much of the hate. Obviously it being the only choice in the browser is part of it. However it's a better language than many of the ones that people (or at least groups) use by choice.
The frameworks and build systems are largely necessary because the web platform is rather weak, and of course to add language features.
A type system would help a lot, as will modules once they are universally used. Typescript, Flow, etc will probably settle on something useful. Evolution is generally better than revolution in language design. It's a bit slower for JS because of the nature of the web.
reply