JavaScript logo

The esteemed Dr. Axel Rauschmayer has written a blog post about a new proposal for JavaScript: Types as Comments. It definitely has got me thinking.

On the one hand, I’m a huge fan of JavaScript evolution over the last decade or so. Arrow functions, const/var, classes, modules – that’s all good stuff that has improved the language.

Typescript logo

Seemingly on the same side of this argument: I’m also a huge fan of Typescript. It changed how I do large-scale frontend development four or so years ago – static typing in a language helps me write clear code, catches a huge number of bugs at compile-time, and the tooling and overall ecosystem around it is top-notch. Kudos to Microsoft on this one.

But I’m not convinced the value of this proposal nets out positive. The proposal itself says that the primary motivation is to inch JavaScript evolution towards eventually supporting static types:

Does JavaScript need static type-checking?

“Given how much effort organizations and teams have put into building type-checkers and adopting them, the answer is yes.”

Why?

Tools

You have to accept that JavaScript is the language of the runtime. We shouldn’t be caring about types at runtime – that’s the job of the toolchain prior to deploying. That’s the way every other language works (feel free to tell me how wrong I am in the comments – I am no language expert!).

Static typing only helps developers, not users.

Think about it this way: what level of performance degradation are you willing to accept for full support of static types? Is it ok for the JavaScript parser and runtime to be 5% slower for every web page or 15% larger in code size? Of course I’m pulling these numbers out of my ass.

When I was first fanboying out on TS, I used to think “gee, wouldn’t it be really cool for browsers to support Typescript natively”. Wouldn’t that be an awesome way to learn and view source, etc. But you know what’s good for that instead? Super-fast and small JavaScript for best performance and if you want to share your developer brilliance, have an optional compile-mode and source maps that point to your awesome Typescript.

Patrick the Star

Another thing I don’t like about the proposal is that, while they are clearly heavily influenced by Typescript, they hedge:

How does this proposal relate to TypeScript?

“This proposal is a balancing act: trying to be as TypeScript compatible as possible while still allowing other type systems”

You are JavaScript – if you are adamant about eventually supporting static types, why not boldly point towards a “north star” of a language that has already proven itself? Is it that you don’t want to admit Typescript won? Is it lingering anti-Microsoft bias?

My opinion: If we are going to add static typing for web apps, we should just use Typescript as a new script type. <script type=”application/x-typescript”> seems a better option to me so that the browser can choose an appropriate parser, etc.

§1296 · March 10, 2022 · JavaScript, Software, Technology, Uncategorized, Web · 1 comment ·


Logo for the ReactiveX / RxJS project

I may have more to say about RxJS some other day, but it’s something I’ve been learning since switching jobs at Google late last year to work on a pretty large Angular app. I found it to be a steep learning curve with RxJS and Observables and functional reactive programming in general, but in this case learning RxJS is exacerbated by a lack of good, comprehensive documentation.

However, I did learn that the RxJS team has put together a pretty comprehensive set of docs for RxJS 6. For whatever the reason, they are located at https://rxjs-dev.firebaseapp.com/.

§1175 · October 26, 2018 · JavaScript, Software, Technology, Web · Comments Off on RxJS ·


Logo for the OPML file format

I’ve been hacking more on kthoom and I want to upgrade it so that it can load reading lists (think playlists-for-comic-books). Anybody have any thoughts on a decent file format? OPML? A custom JSON file format?

This is a pure client-side web app, so a couple caveats here:

  • I would like to be able to load Reading Lists from anywhere
  • It should be able to refer to files using any sorts of shareable links (HTTP, IPFS)
§1164 · February 7, 2018 · Comic Books, JavaScript, Questions, Software, Technology, Web, XML · Comments Off on Reading List File Format? ·


Logo for IPFS

Happy New Year! Inspired by jfmherokiller, I updated the kthoom comic book reader to allow for fetching comics books over the InterPlanetary File System.

I still have lots to learn about IPFS. I have some code locally that lets you put books up on the IPFS, but I haven’t committed that yet as I’m still working out the concepts and debugging things…

§1127 · January 3, 2018 · Comic Books, JavaScript, Open Source, Software, Technology, Web · Comments Off on InterPlanetary Comics ·


[Update 2021-06: Chrome and Edge have supported ES6 Modules in Dedicated Workers since Nov 2019. The equivalent Webkit bug is https://bugs.webkit.org/show_bug.cgi?id=164860 which seems fixed since April 2021. Yay! The equivalent Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 which work seems to have now started. Yay! Follow along on Can I use!]

ReactJS logo

I’ve been playing around a bit with React, since that’s where all the hot and shiny is lately. I really like it, but I can see some of the hot and shiny warts – I’ll blog about that later after I’ve been fully brainwashed had more time to play with it.

For the purposes of this exercise, one thing I’m trying to do is go the no-build-step route, where it’s all pure HTML and JavaScript. This means no JSX, no npm, no Babel. It’s really not too bad at all (unfortunately almost all examples I’ve seen online use JSX – and understandably).

It’s also given me a good stretch at using ES6 modules natively, one hot and shiny wart I’ve noticed there too.

Read the rest of this entry …

§1099 · October 19, 2017 · JavaScript, Software, Technology, Web · 2 comments ·