Joe Hewitt : I'm an indie developer now.
joehewitt.com
joehewitt.com
At the same time, I'm always kind of bummed when those people are snapped up by a large company because their ability to produce the mind-binding ideas seems diminished or, at least, less visible among the many large accomplishments/events of a large company. Good to see that one of the lateral thinkers is returning to where we can more easily see his ideas in practice.
Firebug: I remember the first time I left behind the edit-save-refresh-cry-because-my-padding-was-wrong cycle of HTML/CSS development for the Firebug-driven-tweaks flow. Excellent.
With Stylebot when you make these kinds of tweaks it builds up a supplementary ruleset in a single location that you can afterwards copy and transfer to your CSS file. With Firebug it's relatively tricky to make sure you transfer all the tweaks you just did. Feature request. :)
Nah. You were on-topic (at least, on-topic for my off-topic bit...). Agreed. The Firebug-driven-tweak cycle ain't lovely, but it's positively gorgeous when compared to the old ways...
And thanks for the pointer to Stylebot. Checking it out now.
Firebug is pretty good for JavaScript and DOM. Chrome for profiling and the network.
I've enjoyed webstorm, and that add-in is really the icing on the cake.
edit: ... and then I read the next comment :)
I wonder if Joe Hewitt is not going to wait, and he will channel his energies into helping HTML5 catch the native app rocket ships. Go beyond Firebug.
[1] http://techcrunch.com/2010/04/30/joe-hewitt-web-development/
Can it? It feels like the browsers are slaves to their own success; what the web desperately needs to compete with native applications is the antithesis of what the web has become. To compete, the web would need:
- A runtime environment that can run complex applications -- including games -- with high performance on low-end mobile devices.
- Support for languages other than JavaScript, without having to compile to JavaScript (for why javascript is not an adequate compilation target, see above).
- A common, consistent, high-level application UI toolkit, with support for re-usable UI components. The seperation between HTML, CSS, and JavaScript is the wrong one. We need 'native' widgets rendered in canvas, using a coherent hierarchical view-based design -- not the DOM. You can build this on top of HTML/JS/CSS (see Obj-J/Cappuccino), but that's like saying that all turing complete languages are equal because they can emulate each other.
Any progress that a particular vendor might make (such as WebSockets, NaCL) will be held back by the other vendors (looking at you, Mozilla).
If you help the web catch up to modern native apps, you'll have just re-created native apps -- sandboxed, native code execution speed, coherent application libraries, etc...
Also, performance on the mobile space is a matter of waiting 2 or 3 years. Mobile perf is moving up fast, partly by browser revs and partly by better hardware. People used to say we needed something better than javascript and the dom on the desktop as well, and a few years of moore's law made that discussion irrelevant. Browser tech isn't bad enough to need replacing, so i don't see it getting replaced.
To compete, the web environment has to change drastically, but those that have invested in the web as it exists today don't want to change.
> Browser tech isn't bad enough to need replacing, so i don't see it getting replaced.
That's just the thing, though -- for applications, it is being replaced.
Back to mobile, the app stores make it way easier to ship native apps, and the browsers make it harder to deploy web apps. The consequence is that on mobile native still wins. The app stores may turn out to be better than the web for shipping apps. The web won't win that fight by making it easier to build better apps, it will only do so by making it easier to ship.
The web has the distribution problem solved, but as an application technology platform, it's horrible. Now that we've got a route forward with distribution of native apps, the native app market is growing by leaps and bounds, and it's the web that needs to catch up.
What I'd like to see is a common application platform, PNaCL based, with consistent high-level APIs .. but that would NOT be the web as we know it. It would be another native application platform.
If we were to use PNaCl, even once Google sorts out all the technical issues, in order to compete with native mobile apps, a whole ecosystem of toolkits and libraries will have to be created. That will take time, and we will see growing pains just like the ones we're seeing with mobile app frameworks for JavaScript.
Compare this to the status quo with JS. In two years, JavaScript will be as fast as NaCl for 90% of applications out there. Look at the speed of LuaJIT, which is the closest cousin to the modern JS engines, compared to C [1]. And this is on scientific number-crunching microbenchmarks! We don't have to throw away the lingua franca of the web in order to achieve good performance.
Let's look at the modern platforms:
- Microsoft is innovating heavily on the language front with C#, F#, and the CLR. I'm not a big fan of Microsoft's platforms, but there is no denying that they're doing very interesting work in language and runtime design.
- Google is innovating with Android, the Dalvik VM, and an application development framework not too much worse than Apple's. You have the NDK at your disposal, and many GL-based games can be ported without too much complexity from iOS. Numerous languages are being ported to the JVM, and are supported on Android.
- Apple is innovating with UIKit and high-level high-quality application development frameworks. Even if ObjC isn't particularly cutting edge, it's a reasonable solution for building large applications, it's fast enough, and you've got C at hand.
The browser makers, however, are fighting over whether or not WebSockets can actually be included in the browser; meanwhile, Apple rolled out GameKit support for automatic peer-to-peer session negotiation over bluetooth, wifi, and the internet to support multiplayer games.
The web as an application platform is broken, and will continue to be so as long as browser makers attempt to force everyone to stick to one language, lacking a standardized platform API, using a poor view model (DOM/HTML/CSS), stuck in the browser's limited sandbox.
I wrote this a few years ago on the exact same subject and advocated that a real VM plus application stack is required for the browser if it is to compete with native applications.
Even serious money: Microsoft's Developer Tools (Visual Studio) business made over $1B revenue last year: http://www.techflash.com/seattle/2010/07/microsofts_11_billi...
The second it came out, it personally started saving me hours of work every single week. If you multiply that by the number of people working with the web, damn, that's like millions of hours? Billions?
I think it was Vint Cerf who said something like: if you want to have the most profound effect on the world you can, rather than work on a particular problem, work on tools that help problems get solved and accelerate the process everywhere.
It would have been even more cool to work alongside the creator of firebug, though.
(Link to the status)
Joe's post made it quite clear that Facebook's management strategy is to provide freedom and autonomy, not handcuffs. This is one of the key reasons people love working there. The only thing Facebook is "squandering" is the opportunity to be experienced as a corporate financial prison.
The idea that any of this would be driven by Zuck's personal desire for liquidity is way off the mark.
Joe Hewitt hasn't worked for Facebook in years. This is old. Second, he wouldn't be eating ramen anyhow. Facebook bought his company for the employees (primarily him). He went on to make the iPhone facebook app, which has been wildly popular.