Thursday, April 28, 2011

A new Cambrian explosion

Three areas that seem to be exploding are new programming languages, new databases, and new content-centric networking protocols.

But I think all of these developments will be dwarfed by the emergence of the browser as the unified display substrate and JavaScript as the new instruction set.

The last time we had a similar event was the introduction of the GUI in the 80's/90's: millions of programmers scrambled to write every imaginable application for this new system

But the GUI explosion will be peanuts compared to the browser+JS explosion! Not only are there far more programmers today, they're also all joined by the internet now. And there's ubiquitous view source. Need I say more??

Millions of programmers are scrambling right now to write every imaginable application for the browser+JS.

If you ain't emittin' HTML and JS, you're gonna miss out on this once-in-a-geological-era event!

2 comments:

  1. > the browser as the unified display substrate and JavaScript as the new instruction set.

    This would be a nightmare world for programmers and users alike. In fact, the extent to which this idea has actually come to pass is already nightmarish.

    Imagine a CPU architecture which behaves as capriciously as the web browser:

    "How many problems did you have with hardware compared to OS compared to end-user apps? According to most evidence I got, JavaScript does whatever the hell it wants at each browser. Hardware is not like that. CPUs from the same breed will run the user-level instructions identically or get off the market. Memory-mapped devices following a hardware protocol for talking to the bus will actually follow it, damn it, or get off the market. Low-level things are likely to work correctly since there’s tremendous pressure for them to do so. Because otherwise, all the higher-level stuff will collapse, and everybody will go 'AAAAAAAAAA!!'"
    (Yossi Kreinin)

    There is literally no way to write web apps such that most users are guaranteed to experience exactly what you intended.
    No way, naturally, short of dumping heroic manpower into testing for every catalogued form of browser brokenness. The set of players who can write some kind of web app is ever growing, but the set of players who can write web apps which function as reliably (both functionally and aesthetically speaking) as desktop software is largely limited to megacorporations with armies of QA pyramid slaves.

    ReplyDelete
  2. As one of the true lovers of Javascript, my post may seem biased. However, about 6 months ago I decided to move my project to MongoDB & NodeJS. Since this system communicates with a Firefox extension I am, for the FIRST TIME, able to code in the same language across all layers of my application. I can write code in the most basic of IDEs and get quicker, more useful debugging info than ever before. Javascript's asynchronous nature behaves exactly like computers do physically, whether we like it or not. Processing takes X time, and as developers of applications that are meant to run on any machine, we get very little if no say as to the value of X.

    Of course we should be and are responsible to keep performance a priority. This said Javascript doesn't enforce these things, and that can be a problem. However, as time progresses and we continue to contend with these immortal bit pushers, so too grows the simple truth that users need to take more responsibility for their hardware and environment. Abstracting away from the problem just makes sense.

    ReplyDelete

Real names (or handles), please. Anonymous comments are likely to be ignored.