*Web* Developers vs Web *Developers*

Preface

I’m not trying to make the distinction a hierarchical one.  There is a whole spectrum of equally valid web developers.  Some come from a software engineering background and work mostly on the server, some don’t know much about programming, but they are whiz-tastic at crafting semantic markup and css.  Don’t forget the thousands of n00bs, the WYSIWYG users, and everything in between.  The web is for everyone. That is one of the most important aspects of the Open Web.

Simplification

Let’s just break things down for the sake of a simplified discussion. The people developing for the web (whether it be sites, applications, or something in between) either have a background in programming or they don’t.  Looking at the origins of the Open Web technologies, specifically HTML, it was intended as a way of formatting and linking documents in a very simple way. No programming experience needed. As that changed, web technologies became more complex and programmers were needed.

So, following logic:

  1. Is it important to continue supporting both programmers and non-programmers?
  2. Can we have a single, unified model that supports both at once?
  3. If we had to choose a group as the highest priority, which would it be?

sigh – ok let’s give it a shot.  Yes. Hopefully. The programmer group (don’t hurt me).  Basically, my argument would be this – you can’t squeeze blood from a stone.

XYZ

Lets say there is a set of functionality available to language X. [When I say language, I mean its syntax, but also its libraries and system apis.] X is tedious to work with, but represents all possible functionality.

Y is a language built on X that can accomplish 90% of what X can do, but in a way that is much easier to work with.  It still takes a trained user to work with Y, but they can get a lot accomplished.

Finally, language Z is a domain specific language built on Y that is simplified for a specific use that takes very little training to use. It is a lot more forgiving to its users, and while it can only accomplish 20% of what Y can do, it can do 80% of what the users can possibly want.

I’m sure you already picked up on what I’m putting down, but I’ll elaborate anyway.  XYZ is a process that happens all over the place with great success.  In fact, all modern computing is built on this very process. Machine instructions are like X.  Anything the computer does must eventually boil down to it.  But we build abstraction layers on top of it because its the only way to build scaleable software. Then we add more layers as it makes sense.  One important thing to remember, though, is that you always build on any layer.  In the example, Z built on Y and Y built on X, but maybe language W also builds on X.  Maybe W has a different idea of what would be the important 90%, and what the syntax should look like.  Maybe T, U, and V are all small languages like Z, but they just want to cover a different 20%.  The problem is, it’s very hard to reverse the order and build Y on top of Z instead of Z on top of Y.

Enough letters already!

I know, sorry.  Let’s apply this logic to the Open Web.  Right now, the basic building blocks that we have available are HTML, CSS, and JavaScript.  These were all built with the end user in mind. At the time of creation, the end user was not software engineers, and the purpose was documents, not applications.  I guess what I’m trying to say is that right now, we might be trying to build Y on top of Z.  Throw in a lot of workarounds and hacks and we’re getting there, but there’s just no substitution for a more solid foundation.  I will present just a couple of examples.

  1. Security.  I cannot stress this one enough. We need to be ready for secure mashups. They are coming and they are important. Having a global space is a big problem.  Not just javascript objects, but also the DOM.  And the DOM is not very secure.  We need the foundation to ALLOW better security.  Even if the higher level opts not to use it, if it is impossible to achieve at the base level, it is impossible to achieve at a higher level.
  2. That damned file input! This is exactly the kind of constraint that is still worked around through hacks, but it seriously needs improvement.  The point is, without lower level control, there is nothing you can really do about it.
I’m going to end the post here.  These thought are stewing around in my brain, and I’ll post something else when the they’ve simmered long enough.

Let’s Get Crackin’!

I recently had a conversation with Brad Neuberg about the concept of using a plugin to have an Open Web competitor.  Brad suggested that this was precisely what Google Gears was trying to do (sort of).  In a recent post of his (which has since sparked a conversation across the blogosphere), Brad discussed the definition of the term Open Web and its importance, but also how Gears can help to push the web forward. In our conversation, he asked, “If you were to add functionality to Gears that doesn’t enhance the web’s existing technologies, but rather creates new ones that live in the browser through Gears what would these look like?” The following was my response:

………………………………………………………

1. I think data binding needs to be built in – with mechanisms for formatting and validation (and if you mention XBL, I’ll respond with a blank stare.  Seriously? Stuff like that is the reason Flex and Silverlight are looking so good right now.)

2. HTML5 and SVG can get us most of the way there when it comes to visuals, but its not very friendly for application development because there’s no abstraction layer.  There is no way to compose or componentize a set of elements and attibutes together and then use it as a custom tag for example.  JavaScript frameworks have gone a long way towards simulating this, but it needs to be built in, and it needs to be easy. I would propose an addition to the HTML syntax that basically allows for templating in a very component oriented way.  These templates would be incorporated into the binding syntax, so that they could “re-template” when needed without having to make explicit DHTML calls. I would also advocate for staying with xml syntax.

3. CSS is a really cool idea, but it needs some re-evaluation.  First of all, it needs better layout management.  The hoops required currently are a little obscene.  Even adding a “layout-manager” property with a few possibilities would go a long way.  I would also definitely add CSS variables that, again, could be integrated with the binding layer.  CSS expressions were definitely a mistake, but variables would be extremely powerful.  For some ideas, just look at what webkit is doing with their css transformations and animations.  It would be so much simpler to just put a variable in.  Then a simple easing library could be used to change the variable over time to create animations. Finally, I think that CSS could be better incorporated into the new component model.  For example, it would be helpful to be able to scope rules to components, and allow custom tags to be selected.

4. I’m in the group of people that isn’t totally gung ho about JS2.  I understand the motivation, but its looking like a bit of a kitchen sink language. I think JS needs some improvements, but I’m actually looking at Erlang for inspiration instead of Java and Python.  In my vision of a future JavaScript, I see a few things.  First of all, I think there are some functional language features that would be good to add considering JavaScript is a lready a very functional language. I would like to add overloaded functions that use matching and guards for differentiation. I would also like to steal some aspects of the big Erlang feature of concurrent processes.  Here, I think, is a perfect convergence with Gears.  The Gears worker pools are a lot like Erlang processes (which I’m guessing you knew).  No shared state, separate process, and no access to the dom.  As I’m sure you know, this can be extremely helpful when trying to stay secure doing mashups, offload intesive operations from the main thread, and communicate with the server. Additionally, I think that there needs to be a little more in the way of modularizing code, allowing private data members, and facilitating better code reuse.  I think prototypal inheritance and mixins are definitely better than classes for the language, and I’d like to add some more syntax to encourage them.
………………………………………………………

It’s great to talk about the deficiencies in the technologies we have, but to really move forward, we need a conversation for what can come next. And by next I guess I mean the next next.  HTML5, CSS3, and JS2 are all really great things.  I encourage people to be as involved in those as possible, but I still have a lot of doubts about its ability to stay pragmatic, on track, and happen quickly.

If you could snap your fingers and have a plugin with a wide install base built for web applications (as opposed to web sites), what would it look like?  You can leave a comment, or even better, take a look at the group.

The Premise

If you haven’t seen it already, I recommend you watch this presentation by Douglas Crockford. Douglas Crockford, love him or hate him, knows a lot about internet technologies.  Even if there are aspects you do not agree with, I think his presentation makes many good points. To summarize:

  • Despite its flaws, standard web technologies (html/css/javascript) are hugely successful and have been able to accomplish what others have not.
  • It provides a taste of the potential for the internet – mashups, social computing, powerful web-based applications.
  • We’ve used (abused) every ounce of functionality made available by browsers, but we’re reaching the end of line.
  • There has been very little advancement of the browsers in the past 10 years.
  • We need to move forward, but there is no clear path.

Every web developer is aware of the difficulties of cross-browser ajax application development.  Javascript libraries have made a valiant effort and taken us a long way, but we have a long way to go.

New Developments

The competition for beating the new Acid 3 test has been fierce, and now Opera and Webkit have cooked up versions capable of passing. There is also  building support for the unfinished HTML 5 specification in several browsers.  Also, IE8 beta is passing Acid 2, as well as contributing some of its own new developments.  One might think that this is the answer.  Maybe we don’t have to worry as much as Douglas Crockford might think we do.  Here’s the problem: a lot of people are still using IE6!  Even if all browsers came together right now – even if IE replaced their rendering engine with webkit, there would still be problems.  The web just doesn’t move that fast.

Other Thoughts

recent post by Chris Keene and Alex Russell describes this proprietary side of the web, the “unweb”. They propose that the way to save the open web is as follows:

The key to the web’s future is real competition between the browser vendors that will force them to evolve the browser quickly. These features include:

  • Auto update capabilities
  • 3-d rendering
  • Support for new semantics in HTML
  • In short, give us native ability within the browser to do what we otherwise have to do in Javascript libraries

I think that this is one possible route, and good advice in general.  But is it a realistic possibility? Competition between browsers is a good way of moving forward, but also leads to incompatibilities.  Javascript libraries will once again be the stopgap to manage these incompatibilities, with the end result being the lowest common denominator.  Definitely better than nothing, but the real question, is it better than the “unweb” alternative.

Possible Solution

I believe there is an alternative solution.  I believe it is possible to fight fire with fire. If Flex/Silverlight/JavaFX threaten the open web, is there a way to compete on the same playing field? If the w3c technologies can’t compete, can we take a different route? I propose that one very real solution to the problem would be to create an open source plugin technology to compete. It would allow a few things. First of all, it could ignore backwards compatibility because there would be nothing to be compatible to. Secondly, the cross browser issue would be resolved by being a plugin instead of a single browser implementation.

Posted in propaganda. Tags: . 3 Comments »