Its been a rough year (or two) in the tech industry, and conference budgets aren’t what they once were. Dustin Machi’s doing his bit to keep the Dojo community connected by starting a fully virtual set of conferences, the first of which will be dojo.connect.
I’ll be there virtually and I hope you can join us. The lineup is spectacular, and I can’t think of a more concentrated way to get in touch with the community short of becoming a committer.
Some folks have noticed a new landing page for dojotoolkit.org, one that includes hard numbers about the performance of Dojo vs. jQuery. Every library makes tradeoffs for speed in order to provide better APIs, but JavaScript toolkit performance shootouts obscure that reality more often than not. After all, there would hardly be a need for toolkits if the built in APIs were livable. Our new site isn’t arguing that Dojo gives you the fastest possible way to do each of the tasks in the benchmark, all we argue is that we provide the fastest implementation that you’ll love using.
I gathered the numbers and stand behind them, so let me quickly outline where they come from, why they’re fair, and why they matter to your app.
I took the average of three separate runs of the TaskSpeed benchmark in comparing the latest versions of both Dojo and jQuery. The numbers were collected on isolated VM’s on a system doing little else. You may not be able to reproduce the exact numbers, but across a similar set of runs, the relative timings should be representative.
So why is TaskSpeed a fair measuring stick? First, it does representative tasks and the runtime harness is calibrated to ensure statistically significant results. Secondly, the versions of the code for each library are written by the library authors themselves. The Dojo team contributed the Dojo versions of the baseline tasks and the jQuery team contributed theirs. If any library wants to take issue with the tests or the results, they only need to send Pete a patch. Lastly, the tests run in relative isolation in iframes. This isn’t bulletproof — GC interactions can do strange things and I’ve argued for longer runs — but it’s pretty good as these things go. I took averages of multiple runs in part to hedge against these problems.
The comparison to jQuery is fair on the basis of syntax and market share. If you compare the syntax used for Dojo’s tests with the jQuery versions, you’ll see that they’re similarly terse and provide analogous conveniences for DOM manipulation, but the Dojo versions lose the brevity race in a few places. That’s the price of speed, and TaskSpeed makes those design decisions clear. As for market share, I’ll let John do the talking. It would be foolish of me to suggest that we should be comparing Dojo to some other library without simultaneously suggesting that his market share numbers are wrong; and I doubt they are.
Given all of that, do the TaskSpeed numbers actually matter for application performance? I argue that they do for two reasons. First, TaskSpeed is explicitly designed to capture common-case web development tasks. You might argue that the weightings should be different (a discussion I’d like to see happen more openly), but it’s much harder to argue that the tests do things that real applications don’t. Because the toolkit teams contributed the test implementations, they provide a view to how developers should approach a task using a particular library. It’s also reasonable to suspect that they demonstrate the fastest way in each library to accomplish each task. It’s a benchmark, after all. This dynamic makes plain the tradeoffs between speed and convenience in API design, leaving you to make informed decisions based on the costs and benefits of convenience. The APIs, after all, are the mast your application will be lashed to.
I encourage you to go run the numbers for yourself, investigate each library’s contributed tests to get a sense for the syntax that each encourages, and get involved in making the benchmarks and the libraries better. That’s the approach that the Dojo team has taken, and one that continues to pay off for Dojo’s users in the form of deliberately designed APIs and tremendous performance.
I’ve been invited by Chris Messina and some kindly folks at MSFT to participate in a panel at this year’s SxSW regarding the value and/or necessity of view-source, and so with apologies to my fellow panelists, I want to get the conversation started early.
First, my position: ceteris paribus, view-source was necessary (but not sufficient) to make HTML the dominant application platform of our times. I also hold that it is under attack — not least of all from within — and that losing view-source poses a significant danger to the overall health of the web.
That’s a lot to hang on the shoulders of a relatively innocent design decision, and I don’t mean to imply that any system that has a view-source like feature will become dominant. But I do argue that it helps, particularly when coupled with complementary features like reliable parsing, semantic-ish markup, and plain-text content. Perhaps it’s moving the goal line a bit, but when I talk about the importance of view-source, I’m more often than not discussing these properties together.
To understand the importance of view-source, consider how people learn. Some evidence exists that even trained software engineers chose to work with copy-and-pasted example code. Participants in the linked study even expressed guilt over the copy-paste-tweak method of learning, but guilt didn’t change the dynamic: a blank slate and abstract documentation doesn’t facilitate learning nearly as well as poking at an example and feeling out the edges by doing. View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop. The only required equipment is a text editor and a web browser, tools that are free and work together instantly. That is to say, there’s no waiting between when you save the file to disk and when you can view the results. It’s just a ctrl-r away.
With that hyper-productive workflow as the background, view-source helps turn the entire web into a giant learning lab, and one that’s remarkably resilient to error and experimentation. See an interesting technique or layout? No one can tell you “no” to figuring out how it was done. Copy some of it, paste it into your document, and you’ll get something out the other side. Browsers recovering from errors gracefully create a welcome learning environment, free of the inadequacy that a compile failure tends to evoke. You can see what went wrong as often as not. The evolutionary advantages of reliable parsing have helped to ensure that strict XML content comprises roughly none of the web, a decade after it was recognized as “better” by world+dog. Even the most sophisticated (or broken) content is inspectable at the layout level and tools like Firebug and the Web Inspector accelerate the copy-paste-tweak cycle by inspecting dynamic content and allowing live changes without reloads, even on pages you don’t “own”. The predicate to these incredibly powerful tools is the textual, interpreted nature of HTML. There’s much more to say about this, but lets instead turn to the platform’s relative weaknesses as a way of understanding how view-source is easily omitted from competing technologies.
The first, and most obvious, downside to the open-by-default nature of the web is that it encourages multiple renderers. Combined with the ambiguities of reliable parsing and semantics that leave room for interpretation, it’s no wonder that web developers struggle through incompatibilities. In a world where individual users each need to be convinced to upgrade to the newest version of even a single renderer, differences only in version can wreak havoc in the development process. Things that work in one place may not look exactly the same in another. This is both a strength and a weakness for the platform, but at the level of sophisticated applications, it’s squarely a liability. Next, ambiguities in interpretation and semantics mean that the project of creating tooling for the platform is significantly more complex. If only one viewer is prevalent (for whatever reason), then tools only need to consume and generate code that understands the constraints, quirks, and performance of a single runtime. Alternate forms of this simplification include only allowing code (not markup) so as to eliminate parsing ambiguity. The code-not-markup approach yields a potentially more flexible platform and one that can begin to execute content more quickly (as Flash does). These advantages, taken together, can create an incredibly productive environment for experts in the tools that generate content: no output ambiguity, better performance, and tools that can deliver true WYSIWYG authoring. These tools can sidestep the ctrl-r cycle entirely.
But wait, I hear you shout, It’s possible to do code-only, toolable, full fidelity development in JavaScript! Tools like GWT and Cappuccino generate code that generates UI, ensuring that only those who can write code or have tools that can will participate; removing the potential value of view-source for those apps. But lets be honest: view source is nearly never locally beneficial. I can hardly count the number of times I’ve seen the “how do I hide my code?” question from a web n00b who (rightly or wrongly) imagines there’s value in it. For GWT the fact that the output is an HTML DOM that’s styled with CSS is as much annoyance as benefit. The big upside is that browsers are the dominant platform and you don’t have to convince users to install some new runtime.
Similarly Flex, Laszlo, GWT’s UI Binder, and Silverlight have discovered the value in markup as a simple declarative way for developers to understand the hierarchical relationships between components, but they correspond to completely unambiguous definitions of components they rely on compiled code — not reliably parsed markup — for final delivery of the UI. These tight contracts turn into an evolutionary straightjacket. Great if you’re shipping compiled code down the wire that can meet the contract, but death if those tags and attributes are designed to live for long periods of time or across multiple implementations. You might be able to bolt view-source into the output, but it’ll always be optional and ad-hoc, features that work against it being pervasive. Put another way, the markup versions of these systems are leaky abstractions on the precise, code-centric system that under-girds both the authoring and runtime environments. This code-centric bias is incredibly powerful for toolmakers and “real” developers, but it cuts out others entirely; namely those who won’t “learn to program” or who want to build tools that inject content into the delivery format.
Whatever the strengths of code-based UI systems, they throw web crawlers for a loop. Today, most search engines deal best with text-based formats, and those search engines help make content more valuable in aggregate than it is on its own. Perhaps it’s inevitable that crawlers and search engines will need to execute code in order to understand the value of content, but I remain unconvinced. As a thought experiment, consider a web constructed entirely of Flash content. Given that Flash bytecode lacks a standard, semantic way to denote a relationship between bits of Flash content, what parts of the web wouldn’t have been built? What bits of your work would you do differently? What would the process be? There’s an alternate path forward that suggests that we can upgrade the coarse semantics of the web to deal with ever-more-sophisticated content requirements. Or put another way, use the features of today’s toolkits and code generators as a TODO list for markup driven features. But the jury is still out on the viability that approach; the same dynamic that makes multiple renderers possible ensures that getting them to move in a coordinated way is much harder than the unilateral feature roadmap that plugin vendors enjoy. HTML 5 and CSS 3 work is restarting those efforts, but only time will tell if we can put down the code and pick markup back up as a means to express ourselves.
I’ve glossed over a lot of details here, and I haven’t discussed implications for the server side of a non-text format as our lingua-franca, nor have I dug into the evolution metaphor. Many of the arguments are likewise conditional on economic assumptions. There’s lots of discussion yet to have, so if you’ve got links to concrete research in either direction or have an experience that bears on the debate post in the comments! Hopefully my fellow panelists will respond in blog form and I’ll update this post when they do.
It’s that time of year again….and this year OSCON is back in Portland! The deadline for submitting your talk is Feb 1st, so if you’ve been building or learning awesome Open Source technology, don’t hesitate to get your proposal in. Remember that the process is competitive, so write your proposal with an eye toward what works and make sure to get it in before the deadline. Good luck!
Thank you for covering the browser market. Many users don’t understand that they have a choice of browser and by discussing the alternatives you help promote a healthy ecosystem and honest competition. In covering this important topic it’s easy to be loose with terms, but some shortcuts cross a bridge too far. A few are listed here here along with a rubric to help you understand why they make you (and your esteemed publication) seem less interested in hard facts than I’m sure you are.
Acceptable alternatives: “javascript execution”, “javascript performance”, “DOM rendering” (but only when discussing things that measure DOM performance).
What you need to know is that there is an emerging class of things that users can install into their browsers which are similarly magical but which are not plugins. These things go by different names: “extensions”, “add-ons”, and (confusingly) “toolbars”. I’m sure there will be others. You can think of these things as being interchangeable with each other but not with “plugins”. So how do you tell which is which? A good rule of thumb is that if a web page works fine without you installing it, it’s an extension. Otherwise, if you need to install something for the page to work, it’s a plugin.
Acceptable alternatives: “extensions” (preferred), “add-ons”, “toolbars” (overly specific, may confuse).
Regards,
Alex Russell
Of all the exciting stuff that’s happening at Google, one of the things I’ve been most excited about is SPDY, Mike Belshe and Roberto Peon’s new protocol that upgrades HTTP to deal with many of the new use-cases that have strained browsers and web servers in the last couple of years.
There are some obvious advantages to SPDY; header compression means that things like cookies get gzipped, not just content, and mutliplexing over a single connection with priority information will allow clients and servers to cooperate to accelerate page layout based on what’s important, not only what got requested first.
But the the really interesting stuff from my perspective is the way SPDY enables server push both for anticipated content and for handling Comet-style workloads. The first bit is likely to have the largest impact for the largest set of apps. Instead of trying to do things like embed images in data: URLs — which punishes content by making it uncacheable — SPDY allows the server to anticipate that the client will need some resource and preemptively begin sending it without changing the HTTP-level semantics of the request/response. The result is that even for non-cached requests, many fewer full round trips are required when servers are savvy about what the client will be asking for. Another way to think about it is that it allows the server to help pre-fill an empty cache. Application servers like RoR and Django can know enough about what resources a page is likely to require to begin sending them preemptively in a SPDY-enabled environment. The results in terms of how we optimize apps are nothing short of stunning. Today we work hard to tell browsers as early as possible that they’ll need some chunk of CSS (per Steve’s findings) and try to structure our JavaScript so that it starts up late in the game because the penalty for waiting on JS is so severe (blocked rendering, etc.). At the very edge of the envelope, this often means inlining CSS and accepting the penalty of not being able to cache for things that should likely be reusable across pages. On most sites, the next page looks a lot like the previous one, after all. When implemented well, SPDY will buy us a way out of this conundrum.
And then there are the implications for Comet workloads. First, SPDY multiplexes. One socket, many requests. Statefully. By default. Awwwww yeah. That means that a client that wants to hang on to an HTTP connection (long polling, “hanging GET”, <term of the week here>) isn’t penalized at the server since SPDY servers are expected to be handling stateful, long-lived connections. At an architectural level, SPDY forces the issue. No one will be fielding a SPDY server that doesn’t handle Comet workloads out of the box because it’ll often be harder to do so than not. SPDY finally brings servers into architectural alignment with how many clients want to use them.
Beyond that, SPDY allows clients to set priority information, meaning that real-time information that’s likely to be small in size can take precedence on the wire over a large image request. Similarly, because it multiplexes, SPDY could be used as an encapsulation format for WebSockets, allowing one TCP socket to service multiple WebSockets. The efficiency gains here are pretty obvious: less TCP overhead and lowered potential for unintentional DoS (think portals with tons of widgets all making socket requests). There’s going to need to be some further discussion about how to make new ideas like WebSockets work over SPDY, but the direction is both clear and promising. SPDY should enable a faster web both now and in the future.
So from time to time I’d wondered what all the brilliant DHTML hackers that Google had hired were up to. Obviously, building products. Sure. But I knew these guys. They do infrastructure, not just kludges and one-off’s. You don’t build a product like Gmail and have no significant UI infrastructure to show for it.
Today they flung the doors open on Closure and it’s supporting compiler. These tools evolved together, and it shows. Closure code eschews many of the space-saving shortcuts that Dojo code employs because the compiler is so sophisticated that it can shorten nearly all variables, eliminate dead code, and even do type inference (based on JSDoc comments and static analysis).
There’s a ton of great code in Closure, so go give the docs a look and, if you’re into that kind of thing, read the official blog post for a sense of what makes Closure so awesome.
It’s interesting to me how much it feels like a more advanced version of Dojo in many ways. There’s a familiar package system, the widgets are significantly more mature, and Julie and Ojan’s Editor component rocks. The APIs will feel familiar (if verbose) to Dojo users, the class hierarchies seem natural, and Closure even uses Acme, the Dojo CSS selector engine. It’s impressive work and congrats are in order for Arv, Dan, Emil, Attila, Nick, Julie, Ojan, and everyone else who worked so hard to build such an impressive system and fight to get it Open Source’d.
PPK posted some great new compat tables for various flavors of WebKit-based browsers the other day, editorializing that:
…Acid 3 scores range from a complete fail to 100 out of 100.
This is not consistency; it’s thinly veiled chaos.
But I’m not convinced that the situation is nearly that bad.
The data doesn’t reflect how fast the mobile market changes. The traditional difference between mobile and desktop, after all, has been that mobile is moving at all. If you figure a conservative 24 month average replacement cycle for smartphones, then the entire market for browsers turns over every two years. And that’s the historical view. An increasing percentage of smartphone owners now receive regular software updates that provide new browsers even faster. What matters then is how old the WebKit version in a particular firmware is and how prevalant that firmware is in the real world. As usual, distribution and market share are what matters in determining real-world compatibility, and if that’s a constantly changing secnario, the data should at least reflect how things are changing.
So what if we add a column to represent the vintage of the tested WebKit versions? Here’s a slightly re-formatted version of PPK’s summary data, separated by desktop/mobile and including rough WebKit vintages (corrections and new data much appreciated if you happen to know!):
| Browser | Score (max 216) | Vintage |
|---|---|---|
| Safari 4.0 | 204 | 2009 |
| Chrome 3 | 192 | 2009 |
| Chrome 2 | 188 | Early 2009 |
| Safari 3.1 | 159 | 2008 |
| Chrome 1 | 153 | Early 2008 |
| Safari 3.0 | 108 | 2007 |
| Konqueror 3.5.7 | 103 | 2007 |
| Konqueror (newer, untested) | 0 | ?? |
| Browser | Score (max 216) | Vintage |
|---|---|---|
| Ozone (version?) | 185 | (?) Late 2009 |
| iPhone 3.1 | 172 | 2009 |
| Iris (version?) | 163 | (??) 2008 |
| JIL Emulator (version?) | 162 | ?? |
| Bolt (version?) | 155 | ?? |
| iPhone 2.2 | 152 | 2008 |
| Android G2 (version? 1.6?) | 144 | (??) Late 2008 |
| Palm Pre (version?) | 134 | ?? |
| Android G1 (1.5?) | 108 | (??) 2008 |
| Series 60 v5 | 93 | (??) 2008 |
| Series 60 v3 (feature pack?) | 45 | 2005 |
PPKs data is missing some other columns too, namely a rough estimate of the percent of mobile handsets running a particular version, rates of change in that landscape over the past 18 months, and whether or not these browsers are on the whole better than the deployed fleet of desktop browsers. Considering that web devs today still can’t target everything in Acid2, knowing how the mobile world compares to desktops will provide some much-needed context for these valuable tables. Perhaps those are things that we as a community can chip in to help provide.
Even without all of that, just adding the rough vintages adds an arc to the story; one that’s not nearly so glum and dreary. What we can see is that newer versions of WebKit are much more capable and compatible, even at the edges. None of PPK’s data yet tests where the baseline is, so remember that the numbers presented mostly describe new-ish features on the platform. We also see clearly that the constraints of the mobile environment force some compromises vs. desktop browsers of the same lineage. This is all in line with what I’d expect from a world where:
The important takeaway for web developers in all of this is that WebKit is winning and that that is a good thing. The dynamics of the marketplace have thus far ensured that we don’t get “stuck” the way we did on the desktop. That is real progress.
Where do we go from here? Given that the mobile marketplace is changing at a rate that’s nearly unheard of on the desktop, I think that when new charts and comparisons are made, we’ll need to couch them in terms of “how does this affect the difference in capabilities across the deployed base”, rather than simply looking at instantaneous features. Mobile users are at once more likely tied to their OSes choice of browser and more likely to get a better browser sooner. That combination defies how we think about desktop browsers, so we’ll need to add more context to get a reasonable view of the mobile world.
Somehow I got out of sync with everyone else in the local distcc cluster at work. How? Weirdly, the XCode settings showed that while there were plenty of peers around to build with, they were all slightly off (har) in their OS version number, and therefore returned the dreaded “Incompatible Service”.
Some googling revealed that Apple shipped two 10.5.8’s!. A regular software-update won’t trigger the required update, either. Luckily, re-applying the stand-alone updater got me up to 9l31a, and I can once again abuse my co-worker’s CPUs instead of my own. Phew!
I’ve been so busy with with work and such that I totally forgot to mention that tomorrow, Sept 10th there will be a Dojo Developer Day in Mountain View, generously hosted by AOL.
Come for the whole day, drop by for a bit, or just join us for dinner/drinks afterward. In the ramp up to 1.4, there’s some great engineering happening in nearly every area of the toolkit, including some great new visual improvements that I expect to see and hear a lot about tomorrow.
As usual, folks will be on IRC throughout the day should you not be able to join us in person, and in a first, we’ll have a live feed of the event going.
Hope you can join us!
Since you do not believe that health insurance should always be available via large-group policy to the vast majority of Americans, and since you seem to believe that the individual insurance market functions well, I believe it is only proper for you to buy insurance in the individual market.
As a taxpayer, I’m sure you’re as galled as I am that we’re continuing to insure America’s Senators through a nearly socialist system, and while you haven’t yet discovered the presence of mind to submit legislation to end this objectionable practice and free all of America’s Senators from the yoke of tyranny, you can personally act to see this deeply un-’merican policy corrected. In short, I urge you to find the courage of your convictions and put your health where our money is.
I recognize that legislating in good faith is no longer “on the table” for you. It has to be hard being the party of “no”, never having anything constructive to offer — never being asked to think independently about anything — but this is something that you can do for your country. A contract with America, if you will. Or if not with America, a contract with an individual insurer in the greater District of Columbia and/or your home state…anyway, you get the idea. It’d be a contract for America at the very least.
On this Labor Day, I urge you to do the right thing. Join your constituents and say, with one voice, “what do you mean you won’t cover Timmy’s ear infection? He was just born! How can that be pre-existing!?!” This is “rugged individualism” at its finest. Just you against the private-sector Man. The way it should be.
True, this won’t be a 1:1 comparison since you’re in the top 3% of all earners. But don’t worry, you’ll soon find that you can’t afford the coverage you’re currently enjoying when you buy in the individual market. Your new, terrible, and terribly expensive insurance will doubtless give you the flavor of what the rest of us experience.
Ingeniously, this plan doesn’t even require that you do anything constructive toward health care reform. You can keep stiffing both your country and your constituents and you won’t have to hold any of those awkward “town hall” meetings to explain yourself. After all, this is the fiscally conservative thing to do; you’ll be saving taxpayers money, and who can argue with that?
Pretty soon, you might even be able to find the courage to do what your instincts — and terrible economics — tell you to do: advocate that our retirees buy in the individual market too! Once you discover how great the individual market is, you shouldn’t have any qualms in making the case that everyone should join it. Just think how many people you’ll be able to lift out of the oppressive regime of socialized insurance. The elderly will surely make their thanks known at the ballot box. As someone who’s most likely “getting up there” yourself, you’ll have added credibility on the issue…and seriously, when was the last time you had credibility? This is political gold.
You can even continue to play the part of hostage to broken, antiquated economics if it suits you (and your major campaign contributors, ‘natch).
It’s the very least you can do for your country, and for your (tiny) efforts you’ll be set on a personal journey of discovery. You’ve never seen the pain and burning anger caused by “pre-existing condition” denials for things that are laughably routine. You’ve never wondered in awe at how large a deductible you were suckered into, and you’ve probably never had a plan with a lifetime cap on benefits; so when you really need them, they won’t be there. In fact, I suspect that you have never considered that the majority of us don’t even have actual health insurance.
By buying in the individual market, you can set an example. This is your chance to be a real pioneer! This could even be your first step towards representing a growing constituency — something you Republicans have been searching for: those who have gone bankrupt under a mountain of medical bills because they had the temerity to get sick before they turned 65. Those folks might not have wealth, they might not even have their health, but they sure-as-hell are voters. Just think, you can get in on the ground floor of that action!
Yes, dear Senator, by simply finding your moral compass (you’ve got it back there somewhere, even if you haven’t used it in a while) and following it for just one step, you can help us right this great nation again and return it to glory. I urge you to do this thing for your country, follow your ideology, and deny yourself the kind of care that you’ve worked so hard to deny the rest of us. It’s the Right thing to do, after all.
Sincerely,
Alex Russell
Then please do yourself and your family a favor and read this piece by T.R. Reid on how health care in the rest of the world actually works (hint: better, cheaper, faster).
It distresses me that our health-care debate has been launched from false premises and has deteriorated from there. We cannot ignore the ongoing harm being done, cannot deny that others are doing it better (across the board), and must not succumb to the false equivalencies and misdirections being vacuously peddled. Now is the time to arm yourself against the tragedy of ideology with real, observable facts.
I spend my days in C++ on 32-bit Windows XP in Visual Studio 2005. The build and link times for Chromium are painful on this setup, in part because there has been flakiness with the multi-process build option for VS, in part because the incremental linker which can dramatically speed up builds can run out of memory on some boxes (so is disabled by default), and because Visual Studio steadfastly refuses to give developers any options about how, when, where, and why to rebuild the IntelliSense database. The last one is probably the most intractable. On 64-bit windows, incremental linking is turned on based on the assumption that you’ll have lots of RAM on that shiny 64-bit box. Similarly, Chromium builds using multi-process flags under VS’08 since it’s known to be less flaky there. It seems I run with the “please hurt me more” configuration.
“Distributed builds!”, I hear you scream.
That’s not a bad path. For Mac builds, the office’s ad-hoc distcc cluster is a godsend (particularly given that my Mac is a lowly laptop). For Visual Studio, there’s IncrediBuild, but it has left me wanting a better option. Recently I’ve just thrown caution to the wind and started over-riding the safety valves on /MP and incremental linking via my ~/.gyp/include.gypi file:
{ 'variables': { 'msvs_multi_core_compile': 1, 'msvs_large_module_debug_link_mode': '2' } }
You can get these settings to take effect without updating your repo by running gclient runhooks --force from the top level directory if your Chromium checkout. VS should then prompt you to reload the project (assuming you’re using the GUI).
Hopefully this recipe will help others. It has dropped small rebuilds on my system from north of 10 minutes to below 2.
Update: So the real answer, apparently, is to get dual quad-core i7’s running Vista 64 under VS 2008. Holy cow, what a world of difference. All hail the Powers That Be for new, awesome hardware!
I’ve been in a pretty heated email conversation over the past couple of days regarding how effective (or not) the CSS Working Group has been. I’ve been pretty brutal in my critique in the past (and much of it still stands), but there’s reason to hope.
The best bits are — not surprisingly — being driven by the implementers. Apple is in the driver’s seat, with major contributions for Animations (including keyframes!), 2D Transforms, 3D Tranforms, and Transitions. Great stuff.
Similarly, David Baron (of Mozilla fame) is editing a long-overdue but totally awesome Flexible Box spec, aka: “hbox and vbox”. Both Gecko and WebKit-derived browsers (read: everything that’s not IE) supports hbox and vbox today, but using it can be a bit tedious. Should you be working on an app that can ignore IE (say, for a mobile phone), this should help make box layouts a bit easier to get started with:
/* hbox and vbox classes */ .hbox { display: -webkit-box; -webkit-box-orient: horizontal; -webkit-box-align: stretch; display: -moz-box; -moz-box-orient: horizontal; -moz-box-align: stretch; display: box; box-orient: horizontal; box-align: stretch; } .hbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; } .vbox { display: -webkit-box; -webkit-box-orient: vertical; -webkit-box-align: stretch; display: -moz-box; -moz-box-orient: vertical; -moz-box-align: stretch; display: box; box-orient: vertical; box-align: stretch; } .vbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; } .spacer { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; } .reverse { -webkit-box-direction: reverse; -moz-box-direction: reverse; box-direction: reverse; } .boxFlex0 { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; } .boxFlex1, .boxFlex { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; } .boxFlex2 { -webkit-box-flex: 2; -moz-box-flex: 2; box-flex: 2; } .boxGroup1 { -webkit-box-flex-group: 1; -moz-box-flex-group: 1; box-flex-group: 1; } .boxGroup2 { -webkit-box-flex-group: 2; -moz-box-flex-group: 2; box-flex-group: 2; } .start { -webkit-box-pack: start; -moz-box-pack: start; box-pack: start; } .end { -webkit-box-pack: end; -moz-box-pack: end; box-pack: end; } .center { -webkit-box-pack: center; -moz-box-pack: center; box-pack: center; }
I’ve been using these rules for some time to good effect. You can use them to easily visually center things (for example):
1 2 3 4 5 6 | <div class="hbox center"> <div class="vbox center"> <div>...</div> <div>...</div> </div> </div> |
Or you can use grouping to get nicer form layouts:
1 2 3 4 5 6 7 8 9 10 11 | <form action="handler.cgi" method="POST" class="hbox"> <div class="vbox"> <label>First Name (required):</label> <label>Last Name:</label> </div> <div class="vbox"> <input type="text" name="first"/> <input type="text" name="last"/> <input type="submit"/> </div> </form> |
It’s unfortunate that this stuff is “medium priority”, but at least it’s moving forward in the WG.
Update: Fixed the examples and rules to use box-pack: center;, per Dave Hyatt’s excellent suggestion!
