A Web Application Platform

The Layers

Ok, so it’s another ambitious future looking post. I’ve been thinking a lot about the architecture of a browser platform that fits what I’ve got in mind. Looking at the HTML5 mailing list largely confirms my thought process. I noticed a few weeks ago a thread in the list regarding text in the canvas element.

> I still think by introducing the drawString() method into Canvas we are
> opening the same can of worms that was open in SVG.
>
> If we go that way we will need a drawParagraph() method to draw multi
> line strings or blocks of text with wrapping and a bounding width. We
> also need to be able to stylize the text, i.e. changing the font-weight
> / color / font-style … of any word.
>
> The list goes on and on … and HTML and CSS already cover it all.
>
> The HTMLElement.drawElement() method should be no problem to implement
> since userAgents already do render HTMLElements.
>
> Having it return an ImageData object will make it insanely simple to
> manipulate in Canvas. The text elements/contents can easily be in the
> fall back content of the Canvas tag thus keeping it accessible. Getting
> the bounding box of an HTMLElement is no problem either in JavaScript.
> And applying gradients and patterns can be done using a fillRect() with
> the appropriate globalCompositeOperation.
>
> Everything (almost) is there. Let’s not re-invent a square wheel.

Let me just summarize what I think is important here. Text on the canvas highlights something very key, the browser is in many ways a specialized graphics engine. Under the hood it is capable of a lot of things, but through html we are given just a small subset. SVG and Canvas are also subsets of the capabilities built for other purposes. Really, one can think of each one of these, in addition to CSS as Domain-Specific languages (well, Canvas is really more an API) that specialize in accessing certain portions of the browsers abilities, and there is a lot of cross-over. SVG is markup based vector graphics and Canvas is command based, but they can both draw arbitrary shapes and create complex graphics. And if you look at what Webkit has been up too, you can see that they’re pushing CSS to the next level as well.  They’ve got support for CSS gradients, canvas drawing, reflections, and masks.

Cutting Through The Layers

I am reminded of the blind men and the elephant. Each man feels a different part and thinks it is a different animal, because they do not see the whole. Each of these languages gives us a piece of the elephant, but wouldn’t it be nice to leverage the whole damn thing? I am a huge proponent of domain-specific languages, but they can’t work in a bubble. Imagine defining rails without ruby. Maybe rails can cut it for the 80%, but you need the general purpose language when you have advanced logic rails doesn’t account for.

But Keeping Them

Let me stop for a second and once more reiterate that the concerns of a web application may not be the concerns of a web page. Advancing the abilities of html and css alone would go a long way for those concerned only about documents. The document aspect of html and css are extremely important and should not be marginalized. Html and css should live on as specifications independent of the browser. That is the beauty of the open web. It is more accessible than just through an application on your pc at home. Content on the internet is accessible through any number of devices, and the specifications that we’ve built for the internet can live on without it. JavaScript as a programming language, html and css as a document format, and the whole ball of wax used for various widget platforms.

Bringing It All Together

So what do we do with this disparate collection of specifications that overlap and work with each other in various ways? For developers targeting the mainstream, it would be most advantageous to have a single, solid development platform. This is the draw of Flash and other plugins. So, for the sake of argument, let’s say we start with that. This hypothetical development platform would be designed to be completely on par with (or I dare say better than) the offerings of other plugins/RIA platforms. The open web provided the seeds of innovation that have spurned the next wave of software. It should not be relegated to the back seat when RIAs become the norm.

I come from a Java world (I know, I know). While it is not perfect, it has a history of multiple implementations on multiple platforms by multiple vendors with a high degree of compatibility. The write once, run anywhere promise used to be something of a joke, but now it holds true more than any other platforms I can think of.

I don’t want the open web to become Java. Far from it. I simply think it is a technology that took a similar problem and came up with a fairly successful solution.

So What Am I Suggesting?

What we as open web application developers need is a true Web Application Platform.  The same way that Java, Mac, Windows etc. provide a complete platform for robust applications, we need something capable of similar capabilities, but solving a slightly different problem. The Web Application Platform needs to be safe, loadable from the web without installation, and fluidly communicate with the web while taking advantage of the power of the local machine. I want to be able to dig deep and have access to painting apis, layout managers, and low level loading apis. HTML and CSS are high level abstractions that can be layered over this, and rarely should the lower level stuff be needed, but to truly be powerful, it needs to be there. Adobe Air is getting close to this type of power, but clearly it is proprietary, and is heavily dependent on flash. I just want something more.

Advertisements
Posted in ideas. Tags: , , . 1 Comment »

Why HTML5 is not enough

I wanted to begin this post first by applauding the WHATWG/HTML5 crew for their work. They have been taking up the flag, fighting for the open web in their own way since 2004. You can read all about what is going on at the WHATWG site.

Let’s start with a pity party

I’m not being sarcastic. It sucks. I even feel bad for the internet explorer team. There are billions of web pages out there, and going forward, browser makers are in a position where it is difficult to move forward without breaking backwards compatibility.  A highly controversial posting by Joel Spolsky does a good job of at least describing the problem, even if you come to a different conclusion as he does. The WHATWG group took it as their goal to listen to web developers and take the step forward that we’ve been waiting almost 10 years for.

Here are some of the challenges they face in making HTML better for web applications:

  • HTML was and is a document format first and foremost.  In the document space, there is no challenge to HTML.  It has found its way into all imaginable types of devices and software.  It is simple and ubiquitous, and must remain so. It is one of the only environments that attempts to fluidly scale between document and application. That’s a hard thing to do. Flex and Silverlight don’t even really try.
  • It is a goal of HTML to be simple to create, but it’s still complicated enough that people screw up and the web is filled with tag soup.  Application developers may shudder at the thought (I do), but the fact is that legacy documents are still important, and that the outpouring of tag soup will probably not stop now.  Instead of “breaking the web” the WHATWG is just trying to standardize how to deal with tag soup.  I think that’s one solution, and may be for the best, but it is not an ideal environment for application development.
  • In addition to the richer needs of web applications, HTML must be capable of serving easily digestible, and indexable content.  It has to be accessible to screen readers and search engines.  Additionally, it has to be international, able to be used just as easily with other languages as it is with English.  These are some high requirements.
  • The HTML spec cannot make assumptions about user agent capabilities beyond HTML itself.  That means that while it can be developed with CSS and JavaScript in mind, it cannot assume that they are supported.

So what does that mean?

To put it simply, HTML means a lot of things to a lot of people. I think that it may be the increased importance and variety of use, as opposed to the stagnancy of internet explorer that has largely frozen the web.  It is a victim of it’s own success. Quickly looking at statistics, we can see that the numbers have jumped from 248 million users to 1.3 billion, and that the percentage of users across the world has exploded.  Additionally, we spend a lot more time and money on the internet, and we access the internet from all different devices.  More businesses are dependent on enterprise web applications than ever before.  Now you want to change it?!

There is no room for radical change in HTML. That is why XHTML flopped, and XHTML2 has failed completely. Only through more gradual and pragmatic evolution can the standards change. At least that is the thought process of the WHATWG. I won’t disagree – they are smart people.

Now what?

Well, WHATWG is getting us back on track.  Apple, Mozilla, and Opera are working together to get to this next stage at last. Even internet explorer is joining in.  So we’re finally going back to improving the internet, awesome. HTML5 is going really. Let me just add in that awesome new component I built:

<AwesomeControl id="myControl"/>

Oh right, no custom components. Well at least I can probably do some data binding so I don’t have to to all that wiring myself:

<input type="text" value="{inputValue}"/>

No?  Well, the competition can.  Don’t get me wrong, there are some things to look forward to – built in SVG and canvas, access to the browser history, client-side database, and even some nice form upgrades.  But let’s get a little perspective.  Real, large scale, rich client application development using HTML has been in the stone age for a long time.  This new stuff is great, but look at the competition.  Not only that, but HTML5 is still in draft form.  How long before it’s widely enough supported to actually be used? Flex and Silverlight are here now. JavaFX is on the way.

Dude!

Dude.  So if HTML isn’t going to do the job (shouldn’t do the job), what is? Hopefully something that isn’t proprietary :)  For my part, I’m focusing on something new to compliment HTML, not replace it.  For the sake of speedyness, it’s going to have to be a plugin. If Adobe can do it, why not the open source community.  There are 1.3 billion users out there.  I reckon if you get the right 0.000001% and a bunch of open source libraries to start you off, it should actually be pretty easy, right ;)

Posted in propaganda. Tags: . 5 Comments »