22

What's the best framework (sort of jquery, extjs, etc like) to use if I'd like to intensively use all the freshest technologies of the HTML5 stack provided by modern browsers (Firefox 7, Safari 5, Chrome 14) and have absolutely no need to support any legacy browsers (incl. no need in IE support at all and no need in Firefox or Chrome prior to the latest stable releases)? I'd like to get all the newest available goodness without having (even abstracted by a library layer) a line of code meant just fore legacy compatibility or keeping any legacy-induced things in mind.

To soften the filter, taking very humble hope of such an ideally fresh framework to exist, the least (the maximum level of legacy support) I'd like to agree is not supporting IE versions older than IE8, or better just not supporting IE at all.

Ivan
  • 63,011
  • 101
  • 250
  • 382
  • 17
    I don't believe such a library exists. For most of us poor slobs that don't live in ivory towers, dealing with legacy browsers is still the order of the day. – Robert Harvey May 19 '10 at 03:52
  • 1
    I believe jQuery aims to include as little browser-specific code as possible. It's true they have many IE workarounds, but they try to keep them to a minimum – Michael Haren May 19 '10 at 04:09
  • 1
    @Robert Harvey: You sound a bit bitter about having to support IE6. ;) – Esteban Araya May 19 '10 at 04:09
  • You'd think it plausible somebody somewhere has created a reference implementation without all the legacy cruft, although that might not be a speedy implementation. Then again the browser crowd usually drives innovation and has many features of the standards implemented even before they become standards! – John K May 19 '10 at 04:10
  • @Esteban: I've got it easy; I only have to support IE7+ and the latest version of Firefox, and IE7 should be going away soon, as my particular user domain has a minimum browser standard they must adhere to. Chrome shouldn't be much of a problem, either. Life is good. – Robert Harvey May 19 '10 at 04:23
  • I'd imagine such a library would be difficult to maintain at this point in time. With the HTML5 spec subject to change and browsers implementing some features in varying ways, such a library would have to be constantly updated. I'd be quite interested in such a project though, perhaps even enough to scrounge up some extra time and get involved in one. – Scott Christopherson May 19 '10 at 04:31
  • 3
    Framework or library? If you don't have to abstract away legacy browsers, you'd be more or less left with a library of shortcut methods for working with web standard APIs - and they're pretty easy to write (eg. add/removeClass). I guess your application spec could drive what you need the library to do. Start with plain old library free JavaScript? – Dean Burge May 19 '10 at 04:41
  • Huh, looking on how this my question grows in rating, seems the demand for such a thing is high, while no offer out there... – Ivan May 19 '10 at 05:28

5 Answers5

4

I am really having a hard time reconciling this idea after a serious thought. Assuming such a framework exists, it would only be as good as the current implementation status in any one browser. Let's say there are only two browsers and the HTML5 implementation status looks like this:

Browser | Feature X | Feature Y
-------------------------------
 A      | ✔         | ✘
 B      | ✘         | ✔

Then your most bleeding-edge HTML5 application can either have X or Y, but not both. If the features your application needs are available on the latest versions of most major browsers, then that feature is not bleeding-edge. It would have been bleeding-edge a year ago.

So depending on the project scope and goals, the most B-E application that can be written will conform to a single browser (the one that offers all/most of the features needed for your application).

If you're writing for a lone browser and do not want to fix any implementations deviations from the spec (as the spec is not yet finalized), then it's basically writing code for that chosen browser regardless of any specs.

If that is the case, then a framework is basically extra baggage to carry around. Instead, shortcuts for most commonly used APIs and other general simplifications would be the best way to go.

That said, if you're goal is to have a framework that vastly simplifies the HTML5 APIs oblivious of where the browsers stand today, then I would love to contribute towards that project.

Anurag
  • 140,337
  • 36
  • 221
  • 257
  • If we go back from A&B to real world, we can see that we've got many more "major browsers": IE6, IE7, IE8, IE9 soon, Webkit-based Chrome and Safari, Mozilla Firefox (taking only major milestones) 2, 3, 3.6, 3.7. A set I call "modern browsers" consisting of Firefox 3.6+, Chrome 4+, Safari 4+, and Opera 10 very close have got significant set of common (or slightly differently implemented) features which even IE9 is still far away from, not to say about IE 7 and 6 and Firefox 2, for example. – Ivan May 19 '10 at 12:53
  • 2
    And as far as I see, it is nod hard today to convince a user to consider using a "modern browser" of his choice if he is specifically interested in our application features. So supporting legacy browsers, I think, can be really needed only on public mass-oriented traffic-driven websites and very large unflexible enterprises, while non-profit community (especially those made for tech enthusiasts) projects and enterprise intranets can enjoy all the goodness of modern browsers. – Ivan May 19 '10 at 12:58
  • I totally agree, and it's always good to start with that mindset without the fear of losing out users, especially for niche websites where the audience is open to the idea of installing something on their computer and knows how to do that. But even in niche sites, if users get accustomed to viewing your site on IE7, and you later drop the bomb on it, they are going to be pissed off because that's just the nature of things - nobody likes change. Instead, if users are constantly informed that support for a particular browser will be dropped if the browser starts going out of line. – Anurag May 19 '10 at 19:31
  • StackOverflow itself is a great example. They're using `` for graphing reps. Don't know if they offer a graphic image or flash version for browsers that don't support ``. But if anyone in this community does not already use a modern browser and/or is not willing to upgrade to one, then they have no business being here. – Anurag May 19 '10 at 19:35
2

Sproutcore is another one that sort of fits your opening description "How do we build blazingly fast, desktop-class web applications?". Apple are interested in it and i have heard good reports.

Another approach would be Apples Dashcode. It use html(5) css(3) and JavaScript to build both Mac Widgets but also Web based sites. Essentially because it has little or no legacy it will only run effectively in Safari and Google Chrome, less that effectively in Firefox and not at all in IE.

To use Cappuccino (mentioned in another answer and a good idea to look at) and Sproutcore you you will be more productive on a Mac and Dashcode definitely needs a Mac as you will need to install Xcode to get Dashcode

PurplePilot
  • 6,652
  • 7
  • 36
  • 42
1

What about Cappuccino? I don't really know how much HTML5/CSS3 it supports, but it requires IE7 at minimum. It is focused on web app development, not site-building, so it may not be what you're looking for in that regard.

Em McDonald
  • 198
  • 9
1

See:

Modernizr

Sarfraz
  • 377,238
  • 77
  • 533
  • 578
0

Not exactly an answer, but I think this will be beneficial for the discussion:

GWT's approach (cross-compiling Java to JavaScript with deferred binding) is in line with your point about getting the minimal amount of JS code, without the burden of making all the browser abstractions in client side code, and carrying around all the weight of that code plus the weight of legacy browser support code.

I'm not sure if the current level of granularity by which it produces optimized per-browser versions is the one you're talking about, but the technology enables it.

Also, not sure about out-of-the-box bleeding edge HTML 5 feature support, but again - one could write such libraries (if they're not there already), and they will benefit from the same deferred binding mechanism, and you can compile just for the browser permutations you want to support.

ob1
  • 1,721
  • 10
  • 25