I’ve seen a few people complaining about and/or questioning the lack of mature tools to develop content for the modern web (aka HTML5), and it got me thinking about the evolution of these tools, and how challenges are solved for technology platforms in general.
In my (albeit limited) experience, there is a natural progression for a maturing technology stack, particularly one without a single master (ex. Flash and iOS development differ somewhat because the tools and platform are directed/developed by the same entity).
First, you will see the development of a lot of frameworks, starting with micro-libraries that address a single challenge, and evolving to macro-frameworks like JQuery that tackle an entire workflow. Developing frameworks has a very low barrier to entry, and provides an ideal way for developers to explore and share a variety of potential solutions for challenges. Because the libraries are written in the domain language, it also means that any developer encountering a problem can address it directly with a language they are familiar with.
As problems become better defined, and specific solutions begin to emerge as more dominant, you start to see single purpose tools created, often as command-line utilities. These have an increased investment compared to frameworks, and require that the developer has knowledge of both the problem domain, and basic desktop development.
Next, you will see partial workflow tools, which aggregate and leverage the single purpose tools (either directly, or by borrowing approaches). These put a UI on top of a number of solutions to make them more accessible to users. Again, these involve increased investment, and require additional capability (UX/UI design, more advanced desktop development).
Finally, you will see the emergence of full-scale workflow tools. These represent a major investment, generally require a team of specialists to create, and are built over the course of months or years. As such, they need to build on top of standards, approaches, and frameworks that have been well vetted by real-world use. Even then, their early releases will be limited, and will require a huge amount of community feedback and multiple revisions to “get it right”. With this in mind, early release with rapid iteration is a critical practice for any tool that aims to be successful in this space.
As an aside, code editors tend to follow an accelerated path, simply because the problems they are solving are less tied to a specific technology platform, and have been thoroughly explored for other languages.
Of course, none of these steps happen in isolation. In the JS world, you can see all of these underway simultaneously. There is an unending stream of new frameworks, as developers explore challenges, with a number of more mature ones gaining traction. There are a number of popular single-purpose tools (ex. LESS, Closure Compiler, Zoë). There are a few partial workflow tools (ex. CodeKit). And finally, there are a number of early entries in the more robust tool category (Edge, Sencha Animator, Flash Pro’s Wallaby, etc).
Further, this evolution is massively complicated and slowed in the HTML/JS world by the constant flux of the technology, the non-trivial issue of supporting multiple browsers/platforms, and the question of legacy support. Tool makers need to wait for a standard (or more frequently, a collection of standards) to stabilize and be broadly adopted/accepted before they can risk the investment to build on top of it.
This is obviously a simplified look at the problem, but hopefully helps illustrate where things are today, and why we don’t have access to fully mature tools for HTML5 development yet. They are coming, but it’s going to be an incremental process.
Hey Grant,
this is an interesting and frustrating discussion point. I completely agree with your analysis – but there’s one point that confuses me.
Javascript is not new – it was created 15 years ago (in the same year as JAVA) and became wide-spread at least 10 years ago. Considering this, shouldn’t we be at the last stage (“full-scale workflow tools”) of IDEs, tools and workflows for developing Javascript – at least at the same level of JAVA ? Or is the nature of Javascript making it too hard to be tooled around?
Just a thought… 🙂
João – I think there are two major factors here. The first is as you say, this technology stack is very dynamic (both the language, and the rate of platform change).
Perhaps more important though, is the fact that it is only in the past couple of years that there has been a broad interest in building large, complex projects using JS/HTML, which drive the need for these tools. Previously, most javascript use was limited to fairly simple use cases, so the effort to develop tools for such a dynamic platform wasn’t easily justified.
I agree there should be more advanced tools by this point, but JavaScript got hot only recently. And/or the language is too fast and loose for advanced tooling. I’m hopeful for Dart—it feels pretty good so far, but it’s too early to tell whether web developers will embrace it.
Hi Grant,
Given what you wrote, how do you grade Adobe on where they are in the progression?
It’s all understandable, but it’s sad to see years of IDE experience and evolution go to waste. It took Abobe years to get at the level Flash CS 5/6 is now, and we loose nearly all of it. I entered the Flash scene at version 4, and now we sort of depend on it to get a handle on rich authoring interactive multimedia content. Sometimes it feels like the HTML5 crowd is made up of people who’ve always abolished Flash and so know nothing about using and IDE for animating, easing, doing nested timelines, libraries and proper exporting options. In some circles it’s so not done to say anything good about Flash it’s sometimes not possible to consider it has anything to offer ‘them’, even though ‘we’ did everything HTML5 can offer for like 10 years now..
@Bart: Exactly my thoughts.
So what IDE/frameworks/tools do you guys use these days for building rich internet applications, mobile sites or apps. I know these are all different things, but I wonder: Is there one set of tools that stands out and that can be used for most projects? I preffer not to use other tools for every project (mobile, RIA, website, …).
Actually, Google has been building some pretty large apps in JavaScript for a while. But you can see the limitations of the language in the results. The Gmail UI is ugly, awkward and limited compared to Outlook or almost any other native PC/Mac client. Those limitations are undoubtedly the reason why Google is pursuing Dart. I have high hopes for Dart but it has high hurdles to get over, too.
One of the biggest problems with JavaScript, IMO, is that it’s interpreted. This means that a large class of problems that might be caught at compile-time cannot be detected in any IDE. Another major problem is its loose typing. Again, a large class of problems that go undetected until run-time. And then, even at run-time they’re hard to detect because JS just fails silently with whatever adverse side-efffects happen to occur. The inability to detect these types of bugs at compile-time leads to seriously reduced developer productivity as well as lower-quality web apps. I think serious web development will be hamstrung until there is a realistic (compiled, strictly typed) alternative to JavaScript.
I think the problem is that no one takes full responsibility for Javascript. Its a mish mash of people and no one perfects it. Thus you get a completely substandard development approach on the front end. You get the w3c community who have no clue on a real development environment because they refuse to accept upgrades into the javascript spec like classes or strong typing. Thus all of your HTML5 code is really just a band aid on a professional development environment. Sure we deal with it, but in reality it takes way longer to develop in js with a crappier product simply because the language itself is subpar.
Adobe takes complete ownership for Flash and all aspects of it. You cant say the same for javascript which really sucks. The closest solution I have seen is sencha.