Key Web App Standard Approaches Consensus

suraj.sun tips a report up at CNet which begins: "Browser makers, grappling with outmoded technology and a vision to rebuild the Web as a foundation for applications, have begun converging on a seemingly basic but very important element of cloud computing. That ability is called local storage, and the new mechanism is called Indexed DB. Indexed DB, proposed by Oracle and initially called WebSimpleDB, is largely just a prototype at this stage, not something Web programmers can use yet. But already it's won endorsements from Microsoft, Mozilla, and Google, and together, Internet Explorer, Firefox, and Chrome account for more than 90 percent of the usage on the Net today. 'Indexed DB is interesting to both Firefox and Microsoft, so if we get to the point where we prototype it and want to ship it, it will have very wide availability,' said Chris Blizzard, director of evangelism for Mozilla. ... Microsoft publicly endorsed Indexed DB on its IE blog: 'Together with Mozilla, we're excited about a new design for local storage called Indexed DB. We think this is a great solution for the Web,' said program manager Adrian Bateman."

Comments

Golden age of the web set to continue

[levell]

Personally the new web technology that I'm most keen to get my hands on is the pushState/replaceState stuff that is going to be in the next release of Firefox after 3.6. It makes it much easier to deal with forward/back in AJAX web apps

More on topic, it is good to see Microsoft looking to implement new web technologies again.... if they implement much of HTML5 and they seem to be doing that now and this new Indexed DB stuff it looks like the Golden Age of the web will continue for some time.

Re:Golden age of the web set to continue

[John Hasler]

> ...it looks like the Golden Age of the web will continue...

Provided that your definition of a Golden Age includes many new and exciting exploits.

Re:Golden age of the web set to continue

[girlintraining]

it looks like the Golden Age of the web will continue for some time.

Dude, the web didn't even exist until about 18 years ago. We're still evaluating the impact that the internet is having on culture -- what with some countries defining it as an inalienable human right and others eager to all but destroy or censor the crap out of it, the "golden age" is not what I'd call this time period. I'd call it the friggin' dark ages -- a mish-mash of global entities all competing at cross-purposes, a thriving black market, and every week more of our technology becomes connected to it, and people being burned at the stake for "file sharing", and the world wide web is being crapflooded with advertisements and commercial interests that continually infest the garden of knowledge that is the web like weeds.

Re:Golden age of the web set to continue

[93 Escort Wagon]

Don't look now, but someone used one of those exploits to replace your comment's font.

Re:Golden age of the web set to continue

[user32.ExitWindowsEx]

I read that pushState / replaceState link and it scared me. Note the following from it:

Suppose http://mozilla.org/foo.html executes the following JavaScript:

var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");

This will cause the URL bar to display http://mozilla.org/bar.html, but won't cause the browser to load bar.html or even check that bar.html exists.

Why do I have a feeling that said effect can and will primarily be used for horribly evil purposes?

Re:Golden age of the web set to continue

[j1m 5n0w]

I like to think of the current state of the Internet as the Wild West phase.

Re:Golden age of the web set to continue

[oztiks]

Exploits is the one of the many issues. How about change control, patching and schema changes, this has got catastrophe written all over it unless the API accounts for a lot more than whats written any serious database application reliant on it would require a strong set of change log rules, shifting data when needed, schema compliance checks before allowing access.

The Web is not the Net.

[John Hasler]

> ...Internet Explorer, Firefox, and Chrome account for more than 90 percent
> of the usage on the Net...

The Web is not the Net.

Re:The Web is not the Net.

[John Hasler]

> How do you find non-Web resources on the Internet other than through search
> engines on the Web?

I use Gopher.

Re:The Web is not the Net.

[John Hasler]

> Do they claim so?

The browsers they list as having 90% of the Net have 90% of the Web. As there is more to the Net than the Web they are necessarily wrong.

> Browser usage is definitely what most people do on the Internet...

You forget spammers and botnet operators, both large and growing markets.

Re:The Web is not the Net.

[raddan]

It depends on what you mean by 'do'. There may be more people 'doing HTTP' on the net, i.e., more people actively involved in that application than any other, but at least half of all traffic on the net is currently BitTorrent, so by that measure, you could say that "BitTorrent is the net". I think that kind of thinking is wrong, though, no matter the dominant application. It's abundantly clear that the net is not one application, but many, many applications, and that a real strength of the current Internet is precisely that this diversity is allowed.

(Whether we need so many application protocols for all these applications is a different conversation entirely, though)

Re:The Web is not the Net.

[WrongSizeGlass]

You forget spammers and botnet operators, both large and growing markets.

Well, they'll just have to abide by the new HTML standards like the rest of us. What's fair is fair.

Re:Piled Higher and Deeper

[jo42]

Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.

- T. Roll

Slowly reinventing the wheel in the browser

[dirkdodgers]

Congratulations, you've developed a framework for client-server application development. Welcome to 1990. But wait, it's different this time because it's lightweight? Only it's not. Your framework runtime (the browser) consumes many times the resources that existing client-server applications ever did, and you still can't provide the same level of functionality.

Progress in the software industry today looks like this:
- 2003: Microsoft releases Office 2003
- 2008: Google releases quirky, limited-functionality clone of Office 2003 that runs in the browser
- 2016: Google releases quirky but fully functional clone of Office 2003 that runs in the browser, only it's progress because it's Web 5.0!!!

Thanks but no thanks.

Re:Slowly reinventing the wheel in the browser

[raddan]

I think your comment is spot-on, and I think the reason is this: programmers hate network programming. They hate concurrency. CODER WANT SIMPLE.

When you look at much of the development of platforms, a great deal of effort has been expended to make sure that the programming model is simple. E.g., from the perspective of a typical process running in a typical modern OS, the world still looks like a simple OS: your own flat address space and simple system calls to use to write to disk, etc. Generally, you don't have to deal with interrupts, shared memory, etc. But networking is where all of this breaks down. The location of your storage is important, because while hard disks are slow, network storage is really slow. Some parts of your application run here, and some run there, and here and there may even be wildly different platforms (e.g., 'there' could be a functional language running on a cluster, while 'here' could be a mobile web browser on a cellphone), so race conditions and slow network links and processors are a real problem.

This constant shifting around is an attempt to find the right complexity balance. I don't know if there is a 'right' balance for all scenarios, but it doesn't look like that's going to stop people from trying to find it. Just look at all the iterations of RPC out there. They all suck, too (you just can't pretend the network doesn't exist!), but that does not stop them from being useful. Just look at NFS.

Re:That sounds great.

[larry bagina]

html 5 already has local storage

Re:Piled Higher and Deeper

[John Hasler]

> ...look just like a local app did ten years ago.

No, no, no. It will look completely different. It'll have rounded corners. Or something. I know! It'll have animated 3D shadows! How can anyone get any work done using a program that lacks animated 3D shadows?

I'm glad Microsoft is involved in the early stages

[Hero Zzyzzx]

so they have plenty of time to plan the (seemingly) minor but maddeningly frustrating ways they'll deviate from the standard.

Need to decouple Javascript before it's too late

[dirkdodgers]

And I see that our options as developers for interacting with this stunning new invention are still limited to one: Javascript.

With application development increasingly moving to the browser, we as developers are going to find ourselves locked into a one language platform.

The browser platform should standardize on a VM, not on a language. Say goodbye to traditional paths of evolution of programming languages driven by competition. Want to innovate by using a functional language to bring your solution to market faster? No can do. It's JavaScriptway or the highway.

Death of Web as I know it.

[ThePhilips]

... a vision to rebuild the Web as a foundation for applications

The day I as user would not be able to resize browser window, adjust font size or copy-paste any random text from a page, will be the death of the web as I concerned.

Indexed DB/etc is OK - but rest of the carp they do under the guise of making web seamlessly integrating with the desktop is a huge leap back.

Some people has to sit for a moment and recall why web applications started winning over desktop applications.

Re:I must have missed something

[BlueBoxSW.com]

Yes, and I've already written apps using it. Safari supports the html5 local storage pretty well, including in the iPhone.

I, too, am unsure how this differs from other new local db storage techniques.

What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determin if you are currently web connected, something like isNetConnected() found in some applications. This would let you customize the option you present to the user (ie, you can only sync your data when you're web connected).

Re:Piled Higher and Deeper

[WrongSizeGlass]

Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.

- T. Roll

Apu: Please do not mock the power of duct tape. These are forces beyond the understanding of mere mortals.

Re:I must have missed something

[icebraining]

Why? Just make a request to your webserver. Even if you are connected to the "Internet", if you can't access your server you won't be able to sync.

Re:Need to decouple Javascript before it's too lat

[PotatoFiend]

Whoa there. Bolting a spoiler and ground effects onto a Prius doesn't make it a Formula One car. JavaScript is fundamentally a procedural (and therefore non-declarative) language. It has first-class functions and closures in addition to some superficial support for programming in a functional style, but the function is not the main focus of the language design and using it as a serious functional language is akin to ricing.

Re:Three cheers

[pandrijeczko]

Microsoft will get behind anything that means the wheel can be reinvented - because somehow, some way, they will be able to make money from not actually having done anything new.

The Web is better

[Geof]

Your framework runtime (the browser) consumes many times the resources that existing client-server applications ever did, and you still can't provide the same level of functionality.

I think you're wrong. Functionality is not the name of the game. Communication and content are. Look, I was doing client-server development in the 1990s: Mac Programmer's Workshop (C++), Unix sockets (C), Microsoft Foundation Classes (C++). I would never go back. True, your example does illustrate your point. There are whole classes of application, like word processors, for which the Web is not (currently). But those are mostly stable, well-defined categories. The Web is not a better way to write Word, but it is a better way to create other software we want even more.

1. The Web is social. When you develop an application, communication between users is practically a given. Back in the day, client-server software was deployed within organizations and was focused on access to data or business processes. Communication was rare and tended to be limited.

2. The web centers on content to which developers add various functionality. You may have to work harder on your applications controls, but HTML and CSS give you tremendous power. A framework like Flash or .NET may let you put things exactly where you want them, but this takes flexibility (e.g. text sizing) away from the user. And they are still missing significant chunks of what HTML+CSS can do.

3. The Web is simple. The learning curve for web applications is dramatically lower than for the kinds of apps you are talking about. HTML gives you hyperlinks for free. It also gives you a history with forward/back buttons, bookmarkable URLs, and a world of users who have been trained to use them. Programmers who try to develop apps without these features loose out on core benefits of the Web (hello, Flash).

4. The Web is relatively unified and transparent. I can view source on any page, or if that doesn't work use Firebug to break down the DOM. These days the standards are complex, but there are real advantages over a mess of competing frameworks. Browser implementations are inconsistent: but that beats writing client-server software that works on some mix of Mac, Windows, and assorted Unix flavors, then trying to persuade the wider world to install client software.

5. Javascript doesn't suck. I was surprised too when I found this out. It has some real weaknesses for sure (dynamic scoping!). It's no Python or Ruby, but it is powerful and its idiosyncrasies pale beside, say, C++ or PHP. Perhaps its biggest flaw is the pathetically poor standard library.

If you want to write a word-processor, the weaknesses of the Web compared to traditional client-server development may be very frustrating. You could still go with client-server, which seems like the right tool for the job. But you don't. The advantages of the Web are overwhelming. It's easier to be nostalgic about the benefits of client-server than to reinvent the benefits of the web.

Re:Need to decouple Javascript before it's too lat

[Homburg]

Want to innovate by using a functional language to bring your solution to market faster? No can do.

That's not entirely true - you could write in Haskell and compile to JavaScript.

Re:Need to decouple Javascript before it's too lat

[Nadaka]

Not entirely true. Technically xslt is a programming language and is supported by many browsers. I know of at least one person writing an XML/XSLT CMS.

Re:I must have missed something

[icebraining]

But the browser doesn't know how your app works! What about if your domain is accessible, but the URLs that provide the webservice your app needs isn't?

You'd have to provide an URL anyway, so the abstracted code would be something like:

function isNetConnected(url) {
        request.open("GET", url, false);
        request.send(null);
        return (request.status == 200):
}

I don't find this to be "REALLY useful".

Re:I must have missed something

[Anonymous Coward]

What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determine if you are currently web connected.

You mean something like
var online = navigator.onLine
as defined in http://www.w3.org/TR/offline-webapps/#related ?

Dynamic Scoping?

[weston]

It has some real weaknesses for sure (dynamic scoping!).

Of all the things to pick on... dynamic scoping? Javascript'd be a harder language to work in without it... you'd essentially be getting rid of closures.

It's too late

[weston]

Want to innovate by using a functional language to bring your solution to market faster? No can do.

If you're familiar enough with functional language F (and JavaScript) to be justifiably snobby about JavaScript's status as a functional language and suggesting a VM as a solution, you shouldn't have much trouble writing an F-to-JavaScript compiler.

(If you do, then you likely fail the "justifiably" part of the snobby criteria, and you're also probably not likely to get a jump on that time-to-market measure, given how much more involved getting a standard common browser VM out into the world is going to be than developing a compiler.)

A VM's a cool idea, and maybe getting the idea into the heads of the people making standards would be worth doing. But if there's ever been anything like a "too late" point, we passed it a while ago, probably around the time Netscape split their ideas for client programming between Java and JavaScript. In the meanwhile, the JavaScript we have today is generally pretty capable, works across yesterday's, today's, and probably tomorrow's browsers, and implementations are getting faster. Maybe it's not your favorite language, but we could be doing a lot worse.

Re:Need to decouple Javascript before it's too lat

[patniemeyer]

Maybe we could create a VM based language designed for networked applications, with a full blown security model down to the bytecode and performance as good as a static language.... And to make people comfortable we could name it something that sounds like JavaScript... I dunno... like Java.. Java... I can't think of one :)

Oh, and then Microsoft can adopt it just enough to completely derail it and prevent it from becoming useful in the browser market... And Sun can let the UI and media implementations lag permanently 5 years behind because it doesn't help them sell more server hardware... And the whole thing can just fester until Google comes along and teams of the smartest people in the world waste years of their lives building a layer of sanity over the JavaScript mess that is acceptable enough to write apps for...