It's always exciting to bump into, meet or find out about someone who can see interesting possibilities where others see nothing. I don't know Joe, but he seems like one of those people (Firebug, FTW!).
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.
Re 'Firebug-driven-tweaks flow' [Sorry if this is OT]
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. :)
Making it easy to save Firebug CSS changes back to the source file was at the top of my todo list in 2007, and I was really bummed that I didn't get the chance to build it. Years later the Backfire extension came out, which does alleviate some of the pain of saving CSS, but I still think there's room for improvement.
For the line of JetBrains IDE (PyCharm, IntelliJ, PhPStorm), there is a wonderful plugin, called css-x-fire that allows to save all tweaks you did in Firebug back to your source file. It gave me hours of life back.... I bet there exist something similar for lots of IDE.
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.
"I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait." -Joe Hewitt [1]
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.
... helping HTML5 catch the native app rocket ships.
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...
There is one huge company, whose name start with g, highly interested in all of the above (they want to make a web apps based os). but seems like they have lacked the inspiration, or...
mm.... maybe they are quietly doing it right now, with NaCl
That doesnt change the fact that mozilla isnt interested in NaCl, which is sad because it could enable alot of cool stuff, especially in regards to games and realtime apps.
There are already a few consistent ui toolkits, even with visual designers. Ext js for example. I've developed desktop apps, and building ext js apps isn't far off from that experience anymore. Maybe it would help if we could get the various javascript frameworks to agree on a component spec.
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.
This is why the modern native application environments are winning, and the web isn't: "There are already _a few_consistent ui toolkits" "isn't far off", "maybe it would help," "matter of waiting 2 or 3 years" ...
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.
PNaCl is more than two years away from mainstream adoption though. The system is huge and complex due to the fact that it stretches LLVM far beyond what it was meant to handle. For example, LLVM was never designed to have platform-independent bitcode; to make it work they basically had to find ways to make the x86 data layout sorta work for all platforms. Additionally, LLVM bitcode is huge; it was designed to be an intermediate language for compilers, not a packaging mechanism for application distribution.
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.
If PNaCL or similar can't be leveraged, then the web won't keep up as an app platform.
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.
My "in three years" remark was meant to indicate when the web model's downsides will become irrelevant. But i think the web is winning right now. The desktop is going webbased faster and faster. It doesn't seem so if you look at games and media software, yet, but in the enterprise market you're laughed out of the room if you don't have a web app. Native apps lost that fight a while ago. They lost for a simple reason: the deployment model is superior, and the app quality of web apps was good enough.
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.
We're talking about the modern landscape of native applications -- iOS, Android -- in which apps certainly have not "lost". The legacy desktop application distribution model you're referencing -- one in which a toolbar can spy on you -- is fading away.
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.
There is definitely an opportunity to create an amazing HTML5 IDE, but I also think that smaller and more focused tools have value. I intend to avoid the temptation to try and boil the ocean so that I can actually ship something useful this year.
It sometimes seems it's difficult to make money from making tools, because developers expect them for free, and with source (like Firebug). But of course it is possible, with products like Joel's FogBugz, like Jira and some IDE's.
Microsoft makes money on its development tools because a huge percentage of the world's biggest organizations are its clients. If you try a startup development tool, especially a non-canonical (VS might as well be required for .NET development) tool, good luck making anything close to that number within 5-10 years.
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.
I have no idea what Joe's option situation is, but supposing that he's cashing them in and dumping them in the secondary market it goes to show that Facebook is squandering the employee lock-in advantage of having pre-IPO stock. It's probably in Facebook's interest to shut down the secondary market, but I imagine zuck and co like being somewhat liquid for personal reasons.
If your goal is to have people doing creative, innovative work, then I would strongly disagree that there is any advantage whatsoever to be derived from making people feel "locked in." In practice, I have only seen this achieve the opposite effect -- disengaged people hanging around longer than they should and poisoning the atmosphere for passion-driven folks around them.
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.
Being able to work on small teams on interesting projects that reach 100s of millions of users and get paid reasonably well is sufficient incentive to work for Facebook I should think.
They may have already written off the employee lock-in effect and are taking their time going public just to avoid the disclosure and compliance hassles associated with it.
I'd love to work with this guy. Wonder if he's up for a position with a small team of craftsmen... (yeah, we're actually hiring, if anyone is interesting in working out of a small office in Carlsbad, CA!)
>Working at Facebook was like having my own startup, but with a paycheck instead of ramen
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.
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.