sorted by: recent | see :
popular
Content Tagged with Editorial + Ajax
On Fighting the Web; The invitation
But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it
This is one of a few great quotes from DeWitt Clinton's post On Fighting the Web itself. DeWitt is a colleague at Google, one that I have shared offices with, and great conversations. He has very strong ethics, but at the same time is very practical. But, back to his writing.
This is not a post saying "the Open Web rules and the proprietary Web is evil". If you actually read this carefully you see a very interesting argument that covers:
We can't be blind:
The short answer is that the technology behind Silverlight, and most certainly the company creating it, has the potential of changing how the web itself works.
The Web has strengths, but man it is tough to work with:
If you’re a web developer then you’ve felt the acute pain involved in writing applications inside the browser. Even armed with the most state-of-the-art toolkits, such as jQuery, Dojo, etc., you’re still limited to the available runtime of HTML, CSS, and JS, and worse, the absolute morass of cross-browser incompatibilities and restricted access to native client-side capabilities. I remain in awe of what people have accomplished in this environment, but I’m sad that this is all we’ve been able to accomplish so far.
Man, if the client is involved... evolution is slooooow:
The web revs slowly. Very, very slowly. In 10 years we’ve seen virtually no meaningful advances in the the ubiquitous web client; just a painful slog forward as web developers learn to eek out just a little more functionality in a constrained environment. Progress is slow because revving the ubiquitous client requires the coordination of multiple parties, not all of whom have shown consistent interest in working together to move the web forward.
There is some hope for an Open Web-style speedup:
More recently we’ve seen some earnest attempts at breaking that cycle. Rather than wait for the entire web to catch up, projects like Gears seek to rev the client from the inside out. It may take several years for standards like HTML5 to be widely deployed, but if developers can gain a toehold inside the client and start forcing the issue immediately then we’ll quickly see what works and what doesn’t, and be that much more informed about what to standardize and adopt as part of the long-term web platform.
The proprietary folks have a huge advantage, as they can just innovate and run without getting consensus:
But there’s another approach, an approach best exemplified today by the Flash runtime, whereby one doesn’t seek to improve the web from the inside, but rather replace it entirely. Sure, technologies like Flash take advantage of the web via http-based delivery mechanisms and in that they run inside the browser, and yes, they can use network connections like anything else, but these alternate runtimes fundamentally divorce themselves from the web ecosystem, and in doing so gain a significant advantage, but at a cost.
In spite of circumventing the web — no, because they circumvent the web — these new runtimes have the potential of offering a far better developer experience, and hence, a far better user experience, then the least-common-denominator of the standard widely-deployed ubiquitous browser runtimes of today.
And, thus, the proprietary stuff can be very good indeed:
Which leads us to Silverlight: Silverlight is positioned to take the fork-and-forget approach to the web pioneered by Flash and bring to it an unprecedented wealth of technology and corporate might. With a better underlying runtime and VM, better tool support, far superior multi-language capabilities, and more marketing muscle, Silverlight has all the potential to make rapid and noticeable inroads over the next several months, cleaving a large section clean out of the web.
And the scary thing? That this isn’t entirely a bad idea. The browser itself is anemic, the dependency on a single language is a handicap, the security models simultaneously constricting and flawed, the development environments underpowered, and frankly, the whole ecosystem is deserving of a major disruption. We’ve lived too long thinking that what we have today is good enough.
And will get better, fast:
Granted, these technologies won’t be perfect at first. On the contrary, they might be slow, cumbersome to deploy, buggy, and feature deprived. But right now that doesn’t matter. The strategy is all about getting a wedge in place, a bit of leverage that can be used to further pry open a vector for escaping the existing ecosystem. And over time, as the technology improves and adoption grows, so will the size of that tear in the fabric of the web.
But, there is a reason why the Web does so well:
But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it.
Why in opposition to the web? This stems from the principle that the web is axiomatically defined as an open system, where the underlying technologies are resistant to the centralization of control, where the protocols and formats are extensible and malleable, and where the power to effect change is shared and distributed. The DNA of the web is one of ceding control, and of learning to work with, rather than against, the collective wisdom and power a larger community.
Whereas a development monoculture, a centralization of control, and a tight grasp on the ability to change and adapt, all stand against these basic ideals, and give rise to the forces that, given enough time, will erode and eat away at any temporary advantage gained.
A violation of these principles does not necessarily make for a bad technology, but it does make it something other than the web.
And finally, and this is so key, the answer isn't to try to destroy the innovation in Flash, Silverlight, and others. Instead, the biggest win will be for us to make technology from those worlds into the Web itself. If we can do that, I think it will be a win-win, and we will have a much better Web to show for it:
But the call to action here is not to go and try to fight the disruptive technology. On the contrary, the ideas are sound and the improvements are very much needed. No, the call is to discover ways in which these ideas can become a part of the web, rather than working to tear it apart.
I do not want to see ambitious attempts like these fail. Just the opposite — I want to see them succeed. But success on the web requires a different kind of DNA, the type of DNA that is difficult to adopt when one’s attention is focused on fighting the web itself.
Open Web 0.4: Composability, Interop, Ubiquity, and the Client
Brad Neuberg got a huge amount of feedback on his call for a definition of the Open Web. He distilled that information and tried hard to come up with something that fits into one sentence, and ended up with this:
The Open Web is an interoperable, ubiquitous, and searchable network where everyone can share information, integrate, and innovate without having to ask for permission, accessible through a powerful and universal client.
His litmus test for this asks if the technology in question has:
- Composability The ability to innovate, link, contribute, search, and integrate without red tape, fear of a lawsuit, or having to ask "please?"
- Interoperability The ability for developers to interoperate without having to know of each others existence
- Ubiquity The ubiquity of a set of open technologies and services agreed upon by the widest possible community
- Universal Client Empowering and evolving the browser and web technologies as a universal client
Power, Authority, and Blame
Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be "blaming" for the slow upgrade of the Web, and it requires a look in the mirror:
As a case study in putting your faith in the wrong idols, you can’t do better than posts like this which “blame the W3C” (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I’ve written about this before, but fundamentally you can’t blame the W3C for failing to act because it’s not the W3C’s job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?
Answering these for pushing the web forward is straightforward, even on a simplistic level:
- Why?: it’s too hard to build reasonably sophisticated interactions with current web technology
- What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
- How?: we could try asking the W3C to do it, but they don’t have any power. When they’ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
- When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is “as soon as someone decides to invest in them”. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That’s clearly not soon enough.
TODO: investigate ways to speed this up.- Who?: browser makers and others in a position to affect the code that goes into the renderers we use.
Figuring out “how” leads you directly to “who” in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The “web standards community” has made it clear that they’ll need the imprimatur of some authoritative body where agreement can be forced, but that hasn’t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the “web standards community” can make enough room for renderer vendors to try out new stuff, since that’s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn’t work, so it’s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I’ll argue that this is now the biggest reason that Paul Ellis isn’t getting the improvements he wants out of the web: there’s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view “fixing the web” as the W3C’s job.
Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C’s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.
The W3C is just a sail and all sails need the wind to function. You can’t blame the sail for the wind not blowing.
W3C Event Debugging; Gears and AIR, not versus; Host-Proof Hosting library
A couple of posts from my personal land that are related to the Ajax world:
First up, I am building an application that uses some canvas and ran into an issue handling events which sent me down a merry path that took me through: initMouseEvent, error fun (Component returned failure code: 0×80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent…..] ), tabindex=0 (thanks Alex), and finally Event.stop(e).
It reminded me of how much I have forgotten, and how debugging can be too hard for Ajax applications. The good news, was that the solution was simple, and the event system does have some very nice properties.
Secondly, some folks tried to make a story out of Passpack adding an AIR application, but we quickly saw how they ended up with both an AIR app, and Gears support in their browser based application. I talk about how this is a valid choice:
I also expect to see more joint applications. Gears functionality is working into HTML5 the standard, which will end up in WebKit (as Apple is great in that regard), and AIR uses…. WebKit as its renderer!
I really hope that AIR will be able to bridge to those APIs, and you get the best of all worlds. I would love to use the Workerpool API from within an AIR application that is doing a lot of JavaScript work for example.
The Passpack team also announced a new open source Host-Proof Hosting Library that has a lot of nice encryption routines packaged up allowing you to:
-
-
Passpack.encode("AES",str,mykey)
-
-
Passpack.decode(algorithm,plaintext[,key,optionalPars])
-
-
Passpack.utils.getBits(password)
-
-
Passpack.utils.genRandomKey([size,salt])
-
-
Passpack.utils.hashx(str[,nohex,full])
-
JavaScript, Rebranded….. Check.
Michael Mahemoff has a nice little post on the rebranding of JavaScript. It kicked off when he was listening to Steve Yegge on rebranding:
He talks about how languages are branded, e.g. “Java” is enterprise. One of his main points is that brands are “const identifiers”, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.
He then mentions Javascript has a branding problem, because it represents “browser” and “toy language” and “damnit, I gotta learn Javascript” and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!).
But, wait a minute, didn't we already have a rebranding?
Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax” was one of the most successful rebrandings in software history.
Although technically Ajax != JavaScript, and the rebranding is really DHTML, he is right. Ajax rebranded the Web, and we have all benefited from it.
I also think that this is just the beginning, and we haven't seen the best of the Ajax revolution yet.
JavaScript, Rebranded….. Check.
Michael Mahemoff has a nice little post on the rebranding of JavaScript. It kicked off when he was listening to Steve Yegge on rebranding:
He talks about how languages are branded, e.g. “Java” is enterprise. One of his main points is that brands are “const identifiers”, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.
He then mentions Javascript has a branding problem, because it represents “browser” and “toy language” and “damnit, I gotta learn Javascript” and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!).
But, wait a minute, didn't we already have a rebranding?
Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax” was one of the most successful rebrandings in software history.
Although technically Ajax != JavaScript, and the rebranding is really DHTML, he is right. Ajax rebranded the Web, and we have all benefited from it.
I also think that this is just the beginning, and we haven't seen the best of the Ajax revolution yet.
W3C Event Debugging; Gears and AIR, not versus; Host-Proof Hosting library
A couple of posts from my personal land that are related to the Ajax world:
First up, I am building an application that uses some canvas and ran into an issue handling events which sent me down a merry path that took me through: initMouseEvent, error fun (Component returned failure code: 0×80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent…..] ), tabindex=0 (thanks Alex), and finally Event.stop(e).
It reminded me of how much I have forgotten, and how debugging can be too hard for Ajax applications. The good news, was that the solution was simple, and the event system does have some very nice properties.
Secondly, some folks tried to make a story out of Passpack adding an AIR application, but we quickly saw how they ended up with both an AIR app, and Gears support in their browser based application. I talk about how this is a valid choice:
I also expect to see more joint applications. Gears functionality is working into HTML5 the standard, which will end up in WebKit (as Apple is great in that regard), and AIR uses…. WebKit as its renderer!
I really hope that AIR will be able to bridge to those APIs, and you get the best of all worlds. I would love to use the Workerpool API from within an AIR application that is doing a lot of JavaScript work for example.
The Passpack team also announced a new open source Host-Proof Hosting Library that has a lot of nice encryption routines packaged up allowing you to:
-
-
Passpack.encode("AES",str,mykey)
-
-
Passpack.decode(algorithm,plaintext[,key,optionalPars])
-
-
Passpack.utils.getBits(password)
-
-
Passpack.utils.genRandomKey([size,salt])
-
-
Passpack.utils.hashx(str[,nohex,full])
-
Require Javascript for Contributions?
On the Stack Overflow blog, Jeff Attwood asks Is it OK to require JavaScript to participate?
Note that by “participate” I mean “edit, answer or ask a question”. Of course passively reading a question and the associated answers will work fine without JavaScript enabled.
...
While we do believe in progressive enhancement, it’s possible that some of the features we’re building for asking and editing may be so dynamic that they do not degrade well, if at all.What say you? Is it OK for a website in 2008 to require JavaScript for active (not passive) participation?
On a forum site like StackOverflow, is it an "enhancement" when you add a comment? Not really, which would make me lean towards keeping the site simple and not requiring Javascript for making basic contributions. There is also accessibility to consider (although "accessible" is not the same thing as "Javascript not required").
It could be argued that as a developer-focused website, Javascript can be assumed. But developers are also the most likely folks to go out of their way and turn Javascript off. And developers are also among the most critical of sites that require Javascript (or Flash) when it could have worked without it.
Webmonkey is back!
Webmonkey was a great resource for us when we the Web took off, and it was a shame to see it die out. Today we saw that Webmonkey has been re-born as Conde bought it back and put the content back online.
We have also republished the bulk of Webmonkey’s vast library of tutorials and reference guides on a wiki. With very few exceptions, every page in the tutorials, reference and code library sections of the site is publicly editable. We’re using MediaWiki’s open source software to host the content.
Some new things you’ll notice:
* Articles can be tagged and rated.
* Each page has its own backchannel for comments and discussion.
* Registered users get profile pages where they can talk about their projects and list the sites they’ve built.
* We’re still in the beta phase. Webmonkey is, and will continue to be, a constant work in progress. If you run into trouble, check the FAQ or drop us a line. We’ve set up a wiki page for bug tracking, so if you see something that doesn’t quite look right, let us know.
Welcome back. Now you can join the other Web monkeys out there (from Tamarin to ActionMonkey).
OpenEXT: The fork
OpenEXT is here. It is a fork of Ext JS 2.0.2, which was under an LGPL license (kinda.... with some invalid, non-open source licensing).
The crux of the fork is:
Ext are claiming that a fork of the existing 2.0 version is not legal, due to the way they applied the LGPL. This is likely to be incorrect, and if correct then their use of the name LGPL was grossly misleading.
At this point, developers are getting increasingly passionate, and Jack needs to make a big effort and come clean to his community to save the reputation of the project. If not, it will probably always be in a cloud of darkness as people are both confused and wonder about motives. This is not about personal attacks, but due to not having clarity on the core issues.
You will notice that most of the detractors are members of the Ext community. They aren't out to spoil some of the work that they themselves put into the project. You see the opposite in fact when you read posts such as this one from Jason Sankey:
The saddest part about this is that the Ext team really have built a fantastic library, and a vibrant community around it. The library had all the hallmarks of an open source success story. Now, however, Ext have committed the cardinal sin of an open source project: they have undermined the trust of their own community.
I actually believe that Jack has been given really poor legal advice, which hasn't helped his thinking on the issue. It has thus spiraled out of control, and needs a big humble gesture to steer things in the other direction.
If I were Jack, I would call a meeting (phone, irc, whatever) and get all of the parties together. Hash it out with an open mind, and end up with the right answer. Again, this is for the sake of the Ext JS community, customers, as well as the entire open source JavaScript community. If this doesn't happen, you are keeping the cloud around the project, and handing contributors to other projects. No-one wants to see this happen.
In my opinion the way to protect your business and the project, isn't through a license to protect the forking. If you have a healthy strong community, any fork by someone wouldn't put much of a dent in you... as who would go with BobsExt when they can get the real deal. Of course, the reverse is also true, and tearing the community apart will lead to a world where you will never find the true potential.
Ext JS and the fun with Open Source licenses
There has been a lot of noise revolving around Ext JS and the open source license decisions. Under the original license (LGPL-ish) many thought that it wasn't actually an open source license at all. Jack changed to GPL last week when he announced version 2.1, but others have been upset with views on forking the old code-base.
I have publicly tried to stay out of the discussion, but today Jack published his thoughts and timeline, as well as frustrations with personal attacks.
This is all such a shame, as Ext JS is great stuff, and I wish that Jack could be spending him time on building more great functionality, and growing his business. I am sure these debates have taken way too much time and energy.
Here is the history from Jack's point of view:
- For 7 months I wrote yui-ext full time from my home, gave it away under a BSD license and loved every minute of it. There weren’t many donations and no official support from Yahoo. With my third child due, and savings running low I had to find a way to continue building what was now changing to Ext JS and also find a way to earn a living from it.
At this time I contemplated switching to a strictly commercial framework. I openly discussed this decision with the community in the Ext forums. If you want to read the discussions, they are here:
“Official Commercial License Input Thread”
http://extjs.com/forum/showthread.php?t=2194“Official Open Src License Thread (Commercial License Part 2)”
http://extjs.com/forum/showthread.php?t=2253In the end, after much discussion with the community, I decided to go to the LGPL.
- Shortly before 1.0 is released, there numerous Ext “clones” started popping up that were hacking Ext themes, css and other resources from 1.0 - before we had even released 1.0. Here I had 4 new themes for Ext JS 1.0 that I had spent countless hours working on (I am not a great designer) and what could now be considered competitors were already using it before I even have a chance to release Ext 1.0.
That’s why the proprietary license on the “Assets” (CSS and images) was introduced in Ext 1.0.
- Ext JS 1.0 is released under the LGPL, minus the Assets license as mentioned above. Shortly thereafter 2 major publicly traded corporations (names withheld) embedded Ext JS into their development frameworks. With no mention of Ext JS except in credits files that no one ever saw. No support for all the work that had been put into the framework. Neither one of them even contacted us. How can that be possible? Can they do that? How can we compete with them taking such a large chunk of our potential customers? These are the questions I was faced with and so began my “Intro to Business 101″.
The next release of Ext JS was released under the Ext License, to serve as proxy to the LGPL and add the additional “no framework/toolkit” restriction that was present until 2.1.
Then things got public:
- This blog post comes out on CNET out of nowhere:
- Alex Russell publicly bashes the Ext License on Ajaxian (sorry no link, I could’t find it) and then continues his attack on the license with me personally over email. He then follows with this blog post:
- Matthew Garrett decides in his infinite wisdom to completely disregard our Ext License or Assets license:
- Dion Almaer of Ajaxian privately informs us of concerns he has about the Ext License. His points are very clear and sincere and he is only interested in the open source community as a whole.
- Several private conversations were held with customers regarding the license, spurred by the links and discussions above.
Then Jack talks about some personal attacks, which I won't go into here.
I really hope that this can be worked out, and we can move on. The last thing that Jack, the Ext community, and even the open source JavaScript community needs is for this to go forward. It needs a quick solution, and I think that a message about the past code base can take care of this.
This reminds me of my old days running TheServerSide. These kind of situations happened pretty regularly. Controversy was the norm, especially with characters like JBoss around... oh and CocoBase brought a lot of hilarity too with their fake legal stupidity.
Anyway, I have been very happy to see that Ajaxian hasn't had the same level of controversy in the Ajax community as I saw in the Enterprise Java one. Controversy is great for page views, but life is too short. I hope that our community stays strong and united around the simple goal:
Let's grow the Open Web. The bigger we grow it. The bigger the pie. And, then we all succeed.
What is the future of Ajax applications talking to the data tier?
I have just posted an article on the new attack on the RDBMS on my personal blog. The post talks about the new thinking around data in the cloud, and on the Web. It first starts out by remembering that this isn't the first time the RDBMS has been attacked, and remembers the OODBMS attack, which didn't do too well. Then it gets into the cloud-y Web:
SQL is an enterprise victory that managed to make its way into the consumer Web and application space. A lot of people knew SQL, and it seemed obvious to have a LAMP stack or a Java / .NET stack backed by a RDBMS.
Is this really the right choice for Web applications? Why was Rails so successful? It was due to the productivity gain. How much of that is due to ActiveRecord vs. the other Action* pieces that make up Rails? I would argue a large percentage. Working with the database was actually a big pain in the tuches. ActiveRecord together with migrations helped a lot. It gave us a nice middle man between a full ORM and the SQL that we know and …. know.
What if the database piece didn’t need to be that painful? The source of the pain can be the paradigm shift between the various worlds, but also a huge part of it is scalability. When you have to scale your website, it can be fairly easy to make your application stateless, and then the bottleneck becomes the poor database. This is when you break out the master / slave relationships, think about partitioning of the application, and caching layers (Tangosol Coherence, memcached). Now you have to really think about an architecture ;)
Google had to do this thinking a long time ago, as they obviously have to scale their applications to a huge degree. Scaling the fairly read-only search operation is one thing, but as soon as you get to read-write operations you have a lot more of a head-ache. Scaling a MMORG astounds me. To be that real-time, and having the world constantly changing. Wow. At least there are the separations of locations (world X can be this cluster of machines).
Now we get to Bigtable, the engine that Google built to scale in the cloud. Amazon has their new SimpleDB, and there are others.
What these guys are all doing, is revisiting the database story. Maybe it is time to think about if a RDBMS is the no-brainer choice.
When Google App Engine launched, I thought there would be a lot of people saying “oh man, I just want MySQL instead of this new thing”. I barely heard that, and instead heard more thoughts along the lines of “It is great to be able to use the scalable database that Google uses internally.” In fact, when you start using it and see that it is schema-less, you get a bit of a relief. You can build your model, and even use an Expando to be highly dynamic on the data in the backend. You go along your way, iterating on your code and model and you don’t have to spend time working on
upanddownmigration methods. Doesn’t that remind you a little of the OODBMS dreams? But this time it is fast and scalable!Resting on the Couch
With the interest in Bigtable via App Engine pushing thought, we also have CouchDB pushing from the other end. The end that says, what would a RESTful approach to a database be?
Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API.
JSON built in. JavaScript right there. A database built for the Web?
It is great to see new ideas and thought about the storage of data. The RDBMS isn’t going anywhere of course. There are still a ton of tools out there for it and legacy code, and we all know that:
Data stays where it lies.
It is much easier to implement a new application talking to the old datastore, than migrate the datastore itself. It is like taking out the foundation. Also, SQL is getting new life in places too.
SQLite
I recently saw an application that used GWT on the client, and JavaScript on the server, which reminded me of my comic above. I wonder if we may end up with another flip, having SQL being used in the client, and other systems like CouchDB, Bigtable, etc being used in the enterprise / on the server.
It is happening on the client. SQLite seems to be everywhere. Your operating system, phone, browser, applications, everywhere. I bet I have around 20 SQLite engines on my system right now, and growing. Why is this happening? Well, instead of coming up with your own data format, parser, and search engine, why not just use SQLite and be done. It is very faster, perfect for single user mode, so everyone is a winner.
So, SQL has a looooong future ahead of it, but it will be interesting to see how the RDBMS weathers the latest storm.
Geoff Hendrey, of NextDB.net, emailed me discussing a similar issue and how he thinks that:
The database access issue is the "elephant in the room" as far as Ajax apps are concerned. It's a very hot topic, evolving rapidly, and related to cloud computing and DAAS (SimpleDB, LongJump, S3, Blist, NextDB.net, BigTable, etc).
Geoff is going to be at Web 2.0 Expo talking on the subject.
What are your thoughts on Ajax and the data tier?
ASIDE: I will be giving a joint talk with Ryan Stewart of Adobe there too, so come say hi, and ping me on Twitter with any thoughts.
What does the “Open Web” actually mean?
Many of us use the term "Open Web", yet what does this actually mean. There isn't a Wikipedia entry on it yet. When you start to think about it, you may be surprised to find out how hard it is to pin down. It is HTTP, HTML, JavaScript and CSS? Brad Neuberg argues that they are just technologies that right now happen to implement the core philosophies behind it in his opinion piece What's the Open Web and Why Is It Important?
- Decentralization - Rather than controlled by one entity or centralized, the web is decentralized -- anyone can create a web site or web service. Browsers can work with millions of entities, rather than tying into one location. It's not the Google or Microsoft Web, but rather simply the web, an open system that anyone can plug into and create information at the end-points.
- Transparency - An Open Web should have transparency at all levels. This includes being able to view the source of web pages; having human-readable network identifiers, such as URLs; and having clear network entry points, such as HTTP and REST exposes.
- Code Hackable - It should be easy to lash together and script the different portions of this web. MySpace, for example, allows users to embed components from all over the web; Google's AdSense, another example, allows ads to be integrated onto arbitrary web pages. What would you like to hack together, using the web as a base?
- Open - Whether the protocols used are de-facto or de-jure, they should either be documented with open specifications or open code. Any entity should be able to implement these standards or use this code to hook into the system, without penalty of patents, copyright of standards, etc.
- From Gift Economies to Free Markets - The Open Web should support extreme gift economies, such as open source and Wikis, all the way to traditional free market entities, such as Amazon.com and Google. I call this Freedom of Social Forms; the tent is big enough to support many forms of social and economic organization, including ones we haven't imagined yet.
- Third-Party Integration - At all layers of the system third-parties should be able to hook into the system, whether creating web browsers, web servers, web services, etc.
- Third-Party Innovation - Parties should be able to innovate and create without asking the powers-that-be for permission.
- Civil Society and Discourse - An open web promotes both many-to-many and one-to-many communication, allowing for millions of conversations by millions of people, across a range of conversation modalities.
- Two-Way Communication - An Open Web should allow anyone to assume three different roles: Readers, Writers, and Code Hackers. Readers create content, Writers create content, and Code Hackers create new network services that empower the first two roles.
- End-User Usability and Integration - One of the original insights of the web was to bind all of this together with an easy to use web browser that was integrated for ease of use, despite the highly decentralized nature of the web. The Open Web should continue to empower the mainstream rather than the tech elite with easy to use next generation browsers that appear highly usable and integrated despite having an open infrastructure. Open should not mean hard to use. Why can't we have the design brilliance of Steve Jobs coupled with the geek openness of Steve Wozniak? Making them an either/or is a false dichotomy.
He goes on to talk about the importance of the Open Web, and details of a talk that he is giving at the Open Web Vancouver conference.
What are your thoughts on the Open Web? What do you agree or disagree with in Brad's thoughts? I am curious how divergent we all are!
Kevin Hakman joins Aptana
When we posted the last podcast on Aptana Jaxer, someone commented on the fact that Kevin Hakman was there, and "Doesn’t Kevin Hakman work for Tibco? What does he have to do with Aptana?".
Aptana has now come out with the news that they have hired Kevin:
We are excited to announce that Kevin Hakman has joined Aptana to head up marketing and developer community programs. Kevin is a recognized leader in the Ajax community. Long before the term "Ajax" was coined, Kevin was pioneering single page web application concepts via the company he co-founded, General Interface Corp., one of the first enterprise Ajax libraries and visual development tools companies. General Interface Corp. went on to be acquired by TIBCO Software in 2004 as a compliment the company's service-oriented architecture (SOA) products. Today TIBCO General Interface is used by many Fortune-scale companies for rapid Web application development and deployment atop their XML and SOAP data sources.
In addition to his historic role on the steering committee of the OpenAjax Alliance, Kevin currently chairs the organization's integrated development environment working group. The OpenAjax Alliance IDE Working Group which includes Adobe, Aptana, the Eclipse Foundation, IBM, Microsoft, Sun, TIBCO and others is now close to delivering a draft specification for a uniform way to describe Ajax libraries and controls and thus streamline the ability to use Ajax libraries within your development tools of choice. Kevin is a frequent speaker at Ajax industry events and is an author to many published articles on Ajax in the enterprise.
I asked Kevin a couple of questions about his move, comparisons between the companies, and the industry in general.
What similarities / differences do you see between pioneering heavy JavaScript on the client w/ GI and JavaScript on the server with Aptana
GI and Aptana's primary application models are different to serve different purposes similar to the way that Java has multiple presentation tier architectures for differents kinds of apps: Swing, SWT, AWT for application GUIs and JSP, JSF for generating web pages. With GI, the concept in 2001 when we deployed some of the first "Ajax" apps pretty much evolved from a need to migrate software-style GUIs to the Web and a technical approach summarized as "we like Java Swing, but not the JRE dependency, so let's do something Swing-like in JavaScript with a JavaScript VM of sorts and get data as XML / SOAP via the XML HTTP Request Object -- an oh yeah, make it Visual Basic-like easy to visually develop too". That led to what I call a "Client-Services" architecture where you have a full fledged JavaScript application running in a web page talking to back-end data services plus the WYSIWYG rapid development tools for which GI has been recognized as best in class in enterprise IT journals. With GI, you never really interact with the HTML page or its DOM. Instead there's a higher abstraction of application concepts and a model of the GUI, called "dual DOM" by some. The result is that the JavaScript applications are deployed into a webpage more like an applet, (except it's all in the same JavaScript memory space and there's no JRE dependency of course). This "Client-Services" architecture has been a great fit for many enterprises pursuing service-oriented architecture strategies.
Aptana Studio is clearly among the best-in class for the predominant model of Ajax development called "single DOM" where you work directly in the HTML DOM to describe elements within a page, then apply Ajax and CSS concepts to bring that page to life with interactive features. Aptana Studio meets the needs of Ajax developers working in this model extremely well. Whereas tools for web page development have historically focused on layout, image placement, styling, and JavaScript for roll-over and simple navigational assists, Aptana saw that with Ajax and the popularity of all the single-DOM model Ajax libraries like dojo, Ext, prototype, MooTools, and jQuery, the page was becoming increasingly programmatic in the client and needed tooling optimized for the programmatic page.
What excites you about Aptana
Aptana Jaxer is a very cool concept for all the JavaScript developers out there because they can now go boldly where no JavaScript developer has gone before--to the server-side. Sure Netscape had LiveWire back in the day, but remember there was no real DOM, no real CSS and certainly no XHR object at that time. Aptana Jaxer's genius is that is takes the same Mozilla engine we know and love in the browser, and puts it inside a server along with a bunch of handy Jaxer methods and properties to do server-side things like interact with databases, web services, session concepts, sockets and more. I personally love the ability to write a script that runs on the server, but call it from the client as if it were running on the client. In this case Jaxer handles all the sync or async communications for you transparently, and soon will provide end-to-end debug capabilities as well. We're also now working with Joe Walker of the DWR project to extend this kind of capability to remote Java objects as well through Jaxer. We're also investigating how to best interoperate with Microsoft’s .NET platform.
To some, JavaScript is not a preferred language and that's where things like GWT and DWR come in real handy. At the same time there's millions of developers who like the ease and mutability of JavaScript. Aptana Studio, with its JavaScript debug and type inference capabilities, and Aptana Jaxer with its server-side power enable all JavaScript developers to do much more, more quickly in the language we love to work with -- JavaScript! Thinking beyond the solid JavaScript programming tools in Aptana Studio today, things like visual WYSIWYG GUI composition and data-binding are clearly natural extensions. Not many people know that the Aptana team contributed to much of the Eclipse Monkey code which enables JavaScript to run within and communicate with Eclipse's APIs. This means that Aptana is extraordinarily well positioned to execute a first-class solution for WYSIWYG editing -- and further streamline the creation of Ajax web pages and full-featured Ajax applications.
Now you have been around JavaScript for awhile, what are you likes and dislikes, and do you have any thoughts on JavaScript 2?
Having been part of Ajax projects where we had single HTML pages running for 9 hours sessions with over 180 separate application modules you could load/unload during that time (and that was in 2001), the GI core team (Luke Birdeau, Michel Peachey, Jessee Costello Good, and myself) has had loads of experience in what it means to make highly scalable, full featured apps in JavaScript. Much of what we had to invent and implement in JS1.5 for the TIBCO GI Framework, things like object orientation for example and better memory management, is on the horizon for future releases of JavaScript. The primary pain of JS though, until recently, has been lack of great debugging, type inference, and code assist capabilities. What few people realize about Aptana Studio is that it not only code assists on the Ajax libraries you've loaded, it assist with the Ajax objects, classes, packages, functions and properties that you create too -- again a concept borrowed from the Java community, but with less programmatic overhead since its JavaScript.
Random thoughts from a Firefox
Robert O'Callahan has a nice recap of BaaCamp down under.
Robert talks about various talks that he went too, for example on AIR which touted:
features that can and should be provided by browsers too, possibly via extensions like Gears for the laggards, ideally via standard APIs like HTML5.
Robert feels like there is still a bit difference between the browser and Flash:
There are few philosophical differences between AIR and the browser. The biggest one is that AIR doesn't sandbox apps, so users have to make a trust decision to use an AIR app. I don't know how high a barrier that is to AIR app adoption; I hope it's a high one, because users should be reluctant to let applications abuse them! Another, related difference is that AIR lets apps escape browser chrome such as the forward/back buttons and the address bar. I can see that app designers would love that --- yay for integrity of artistic vision! --- but I'm not sure users would. Browser navigation (back, forward, bookmarks, addresses and autocomplete) is a powerful mental model that is not only deeply entrenched but is actually very useful.
He then goes into detail on the IE 8 features, and finishes up on bug hunting with Firefox 3. I have been using that on the Mac, along with Webkit, and I am impressed. It is fast, and doesn't churn the memory as much. I couldn't use Firefox 2 anymore!
Beyond DOM
Neil Mix is scheming and waiting for someone to go beyond DOM:
Here’s the problem as I see it: the UI I’ve coded, what you see on the screen, is a reflection (some would call it a transformation) of the data sitting in memory in my JavaScript objects. So why is it that every time the data changes I have to go twiddle something in the DOM? Shouldn’t that just happen automagically?
Why should I have to wrap my head around two UI representations, the markup and the DOM? Markup is easy to read but captures a small sliver of the UI gestalt. The DOM captures everything else, but sits in memory. Can’t it all just be markup, so that I don’t have to spend so much time visualizing data structures whose only representation is either in code or in Firebug?
Neil is looking to cycle back and see how we can put pieces together to get to a better place. I think that 2008 is the year for this. We are seeing many rich Ajax applications which need more than simple XHR requests, and feel the pain that ensues. There is room for solutions that nicely tie the client and the server in a smart way.
Google Gears Future APIs
Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about "offline", when that is just the surface.
I started off by discussing the Image Manipulation API, "is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing - a user can edit a photo with instantly applied changes before uploading it to the server."
Then I went on to the Desktop Shortcut API where you can:
-
-
var desktop = google.gears.factory.create('beta.desktop');
-
desktop.createShortcut("Test Application",
-
"An application at http://www.test.com/index.html",
-
"http://www.test.com/index.html",
-
{"16x16": "http://www.test.com/icon16x16.png",
-
"32x32": "http://www.test.com/icon32x32.png",
-
"48x48": "http://www.test.com/icon48x48.png",
-
"128x128": "http://www.test.com/icon128x128.png"});
-
The Location API provides a means to fetch the location of a device running a Web browser with Gears:
The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.
The Messaging API fits in with the current WorkerPool API to give you cross domain rich messaging:
-
-
var port = google.gears.factory.create('beta.messageport', '1.0');
-
port.onmessage = function(port, msg, sender) {
-
alert("message: " + msg);
-
};
-
port.listen("name"); // Omit for anonymous listener.
-
-
// and having a way to send it a message:
-
-
var port = google.gears.factory.create('beta.messageport', '1.0');
-
port.open("name");
-
port.sendMessage("hello there");
-
There there were smaller fry such as a Logging API, the Blob API, and Factory API updates.
To finish off we have the issue of developer tools. We need to make sure developers have the tools they need to enable successful app development using the APIs, so we want to first add:
- Database
- List databases per origin
- Create new
- Delete
- Interactive DB command line (can just use existing /sdk/tools/dbquery.html)
- List ResourceStores (and ManagedResourceStores) per origin
- ResourceStore and ManagedResourceStore status (last error, update history, etc)
- command line (like db command line, but pointed at localserver DBs)
- Show running workers
- Interactive JS prompt to run JS inside a worker
- Interactive prompt to send messages to a worker
- Show logging in real time as it happens
- Show historical logging
- Sort/filter by origin/page of source page
I would love to see what you would like to see, and these thoughts will be the subject of future posts.
Matt Webb on the Web 2007 Wrapup on the Web
Ah the end of the year, the time to write top ten lists and predictions. I am not going to go this here. We do that enough in our State of Ajax talks.
What I will do though, is the digital version of something I dislike. As an experiment, I used a "highlighter" on Matt Webb's piece on wrapping up 2007, which is a fantastic (and long) flow of consciousness that manages to say everything and nothing.
Here are the yellow bits as I saw them:
So what does phenotropics mean for the Web? Firstly it means that our browsers should become pattern recognition machines. They should look at the structure of every page they render, and develop artificial proteins to bind to common features.
While browsers look for patterns inside pages, search engines would look for inter-page, structural features
...
I have a feeling that refactoring code is not a good thing. I am not in favour of deleting code. If there are problems with code the way it is written, there should be mechanisms to code over it gradually, and leave the old code there.
A codebase should be its own source repository: seeing what the code was like a year ago shouldn't be a check-out from source control, but archeology.
...
What the Magna Carta did - or rather, what the process that the Magna Carta was part of did - was turn the king into a thing. The thing-king is the king revealed. The important feature of the document isn't the constraints put on the king, but rather the fact that it is possible to bind to the king at all.
This means we'll have metamarkets, in the end. Mini free markets captured and tuned to perform particular tasks, inside a society we can't currently grasp, just as China held Hong Kong in a bubble to propel it into orbit, and the Large Hadron Collider intends to create new zones of particular kinds of physics in order to perform scientific experiments.
...
I want to think about social software in reverse. Can we take activities that are already group-based and irreducibly social in the real world, and make software that is good for them?
Perhaps the login system could be based around questions: 'what is a name of a blonde person in your group?'
...
To generalise Flickr's attributes, successful interactive systems will bend users back towards them, whether by play or not.
...
The cleverness of Getting Things Done is to wrap this finite-state machine in another finite-state machine which instead of running on the tasks, runs on the human operator itself,
...
Websites can also be seen as finite-state machines that run on people.
Instead of a finite-state machine, think of a website as a flowchart of motivations....
Imagine popularising a method like Getting Things Done crossed with the creation and value of the diamond industry
I am looking forward to see what you come up with in oh-eight.
Alex Russell is trying to save us
Alex continues on truthiness with The W3C Cannot Save Us that follows on from the CSS uprising as we watch things crash and burn.
Alex discusses the Opera case (how it is a bad idea), and how Opera could be more productive.
He calls out how we can't hide behind the "let's just make IE work with standards better" line:
In order for the future to be better by a large amount, it must be different by a large amount.
Until we get some great new (non-standard) CSS features out Mozilla, Opera, and IE nothing will get better to the extent that we will again be optimistic about the future (Safari earns a pass). The size of the improvements they deliver in the future are directly tied to our expectations of how different the future will be. Only when there are large and divergent ideas of how to proceed expressed through competing, successful implementations will standardization really work to whatever extent that it can reasonably be expected to.
Let that sink in a bit. To get a better future, not only do we need a return to “the browser wars”, we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality. Non-standard features are the future, and suggesting that they are somehow “bad” is to work against your own self-interest.
Web developers everywhere need to start burning their standards advocacy literature and start telling their browser vendors to give them the new shiny. Do we want things to work the same everywhere? Of course, but we’ve got plenty of proof to suggest that only healthy browser competition is going to get us there. Restructuring the CSS WG or expecting IE8 to be “fully standards compliant” is a fools game.
*listens to a beating drum*
Ajax, Browsers, Running Out of Time
History repeats itself, first as tragedy, second as farce. -- Karl Marx
I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision -- I was a Mac and Unix nerd all through college -- but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I'm sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I ran out and bought a PC that very day.
Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.
I'm not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I've even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.
The cause should be evident to everyone. We've taken what was first called LiveScript -- a crufty embedding just good enough to validate a form or two -- and we've abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.
Help is on the way, in the form of bytecode interpreters and vm's for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don't arrive quickly enough, or if they don't fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.
Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn't reliable, it will be as dead as the Java Applet, never to be heard from again.
Real Men Don’t Do JavaScript Do They?
Dave Thomas (The AOP/Bedarra one, not the Ruby one) has a column titled Programming the World in a Browser: Real Men Don't Do JavaScript Do They?! where he discusses how JavaScript won:
The mainstream professional developer community has never taken JavaScript seriously but soon they will have no choice. JavaScript is ready to move to center stage as the development and delivery technology for Web 2.x applications. In the past, most enterprise and product developers flocked to Java or C# while web developers moved to PHP, Perl, Python and more recently Ruby, with most ignoring the web based scripting language called JavaScript. At best it has been considered something to spiff up one's HTML pages. To make matters worse, incompatible implementations of JS and the DOM have tormented developers and made JS very unpopular with many. Until Ajax and Web 2.0 Douglas Crockford seemed to be the only advocate for JavaScript as a reasonable programming language. He pointed out that JS was really a Scheme like language with a prototype-based object model layered on top of it. I'm sure that popular author David Flanagan never dreamed that he would be best known for his book Definitive JavaScript.
While many smaller companies had built quality widgets and applications in JS it is was the entry of Yahoo Widgets, and more importantly the that of Google Mail, Calendar, etc. that laid the commercial foundation for the Ajax revolution with a plethora of frameworks and tools. Rather than bulky and complex web standards, more and more of these toolkits support simpler Restful style services that use JSON rather than SOAP.
JavaScript's ubiquitous browser availability makes it the frontrunner in that environment and this will no doubt ripple to servers and appliances. JavaScript is headed into the limelight once promised to Java, then later to Flash.