Just Say No to JavaScript
infoworld.com
infoworld.com
> Ultimately, JavaScript was the right thing at the right time. It ended up being folded, spindled, and mutilated to serve purposes that it isn’t well suited for
Counterpoint: many quirks in the language were addressed, e.g. introduction of === and with ESLint you get many of the practical advantages of a type checker. And when you need more safety, sprinkle TypeScript on top.
What I really want for Christmas is a TypeScript-to-native compiler.
The lack of explicit typing. The author argues against untyped code, and for using typescript instead of javascript to get types.
The JIT seems to figure it out just fine. Otherwise typeless programming is just a particular style and it's not particularly complicated just different. I've never understood this rationale in a language that does not have pointers.
You are right that dynamic typing is a valid style though and offers some great advantages but also disadvantages. That is why most dynamic languages have added gradual typing support to have the best of both worlds. The real issue is the weak typing in JS which is an design mistake in retrospect.
But now I'm going to. For context, I write code in both explicitly typed and not explicitly typed languages (mostly JS).
> The JIT seems to figure it out just fine.
And the CPU will figure out binary code just fine. But you won't. You can, but not easily. You are writing for the computer, but also in a way that you (and your peers, if applicable) will be able to work with the code: extend it, fix it, maintain it, make it evolve. "The runtime figures it out" is hardly an argument for the dev UX.
Explicit typing is one way among other things to document the code, and this is documentation that's automatically checked by the tooling, which is nice. Types are documentation that can't rot. I'd say, good to take.
"The JIT doesn't need this to figure out the types" also applies to documentation by the way. The runtime, however, doesn't need to understand the code, just to run it. But you need to understand the code when working on it.
Types can help you figure out what functions you can call on any particular variable, without having to have something similar to a complete stack trace in your mind to know which type is a variable.
Sometimes, you can't even have the complete stack trace, for example when you are working on a library called by user code, or when you are calling some black box library code from user code. It's nice having types that are automatically checked at the interfaces so you don't have to figure it out (which you may need to do by running the related code, noticing the return types and hoping for the best). Even if you are dealing only with code that you have access to, it's nice not to have to go read all the code of the other side each type.
Explicit types just make it easier and faster to understand code, and also to modify it. Without types, you need to "recompute" the type of anything you are dealing with, risking calling the wrong method if you do a mistake at this step. Of course, if you have solid testing in place, you will probably catch it, but with explicit typing, that's a mistake you can't do: it'll be in red in your editor, or an error at the type checking step, winning some time.
Explicit types lets you avoid having to re-figure out again and again types of things, and that's cognitive burden that's freed to give more room to focus on what the code actually does. They also help your IDE help you if you use one (or something like LSP).
if you are dealing with small pieces of code, it doesn't matter much: everything can be kept in your head anyway. For such code, explicit typing can be just noise. But for bigger code, types are a relief.
For me, a nice balance is explicit typing at the interfaces (function parameters and return types), and implicit typing inside the function body.
All in all, I think explicit types make me faster for anything more than a trivial amount of lines of code. So I have a strong case for explicit typing. But I don't have much for non explicit typing.
The only reason I can choose to write vanilla JS despite this is because Typescript more or less requires opening the NPM can of worms. Would browsers allow type annotation in JS, I would totally use them and have some type checking pass somewhere to enforce correctness.
Considering how much of the article was about typing and not specific to JS itself, "Just Say No to Dynamic Typing" would've probably been a better title for readers. It would likely get less clicks, though. :')
The author does but you have to extract it yourself by using some mental subtraction from the sentences he did write:
>[...], TypeScript has all of the benefits of JavaScript (such as they are) while _adding_ a type system that is expressive and powerful. [...] TypeScript leverages the ubiquity of JavaScript while _adding_ all the power of a modern typing system. And that is why you should be using TypeScript instead.
Translation... subtract out the "added modern type system" from Typescript... to reveal his Javascript criticism: "Javascript does not have a modern type system to help catch errors."
Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type.
It's probably not listed in the article because it's a nonsensical argument.
Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix.
What I need is a StupidScript to save me from the stupidity of my logic errors…
Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards unlock at the end of the match. The code is “correct” the right types go to the right place but there is a logic error somewhere that prevents certain rewards from unlocking.
Uh, yeah, that's a runtime error. Type safety tells you the error before you even hit save, let alone run and test. It's a wildly faster loop.
Yes. The point is that without type-safety and a compile-time type check, you have absolutely no way of knowing if you have an error like this until you hit that piece of code.
The very fact that you think you don't have those kinds of issues just exemplifies how you actually are just ignorant to all the type errors you have in your code because you haven't tested enough, hit the right edge case, etc.
Once you have written down the shape of the data flowing through your program in a way that a compiler can check you'll be able to reason about the whole program better and you might find issues much faster.
I think that types can directly help a lot with logic errors as well: one of the things people say most often when discussing typed programming language is that you can make illegal states unrepresentable, which means that you can encode logic into the type system itself.
Over the years I feel like I have read this comment at least ten times from different commenters (and the second time this month) and I cannot really fathom it. I consider myself a pretty good developer, and I have type errors many times a day. It is perhaps the most common error I encounter, and thankfully one of of easiest to fix with static typing.
By far the biggest recent productivity gain I have made using types is by generating the types along with client code for APIs via a swagger doc. I cannot overstate the value in seeing the types update when the backend devs have changed the API, and getting a compiler error when it doesn’t match with your code. By having the types the next developer after me is going to be spending far less time getting up to speed with the codebase.
I started programming with static types early in my career so perhaps I have become wired to lean heavily on the type system.
I have made a lot of code that works on a lot of third party APIs (The major LLMS, Image generators, E-commerce stuff) and yea it's all been easy breezy and never thought I wish I had types.
Different people just work in different ways.
https://news.ycombinator.com/item?id=35892250
Personally I like using typescript's namespaces that have no nice-enough jsdoc/js equivalent, but if tsc/tsserver had an option to mutate in-place typescript syntax to jsdoc notations where possible I would use it as much as possible.
I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.
I do agree with you on the compilation, and this is the reason I'm still writing the occasional .js or .mjs file. However, the js I write starts with enabling ts-check and has all of its type information encoded as comment. This way, I'm getting the benefits of typescript while writing the code without needing the whole compilation step.
That's such a weird requirement, maybe because I'm used to writing Go code in my day job. I work on some React webapps on the side and there's no way I would miss on TS, typing is just the only way to write code that you can actually refactor. Granted you get some of TypeScript safety for free thanks to `// @ts-check` and friends, but it's the bare minimum.
But for Web UIs I'll drop down to a #NoBuild "Simple, Modern JavaScript" [1] i.e. using JS Modules + JSDoc Type Annotations to avoid needing any npm modules/build steps/etc. I still benefit from a library's TypeScript definitions/VS Code intelli-sense/static analysis/etc but completely avoid any build/bundling complexity for the cost of a slightly more verbose syntax in JSDoc type hints.
I'd happily move to using ECMA Type Annotations proposal [2] if it ever got accepted, but alas TC39 moves slowly...
I think this depends on how you use the type system in your code. If you're just passing around strings and numbers, then sure. But if you're making explicit types for all the entities your program processes, and if you're structuring them in a way that means you don't have a bunch of undefined fields in the normal case (e.g. by using tagged unions a lot), then Typescript is absolutely, objectively, transformative compared to Javascript.
But Javascript is the language of choice for programs (scripts) that I do not care to run. By default, these undesired Javascripts are executed automatically with no user input when one uses a so-called "modern" web browser.
As such, I do not run Javascript. As it happens, the language is closely associated with the so-called "modern" browser, a program that I consider too big, too complex and too dificult to control. It takes far too long to compile, assuming the source code is even available.
I am submitting this comment without using a "modern" web browser.
There are a lot of sites out there dependent on javascript of course - but you can evaluate these as you find them and either move on, give them temporary permission, or permanent permissions.
I'm not convinced it actually makes the web any safer to browse given modern browser security controls, but it certainly feels safer to browse, and generally it's a much nicer experince with less crap happening on the page as you go (pop overs etc)
Default settings matter. In popular browsers, Javascript is "on by default". From the evidence produced in Google's antitrust litigation, we know that companies or organisations that control these browsers choose default settings strategically to increase surveillance, data collection and ultimately online ad services revenue.
I rarely find websites that are truly dependant on Javascript, meaning the web developer had no choice other than to use it. Instead, what I find is (a) gratuitous use of Javascript to do something, e.g., make an HTTP request, etc., that can also be achieved without it and/or (b) use of Javascript to make HTTP requests I never intended to make, e.g., requests for ads or tracking. Javascript is effectively used to transfer control over web browsing from the web user to the web developer. Through the use of Javascript, a single request for a page becomes a trigger for dozens of additional requests the web user never intended to send, and usually to domains the web user has never heard of, that serve no useful purpose to the web user.
1. Extensions/add-ons like uBlock will show numbers of requests to be triggered with Javascript. Insanely high numbers are common. For example, something like fifty-seven for Github. Meanwhile I am able to use Github to search, read and download source code just fine with a relatively small TCP client (not git) that does not run Javascript, only sends a single HTTP request and generally uses only two github domains, i.e., github.com and githubusercontent.com.
In sum, I am not sure that many websites are truly dependant on Javascript to offer what they purport to offer to web users, e.g., information, files, etc. What I am more inclined to believe is that websites are dependant on Javascript to perform surveillance and data collection, not to mention serving ads and tracking.
Types are definitely useful in the fight to 'make invalid states impossible', but this rather overstates the case. They go only a very little way in documenting intent.
I don't have a problem using typescript, but prefer dart if you need a strongly typed (null safe) language.
Sources - or just an opinion stated as fact?
If going untyped JS, then you don't have the same restrictions as Java.
If going typed, then the TypeScript type-system is more powerful than Java's.
The issue with JS is weak typing. Also programmers mostly using batch style programming makes it more frustrating though the browser dev tools are decent.
Dynamic typing is not an issue. Gradual typing can be added later on to an language. JS just needs to add syntax support for type hints so you don't need to rely on JSDOC. The weak typing is a serious design flaw and can't be fixed in a backward compatible way. Maybe with an explicit opt in where you declare types strong is the beginning of your file but that would make JS engines more complicated as they would need to support both and I don't see it realistically happening but one can dream.
If lack of explicit typing is the issue, then his rant would apply to most scripting languages and to single out JS seems odd to me...
Can you clarify how you do this? the type annotation TC39 is not approved; but I'm interested in hearing if you have a "userland" approach that works for you?
The most compliant one seems to be using [JSDoc](https://jsdoc.app/). JSDoc is mostly intended for generating documentation. However, the Typescript compiler can validate types (and can even interoperate with Typescript definitions), if you configure it as such.
In scenarios where you HAVE to write raw Javascript but still would like to do some type validation, this is probably the best solution.
It looks a bit like this:
/**
* Fiddle the widget
* @param {WidgetThing} The widget to fiddle
*/
function fiddleWidget(widget) {
JSDoc also works in the middle of a method:
/** @type {Foo} */
const foo = widget.fetchFoo();
JSDoc also has arbitrary type definitions:
/**
* @typedef Foo
* @type {object}
* @property {WidgetThing} parent - the parent that created this Foo.
* @property {string} name - the name of this Foo.
*/
JS is in a different spot where to benefit from type checking you have to add a build step or reconfigure your build tool, switch files to another extension, add some "type stubs" dependencies, and make significant changes to the codebase to benefit from type checking.
I think if Node and the browsers started allowing type hints in their parsers you'd see much less resistance to TypeScript.
Other scripting languages are probably not popular enough to matter as much as JS does.
It's similar for JS, believe it or not. Type hints via jsdoc can be just as easily configured for type-checking in our IDE of choice.
Python type hints aren't mandatory either, so they're strictly opt-in and nothing stops users from ignoring them.
Still, the title is disappointing because switching to a type checked dialect of JS won't fix the bloat issues that are fundamental to the browser as a platform.
There may be a case that typed languages ship with fewer initial defects in new features but I'm not entirely convinced it's always competitive with the return in development speed and simplified testing you can get staying untyped. Particularly when your underlying problem is not CPU bound.
Solo project or very small team then? When everyone understands all code?
Of course it's faster to go type less then.
Add 4 more people and you'll end up debugging runtime errors because it was intuitive what you should send to $COLLEAGUE's functions but in reality they expect something else.
Or at best, $COLLEAGUE will document the type info in comments :)
It is not at all "say no to JS". It's "use my preferred flavour of JS instead."
I want to return to the pre-JS internet and especially the pre-JS Web.
Say no to Javascript at all in any variant. Also say no to PHP. Nothing of lasting value to humanity would be lost if both of them went away completely, forever.
What about dynamic websites? For example, a platform-independent chat app. Javascript has a place, although that place would be better filled by another language. PHP... yes, PHP can be completely replaced by other server side frameworks.
An exact example of the kind of thing I'd like to get rid of.
The UK PC vendor Elonex had the first ever webmail system I saw, called HTMail. It was impressive but it was a private in-house tool to give remote workers email access without needing their own machine with an email client. Wrong sales model.
It the was followed by the indie HoTMaiL, based on NetBSD servers I think, which had the right model: a free public standalone service, paid for with ads. Of course MS bought it and ruined it.
Webmail doesn't need Javascript and worked with pre-JS browsers and servers.
> For example, a platform-independent chat app.
Good. Let's eliminate them, too. They are bloated slow things that allow companies to hijack their own commercial clients' data.
Stick to standard protocols, extend them if necessary -- XMPP 2, Matrix, whatever -- and document and publish the protocols. Make it possible for 3rd party client apps to connect. Pidgin was great and it takes about 1% of the RAM of a bare handful of these crappy Electron efforts like Slack.
What you are citing as reasons to keep it are the reasons I want to see it dead.
There is room for programs that do not need to be installed. Examples are Flash, Java applets, and Javascript. Personally, I think some sort of UI thing based on WASM might be the way to go, but that's just my opinion. Can you think of any other way to run programs from the internet without installing them? Yes, SSH, telnet, remote access, remote X11, but with all of them, the programs are running on a different computer, whereas with web apps, they're running on your own computer, without costing them money, other than hosting costs.
I never thought I'd be speaking for web apps, but I guess I'm not, not really. What I'm saying, is there is a niche, and that is currently filled by web apps.
Oh dear hypothetical deity, please no!
I can best respond by copying my own response from another place:
Do you know Greenspun’s tenth rule?
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
It was about Lisp, so it’s an ancient thing now, but it still has truth.
As far as the Unix/Linux/xBSD world goes, it can be generalised like this:
Level 1: Any sufficiently complicated [container or VM management system] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9.
Level 2: Any sufficiently complicated [bytecode VM or runtime environment] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Inferno.
Wasm to me still smells very much like a second-hand, poorly-conceived, half-assed version of Dis.
> There is room for programs that do not need to be installed.
Sure there is room. But is this a desirable thing? Is it worth the price in inefficiency and insecurity?
If it is, and I am not 100% convinced of that, then design it right into the OS from the outset. Any effort to bolt it on later will be fatally flawed.
I like opinion columns and would love to see more about software development, but this one feels like it's going for the lowest of hanging fruit. Anyone who cares about JavaScript either way will already have an opinion and won't be won over by a humorous take.
I do like the author's style though, so don't interpret this as crapping on his work. Looking at the "More from this author", it seems this is his genuine style, and I found some of his other pieces to be good reads. More please.
Look, you can hot glue and tape all the types you want, but it is still JavaScript. No amount of compiler-enforced comments is changing that.
Yes, it's still one of the most performant languages around, so that's a good thing right?
This time it comes from a "former Delphi product manager" turned clickbait writer. I just hope that my visit with adblock enabled didn't generate any form of income for him or his website.
It has warts. I have seen a staggering amount of flavors / styles of JS.
It is a really expressive language. But that is kind of a cope. You will figure out how to express your wildest ideas. But you will struggle to read others code.
Multithreading is...weird to say the least. Are people spinning up a server per core? Using PM2? Have they discovered the world of testing...without mocks.
If we don't criticize JS it will never get better. So writing off the criticism of the especially hateful BE dev stereotype isn't doing anyone any good. Take it in stride. Nobodies feelings need to be hurt.
Many languages evolve into other languages. JS does not really have that luxury, and I don't know of any langs that preceded it that were similar (my own ignorance).
It is amazing for what it is.
But...if we could start over with what we have learned over the years many things would certainly be very different.
The issue I take is that the criticism is vague and outdated. "It was built in a week" is the only direct piece of criticism, which is simply no longer valid. The JS that was built in a week is long dead.
In fact, the whole article is about how TS = good and JS = bad. Except that Javascript is valid Typescript. So every wart or issue that exists in JS also exists in TS, with the exception of a layer of type safety.