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.


3 Responses to “Let’s Get Crackin’!”

  1. charlie Says:

    First of all, good points. I agree wholeheartedly about the data binding and security layers and though I am not familiar with Erlang I believe I understand.

    Concerning your third point, I’m not understand I understand the layout manager idea (admittedly this is likely due to my inexperience). I absolutely agree with your critique or current css though. It seems like it puts such a a strain on developers to do the simplest things which could easily be alleviated with variables. Though at what point does css stop and javascript take the reigns, or do you see this ambiguity as a strength?

  2. Russ Says:

    Thanks. I’ll be developing on these ideas more soon to expand and clarify these ideas. The point about Erlang will take longer, so I’ll save that for later, but I think I can clarify the point about layout managers.

    I guess I’m showing my Swing background here, but most desktop systems have some kind of explicit layout management system. Basically a layout manager is a way of explicitly defining how elements inside a container are automatically laid out. Right now, css allows most of the tools needed for layout management, but provides them in a way that can be awkward and difficult. CSS3 will make some things better, like the new template layout, but having explicit layout managers could make a lot of simple things simple again.

    Here’s a really simple example:


    No floats, no clears, just a simple horizontal layout. I think that css provides a lot of lower level layout functionality that I would never get rid of, I just think a higher abstraction layer would be very powerful and helpful. Just imagine:


    for simple pretty forms.

  3. tav Says:

    Man, we should talk!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: