Simon Willison’s Weblog

“javascript” in quotations

Filters: Type: quotation ×

[...] 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 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

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

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

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

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

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

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

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

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

Me # 13th May 2008, 1:49 pm

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

When visiting any Web page, the site owner is easily able to ascertain what websites you’ve visited (CSS color hacks) or places you’re logged-in (JavaScript errors / IMG loading behavior). They can also automatically exploit your online bank, social network, and webmail accounts (XSS). Additionally, the browser could be instructed to hack devices on the intranet, including DSL routers and printers. And, if that’s not enough, they could turn you into a felon by forcing requests to illegal content or hack other sites (CSRF).

Jeremiah Grossman # 3rd November 2008, 12:43 pm

I think the Web community has spoken, and it’s clear that what it wants is HTML5, JavaScript and JSON. XML isn’t going away but I see it being less and less a Web technology; it won’t be something that you send over the wire on the public Web, but just one of many technologies that are used on the server to manage and generate what you do send over the wire.

James Clark # 2nd December 2010, 6:48 pm

Let’s try to imagine what a Google Silverlight would have been. It would have been a fully open source product from Google, with a very liberal open source license (BSD or Apache). It would have all the technical specifications published openly. They would pledge to have the Silverlight VM interoperate with Javascript and HTML5. And a company like Zoho would have a ton of developers working on Google Silverlight based applications by now—as opposed to having exactly ZERO developers working on Microsoft Silverlight.

Sridhar Vembu # 7th June 2009, 11:32 am

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

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

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

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

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

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

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

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

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