Simon Willison’s Weblog

Someone asked me today if there was a case for using React in a new app that doesn’t need to support IE.

I could not come up with a single reason to prefer it over Preact or (better yet) any of the modern reactive Web Components systems (FAST, Lit, Stencil, etc.).

One of the constraints is that the team wanted to use an existing library of Web Components, but React made it hard. This is probably going to cause them to favour Preact for the bits of the team that want React-flavoured modern webdev.

It’s astonishing how antiquated React is.

— Alex Russell # 15th August 2023, 9:15 pm

SvelteKit is written in JS and distributed as source code — no build step — and it’s been miraculous for productivity. build steps make sense for apps, they make much less sense for libraries

— Rich Harris # 24th March 2023, 11:07 pm

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.

— Jason Miller # 28th June 2022, 3:01 pm

We write a lot of JavaScript at Basecamp, but we don’t use it to create “JavaScript applications” in the contemporary sense. All our applications have server-side rendered HTML at their core, then add sprinkles of JavaScript to make them sparkle. [...] It allows us to party with productivity like days of yore. A throwback to when a single programmer could make rapacious progress without getting stuck in layers of indirection or distributed systems. A time before everyone thought the holy grail was to confine their server-side application to producing JSON for a JavaScript-based client application.

— David Heinemeier Hansson # 8th February 2020, 8:10 am

If you want the fastest website despite implementation difficulty, the answer is: SSR behind a CDN with assets in best compression formats (webp, Brotli, woff2) served over http2 (or 3) from same origin with JS as enhancement only

— Mike Sherov # 15th February 2019, 7:12 pm

The nature of NPM is such that I’d expect most large corporate Node software to depend on at least a couple of single individuals’ hobby projects. The problem is that those projects don’t tend to fulfill the same expectations of security, quality and maintenance.

— Sébastien Cevey # 2nd December 2018, 9:32 pm

Before events took this bad turn, the contract represented by a link was simple: “Here’s a string, send it off to a server and the server will figure out what it identifies and send you back a representation.” Now it’s along the lines of: “Here’s a string, save the hashbang, send the rest to the server, and rely on being able to run the code the server sends you to use the hashbang to generate the representation.” Do I need to explain why this is less robust and flexible? This is what we call “tight coupling” and I thought that anyone with a Computer Science degree ought to have been taught to avoid it.

— Tim Bray # 10th February 2011, 6 am

JS had to “look like Java” only less so, be Java’s dumb kid brother or boy-hostage sidekick. Plus, I had to be done in ten days or something worse than JS would have happened.

— Brendan Eich # 16th October 2010, 8:25 am

The Web for me is still URLs and HTML. I don’t want a Web which can only be understood by running a JavaScript interpreter against it.

— Me, on Twitter # 27th September 2010, 4:37 pm

If HTML is just another bytecode container and rendering runtime, we’ll have lost part of what made the web special, and I’m afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf.

— Alex Russell # 17th March 2010, 10:37 pm

Glitch is built in an entirely new and different way for a game. The back end (java at the lowest level, with game logic scripted in Javascript) is designed for maximum flexibility and ease of deployment. That means we’ll be able to push new content — new items, new places, new characters — on a daily basis. It also means that we’ll have lots of APIs with which the game can be expanded and extended.

— Glitch # 10th February 2010, 11:40 am

It’s interesting to me how much [Closure] feels like a more advanced version of Dojo in many ways. There’s a familiar package system, the widgets are significantly more mature, and Julie and Ojan’s Editor component rocks. The APIs will feel familiar (if verbose) to Dojo users, the class hierarchies seem natural, and Closure even uses Acme, the Dojo CSS selector engine.

— Alex Russell # 6th November 2009, 7:35 am

JavaScript cannot save you. Even if it could, you should not let it, for the price of this short-term salvation is the end of what you like about the web.

— Alex Russell # 19th August 2009, 11:33 am

I think you overstate the usefulness of the [jQuery Rules] plugin. Using this plugin, users are now limited by what selectors that can use (they can only use what the browsers provide—and are at the mercy of the cross-browser bugs that are there) which is a huge problem. Not to mention that it encourages the un-separation of markup/css/js.

— John Resig # 22nd February 2009, 11:11 pm

Someone asked for onbeforeunload, so I started fixing it. Then I found that there was some rot in the drywall. So I took down the drywall. Then I found a rat infestation. So I killed all the rats. Then I found that the reason for the rot was a slow leak in the plumbing. So I tried fixing the plumbing, but it turned out the whole building used lead pipes. So I had to redo all the plumbing. But then I found that the town’s water system wasn’t quite compatible with modern plumbing techniques, and I had to dig up the entire town. And that’s basically it.

— Ian Hickson # 19th December 2008, 1:58 pm

I’m really typecasting myself here. If there were an international “Person most likely to write a Spectrum emulator in Javascript” award, I’d have taken it for the last five years running.

— Matt Westcott # 29th October 2008, 5:24 pm

Making queries faster isn’t in the critical path for improving the real-world performance of any Dojo apps I know of, and I bet the same is true for JQuery users. Reducing the size of the libraries, on the other hand, is still important. Now that we’re all fast enough, it’s time that we stopped beating on this particular drum lest we lose the plot and the JavaScript community continue to subject itself to endless rounds of benchmarketing.

— Alex Russell # 22nd August 2008, 8:12 am

Hey Google: any chance we can all build the social web together without requiring JavaScript?

— Me # 13th May 2008, 1:49 pm

Let me be again clear here that Comet isn’t a new single technique. Rather, it’s a combination of existing push technologies with further research into new methods that together provides a robust framework for pushing data to all clients on modern networks.

— Michael Carter # 3rd February 2008, 10:04 pm

In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups. But in the short term, I recommend that you be using Firefox with No Script. Until we get things right, it seems to be the best we can do.

— Douglas Crockford # 7th November 2007, 3:36 pm

I have another technique [...] that I’ll be switching jQuery to. If you attempt to insert into the document.body before the document is fully loaded, an exception is thrown. I take advantage of that to determine when the document is fully loaded.

— John Resig # 26th September 2007, 12:21 pm

Apparently if you try to remove/destroy/trash a FORM dom node in IE6, it won’t delete it, instead creating a bizarre orphaned node stuck sucking up memory until the browser window is refreshed.

— Jon Sykes # 20th September 2007, 1:04 pm

The recent announcement that Mozilla’s next JavaScript engine, Tamarin, will also be a container for functionality written in Python and Ruby (and, one assumes, beyond) is proof that JavaScript is the new Parrot.

— Aaron Straup Cope # 29th July 2007, 9:17 pm

MooTools is not compatible with any other javascript framework. If you “definitely need to work with prototype” (which you don’t, since the frameworks each provide all the functionality you need to use only one or the other) then learn how to do what you want to do in prototype. Otherwise, learn to use MooTools to do all the things you want to do. They simply do not work together, and I promise they never will.

— Tom Occhino # 8th July 2007, 7:29 am

[...] Silverlight has full access to the browser DOM and you can make calls from Javascript into silverlight code and from Silverlight into Javascript. This means that you can already write the presentation layer of a client side web app in Javascript and implement your business logic in IronPython.

— Michael Foord # 16th June 2007, 12:25 am

Microsoft saw the danger of Javascript and tried to keep it broken for as long as they could. But eventually the open source world won, by producing Javascript libraries that grew over the brokenness of Explorer the way a tree grows over barbed wire.

— Paul Graham # 7th April 2007, 8:22 am

The JavaScript alert(), confirm() and prompt() functions in Firefox, Opera and MSIE (but not Safari) will truncate the message after any null character. So an unsuspecting programmer who inserts user-provided text into one of these dialog boxes opens up an opportunity for the user to rewrite the bottom of the dialog box.

— Neil Fraser # 13th January 2007, 12:28 pm