Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Key Web App Standard Approaches Consensus

Soulskill posted more than 4 years ago | from the apple-doesn't-count dept.

Databases 143

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."

cancel ×

143 comments

Sorry! There are no comments related to the filter you selected.

Golden age of the web set to continue (2, Informative)

levell (538346) | more than 4 years ago | (#31465318)

Personally the new web technology that I'm most keen to get my hands on is the pushState/replaceState [mozilla.org] 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 (3, Insightful)

John Hasler (414242) | more than 4 years ago | (#31465408)

> ...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 (0)

Anonymous Coward | more than 4 years ago | (#31465574)

Why should it mean new exploits? We are far past the ActiveX and other baby steps with the net. Now we can begin to create useful and interesting things with the net.

Re:Golden age of the web set to continue (3, Funny)

93 Escort Wagon (326346) | more than 4 years ago | (#31465698)

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 (1)

larry bagina (561269) | more than 4 years ago | (#31466816)

never attribute to exploit what can be explained by the slashdot janitors not testing css changes.

Re:Golden age of the web set to continue (1)

A nonymous Coward (7548) | more than 4 years ago | (#31467146)

Don't look now ...

Why the heck not? How else is someone supposed to see a hacked *font*?

Re:Golden age of the web set to continue (1)

ground.zero.612 (1563557) | more than 4 years ago | (#31465656)

> ...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.

Yes, but think of it in terms of the relationship between human development and their immune system. The web might be reaching adolescence. Perhaps future of the web will be more emergent than most realize. More exploits also means more robust heuristics, more advanced intrusion detection, and better infection mitigation.

Babies aren't born immune to chicken pox, it takes a life threatening infection to develop that.

Re:Golden age of the web set to continue (1)

WrongSizeGlass (838941) | more than 4 years ago | (#31465702)

> ...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.

The web isn't just for the enjoyment of users. Developers need to get their fix of fun, too.

Re:Golden age of the web set to continue (2, Interesting)

oztiks (921504) | more than 4 years ago | (#31469106)

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.

Re:Golden age of the web set to continue (2, Interesting)

girlintraining (1395911) | more than 4 years ago | (#31465496)

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 (2, Interesting)

j1m+5n0w (749199) | more than 4 years ago | (#31466618)

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 (1)

MobileTatsu-NJG (946591) | more than 4 years ago | (#31469702)

I like to think it's the phase where you've built a global government, but haven't built your UFO yet.

Re:Golden age of the web set to continue (4, Insightful)

user32.ExitWindowsEx (250475) | more than 4 years ago | (#31465708)

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

Suppose http://mozilla.org/foo.html [mozilla.org] 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 [mozilla.org] , 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 (1)

marcansoft (727665) | more than 4 years ago | (#31465908)

Sounds OK to me as long as the site portion remains the same. This isn't any different from other cross-site scripting or impersonation problems. For all I care sites can do whatever they want to the URL bar as long as the site-identificating portion remains constant.

Re:Golden age of the web set to continue (1)

OverZealous.com (721745) | more than 4 years ago | (#31468654)

I don't think this would be a problem. If you already own the website, then you already can change the URL at will to anything you want.

The only reason this would be a bigger issue is XSS attacks - but those are already have way more important concerns than just spoofing the URL.

Personally, I would love it. It would make it much easier to merge the mobile/AJAX/static structures of the website, allow end-users to access the same bookmarks from multiple devices, and provide a much cleaner look than we already have.

Currently, the real issue with AJAX-webapp links is that the server never gets the hash (fragment) portion of the URL. This makes it hard to serve the correct page to a mobile device, and completely impossible if the device does not support JavaScript.

Re:Golden age of the web set to continue (1)

michaelhood (667393) | more than 4 years ago | (#31468942)

Currently, the real issue with AJAX-webapp links is that the server never gets the hash (fragment) portion of the URL. This makes it hard to serve the correct page to a mobile device, and completely impossible if the device does not support JavaScript.

It also makes the server-side logs less and less useful, without introducing other kludges like calling "fake" URLs (via iframes or other tags) just to populate actual activity in the logs..

Piled Higher and Deeper (1)

oldhack (1037484) | more than 4 years ago | (#31465320)

This DB is simply tweaking the edge, nowhere near addressing the real fundamental problem of web app.

Re:Piled Higher and Deeper (2, Funny)

jo42 (227475) | more than 4 years ago | (#31465398)

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

Re:Piled Higher and Deeper (5, Funny)

John Hasler (414242) | more than 4 years ago | (#31465474)

> ...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?

Re:Piled Higher and Deeper (1)

A nonymous Coward (7548) | more than 4 years ago | (#31467186)

i *especially* am amazed at the Mac's throbbing shadows when your program opens several dozen windows. The first few windows only deepen the shadow, which is reasonable even if a waste of effort. But at some point, it decides that deepening the shadow would make it too big, so the shadow starts throbbing instead. I haven't tried writing a custom program to open windows at various speeds to see what happens, but I suspect it is not actually decreasing the shadow for each window, rather setting an internal flag to start throbbing the shadow as long as new windows are being opened.

It's very very bizarre to think that someone put so much effort into such a useless animation.

Re:Piled Higher and Deeper (1)

sopssa (1498795) | more than 4 years ago | (#31465514)

If there's any good side in it, it means you don't have to install some random untrusted applications on your computer but they just work on browser with HTML and JavaScript.

Re:Piled Higher and Deeper (1)

John Hasler (414242) | more than 4 years ago | (#31465550)

JavaScript downloaded from a Web site _is_ "untrusted applications". Soon HTML itself will be a full-blown progamming language.

Re:Piled Higher and Deeper (1)

LiENUS (207736) | more than 4 years ago | (#31465782)

JavaScript runs within a sandbox, so while it's untrusted it shouldn't be able to affect anything outside of its sandbox.

Re:Piled Higher and Deeper (0)

Anonymous Coward | more than 4 years ago | (#31465902)

Let me ask you a question... do you completely, 100% without a doubt trust the sandbox? The sandbox code by definition runs at a privileged level, and must process untrusted input. So really, you're just moving the trust from one developer to another. The problem isn't that the developers might be untrustworthy. It's that they're human.

Re:Piled Higher and Deeper (1)

sopssa (1498795) | more than 4 years ago | (#31466154)

How would HTML5 change that?

Re:Piled Higher and Deeper (1)

John Hasler (414242) | more than 4 years ago | (#31465988)

> ...it shouldn't be able to affect anything outside of its sandbox.

Sure. Of course it shouldn't. And if it did, why that would be wrong.

Re:Piled Higher and Deeper (0)

Anonymous Coward | more than 4 years ago | (#31467380)

It is the same stupid mistake over and over again. If users work on their data with applications inside the sandbox, then their data is not protected the sandbox. The more the web is extended into an API for desktop applications, the more data will be at risk. Now we're talking about local storage. What do you suppose this local storage is going to be used for? Web applications are untrusted code working on confidential data. At least with server-side data there's the intuition that the data is not really private, because there's at least the server operator who has access to the data.

Re:Piled Higher and Deeper (1)

LiENUS (207736) | more than 4 years ago | (#31467642)

You do know not all web apps are hosted by google right? I'm working on a web app for a business that will run on the local lan.

Re:Piled Higher and Deeper (2, Funny)

WrongSizeGlass (838941) | more than 4 years ago | (#31465724)

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.

The Web is not the Net. (4, Informative)

John Hasler (414242) | more than 4 years ago | (#31465344)

> ...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. (1)

sopssa (1498795) | more than 4 years ago | (#31465494)

Do they claim so? Browser usage is definitely what most people do on the Internet, so it might be either way. Especially as people moved from communication on IRC and IM to Facebook and other sites.

Re:The Web is not the Net. (2, Interesting)

John Hasler (414242) | more than 4 years ago | (#31465598)

> 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. (3, Funny)

WrongSizeGlass (838941) | more than 4 years ago | (#31465748)

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:The Web is not the Net. (2, Interesting)

raddan (519638) | more than 4 years ago | (#31465610)

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. (1)

tepples (727027) | more than 4 years ago | (#31465504)

How do you find non-Web resources on the Internet other than through search engines on the Web? For example, to find a torrent file, one uses a search engine on the Web.

Re:The Web is not the Net. (3, Funny)

John Hasler (414242) | more than 4 years ago | (#31465570)

> 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. (1)

oddaddresstrap (702574) | more than 4 years ago | (#31465992)

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

I use Gopher.
Oh, and by the way, get the hell off my lawn!

FTFY

Re:The Web is not the Net. (1)

John Hasler (414242) | more than 4 years ago | (#31466022)

> Oh, and by the way, get the hell off my lawn!

Sonny, when I was your age we didn't have lawns. Grass hadn't been invented yet.

Error -420: Grass not found (1)

tepples (727027) | more than 4 years ago | (#31467324)

Grass hadn't been invented yet.

Then what did you smoke to get high?

Re:The Web is not the Net. (1)

JohnnyBGod (1088549) | more than 4 years ago | (#31466866)

...or Usenet, or eDonkey, or Limewire, or...

Re:The Web is not the Net. (0)

Anonymous Coward | more than 4 years ago | (#31469284)

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

The Web is not the Net.

Stop being so pedantic. Yes they are different, but everyone refers to them synonymously.

Apple (0, Troll)

goldaryn (834427) | more than 4 years ago | (#31465380)

Apple declined to comment about its support for IndexedDB.

However, if IE, Mozilla, and Chrome support Indexed DB, and it becomes a W3C standard, it's likely Apple won't have much choice, because programmers will begin to use it.

Happily for Apple, Google has detailed its approach in a Chrome design document and has begun checking Indexed DB code into WebKit, the open-source project that underlies both Safari and Chrome. That means Apple will be able to adopt a tested version of the technology relatively quickly.

Browser OS/webapps isn't really their market.

Personally, I reckon they are trying to work out who to sue.

Re:Apple (0)

John Hasler (414242) | more than 4 years ago | (#31465440)

> Personally, I reckon they are trying to work out who to sue.

Just be careful never to call it iNdexedDB (or bdDEXEDnI).

I beg you, please don't. (0)

Anonymous Coward | more than 4 years ago | (#31465384)

The web is not an application programming interface. Yes, the "runtime" is ubiquitous and cross-platform, but the price is too high: API induced insanity is going to become an occupational disease among developers.

Re:I beg you, please don't. (1)

The End Of Days (1243248) | more than 4 years ago | (#31465612)

Good news, no one will force you to participate. Isn't it great? You get to ignore it because you hate it, and those of us who don't hate it get to not be ignorant. Life is grand with choice.

That sounds great. (0)

Anonymous Coward | more than 4 years ago | (#31465404)

One of the biggest frustrations I have as a Web developer is that there isn't a way to allow users to save settings on their local computer. Granted, offering this type of capability creates the risk that users will have local settings that they will want to carry with them to other computers but cannot, however maybe something can be done about that in the web clients allowing peer2peer transfer of settings over an authenticated connection. Of course, the next frontier is to make client-client connections simple and easy without requiring a server intermediary as is needed now because of NATting and ISP blockades.

Re:That sounds great. (3, Informative)

larry bagina (561269) | more than 4 years ago | (#31465472)

html 5 already has local storage [w3.org]

Re:That sounds great. (1)

beakerMeep (716990) | more than 4 years ago | (#31465600)

Yeah, about that. From that site:

1 Introduction This section is non-normative. This specification introduces two related mechanisms, similar to HTTP session cookies, for storing structured data on the client side. [COOKIES] The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

Hokay...

Someday the W3C is going to learn how to write I think. You know, in a human language, where the laws of physics apply. Non-normative indeed.

Re:That sounds great. (1)

WrongSizeGlass (838941) | more than 4 years ago | (#31465788)

Are you kidding me? I don't even RTFA's here (I barely skim the summaries) and you want me to read a W3.org document, the 'drying paint' of the internet? Thanks, but I'll wait for /. to do a story on it, TYVM.

Re:That sounds great. (0)

Anonymous Coward | more than 4 years ago | (#31465836)

Local storage looks like a hash table to me, i.e. a simple key -> value lookup.

OTOH, see the first sentence from the working draft

"User agents need to store large numbers of objects locally in order to satisfy off-line data requirements of Web applications. [WEBSTORAGE] is useful for storing pairs of keys and their corresponding values. However, it does not provide in-order retrieval of keys, efficient searching over values, or storage of duplicate values for a key."

So a better api for apps that need to store data. You get multiple indices, cursors and transactions.

Re:That sounds great. (1)

Skreems (598317) | more than 4 years ago | (#31466996)

html 5 already has local storage

Yep, and if they didn't recommend a space limit of 10 megs, it might almost be useful.

Re:That sounds great. (0)

Anonymous Coward | more than 4 years ago | (#31468024)

Five megs. But if you use the database API, you can ask the user to grant you as much additional space as you want.

Re:That sounds great. (0)

Anonymous Coward | more than 4 years ago | (#31465754)

One of the biggest frustrations I have as a Web developer.

One of the biggest frustrations I have with web developers is that they always tend to mess with things they shouldn't, like the fact that you seem to think it's necessary to alter the text formatting of all your posts for no reason.

Slowly reinventing the wheel in the browser (4, Insightful)

dirkdodgers (1642627) | more than 4 years ago | (#31465454)

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 (4, Interesting)

raddan (519638) | more than 4 years ago | (#31465764)

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:Slowly reinventing the wheel in the browser (0)

Anonymous Coward | more than 4 years ago | (#31466602)

While it's true that coder wantz simples, that has nothing to do with the anti-progress of the last 10 years in usability and functionality of new applications.

Web coding is not simple. Interactivity on the web is an order of magnitude harder than writing a GUI using Qt/X or FLTK/X or MS Visual C++. It is a multi-language, multi-program mess, with multiple slightly incompatible presentation platforms on top of that. X windows had the network/storage/programming-model problem you describe figured out more than 20 YEARS AGO. I run X applications every day where the program is on a remote machine and the full featured GUI shows up on my desktop.

What's driving web apps is history, hype, and experimentation with new business models, along with the limitations of legacy network effects. Web browsers were designed for low-interactivity presentation of static material. Once the web took off, interactivity was grafted onto them sloppily, first for business transactions, then other applications like email, and finally for less communications-centric applications like games and word processing. There are real advantages to having your documents accessible anywhere on any platform from the web, or being able to order products from the web, or check your email from everywhere - that's the business driver for web apps, along with the advertising supported services business model.

The limitations of browsers, and the multiplicity of them and difficulty of upgrading them, drives the Frankenstein code software-engineering horror story that is web application development. Half your users are on IE6, some are on Firefox, some on Safari, Chrome, Opera, et al, and many are at work, on computers for which they do not have admin rights, and can therefore not download upgrades or plugins, even if you could succeed in convincing them to do it, which you often can't. Oh, and the web is full of bad actors, so you have to assume the worst about both clients and servers, and incorporate security at every stage in every transaction, which is why we don't just use X over the internet. Java actually achieved something like secure X over the internet in the late 90's, but the Microsoft vs. SUN vs. World rivalry sabotaged it as a standard, along with the sometimes nightmarish installation process (I remember, around 2000, our IT people having to spend a full day installing Solaris upgrades to get Java running on a SUN workstation to run a demo GUI we had developed - using SUN's own Java!).

To reach a wide audience, designers are forced to the lowest common denominator, a mix of HTML and JavaScript and server-side duct tape, or Flash. Progress is slow because a bunch of rival companies, all users, and the IT staff at their workplaces all have to agree to take any one-inch step forward - it's the US Congress approach to innovation.

In a nutshell, people want to access their information and apps anywhere via the web, but the web's history and politics makes it a really shitty platform for delivering an interactive experience. That's why Google Apps 2009 is inferior to MS Office 1995, and yet people use both.

Re:Slowly reinventing the wheel in the browser (1)

HiThere (15173) | more than 4 years ago | (#31466680)

Of course we hate concurrency. That doesn't mean we don't need it.

Concurrency makes code nearly impossible to debug. We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.

Now if you throw in delays for IP connections, handling sockets that might or might not be there, etc. .... now you're getting to a place where most applications are better off avoiding. Yeah, there are toolkits and frameworks to make dealing with it plausible, and to ensure that someone else is responsible for the errors. That still adds time delays of uncertain duration whenever you link. And that means that the errors are ones that you have to figure out from scratch, and may even be in a language that you've never coded in. This is a mess that's best avoided when possible.

Re:Slowly reinventing the wheel in the browser (1)

dkf (304284) | more than 4 years ago | (#31467082)

Concurrency makes code nearly impossible to debug.

Then you're probably doing it wrong. But I'd certainly not characterize it as being particularly easy. Key issues are that you need to avoid shared state (shared state concurrency is very difficult to debug) and you need to beware of global problems like deadlocks and livelocks; not everything can be solved just by looking at individual threads.

But if you keep the level of separation between different concerns strong, with every piece of state having a clear single owner at a time, you avoid most problems.

We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.

One of the issues with Erlang for most people is that they aren't just learning to write highly parallel programs when they start using it, they are also learning to use functional programming. Now there's nothing wrong with FP, but it's very different to the imperative style used by most programmers.

Kinda necessary (1)

HalAtWork (926717) | more than 4 years ago | (#31466242)

It's kinda necessary because nobody will agree on a common runtime or at least common APIs. I'm sure intel and AMD are happy though.

The Web is better (3, Insightful)

Geof (153857) | more than 4 years ago | (#31466446)

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.

Dynamic Scoping? (2, Informative)

weston (16146) | more than 4 years ago | (#31467802)

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.

Re:The Web is better (1)

FlyingGuy (989135) | more than 4 years ago | (#31470066)

I am not "nostalgic" about the benefits of client-server apps, they are what business needs for head-down handling of data in a manner that does not require a 50,000 line mashup of javascript, html, xhtml, xml and bloody css.

Browser implementations are worse then inconsistent, they are insane. One does it just every so slightly different then the other and your app fails in the land of the web browser.

But not to worry, the project for the application browser has begun. It will present a clean well defined environment for an application to run on any platform consistently without the insanity of html/css.

Define a control in your source and it will appear where you want it and it will be a native control, regardless of it being instantiated on Gnome, KDE, Cocoa or Windows.

Both MDI and SDI applications will be supported.

Authentication will be certificate based as well as by name and password.

The web is far from unified and 15 minutes poking around the web will show you just how unified it is not, site to site page to page things fall apart as far as consistency and uniformity.

The DOM is still a mess, it is slow and browsers to not take having their inner-html poked at very well at all.

AJAX aka httpRequest is lousy because you cannot control what the bloody user does. Run it synch and the users complain it freezes up the browser, run it asynch and the back button can destroy the entire context of what you are doing and completely invalidate whatever data you have fetched at that moment in the middle of fetching it and no one has found a way around that so you have to count on the user not being stupid ( good luck with that one ).

A Modal dialogs are required from time to time but unfortunately the javascript alert function is so horrible that you can't even change its font, much less make it bold or even change the graphic.

We have to wait until version fucking 5 to be able to tell a forms field it is required and maybe prevent the submit method from firing?!?!?! And until 5 is ubiquitous we cannot even count on that. But hey who knows they might actually get it together enough by then to actually transmit the fact that a check box is NOT bloody checked instead of having to either do kludges like hidden fields or have to write backend code to check to see which ones didn't come back!"

Personally I want a reliable, predictable and more importantly a controllable application browser that does not have some ding dong browsing some virus ridden, malware delivering web site finding yet another vulnerability to go across sessions to rape the mission critial data the user is "working" on while they are watching porn.

The bottom line is this. With vagaries of browsers, apache, jvm's, servlet enigines and the like it is a monumental pin in the ass to develop "applications" for the web. And as hard as they try it is just never going to work as well as something presents native controls, using native interfaces and talks directly to the data source not through 5 different application frameworks.

Re:Slowly reinventing the wheel in the browser (1)

Jenming (37265) | more than 4 years ago | (#31466850)

For the most part, but Google Office has some advantages. Multiple people editing the same document at the same time can be really powerful.

Re:Slowly reinventing the wheel in the browser (0)

Anonymous Coward | more than 4 years ago | (#31466854)

While this is true, grandma doesn't have to install anything. Everything is done for her if her browser supports it. Moreover, you can use applications without having to install anything which is a big bonus since applications now seem to think they have unlimited privileges (like adding themselves to your start menu, taking over file type associations when you don't want them to, adding themselves as a service, installing third party software unrelated to the application, etc) to your computer if you install them.

Re:Slowly reinventing the wheel in the browser (1)

FlyingGuy (989135) | more than 4 years ago | (#31470092)

The Application Browser will install in user space, require no system privileges, maintain its own lib's and dll's in its own directory space and more importantly it will be lightweight, fast and very very small. It will stay the hell out of the windows registry and stay the hell out of the etc directory. It will keep everything it needs local.

Re:Slowly reinventing the wheel in the browser (0)

Anonymous Coward | more than 4 years ago | (#31467040)

Web programming has always felt to me like a failed attempt at reinventing X11.

Re:Slowly reinventing the wheel in the browser (1)

LiENUS (207736) | more than 4 years ago | (#31467560)

Web programming has always felt to me like a failed attempt at reinventing X11.

Except the web works on dialup links whereas X11 feels sluggish on my 10/100 network

I must have missed something (1)

Mike Rice (626857) | more than 4 years ago | (#31465534)

Isn't local storage part of HTML 5?

Re:I must have missed something (4, Informative)

BlueBoxSW.com (745855) | more than 4 years ago | (#31465672)

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:I must have missed something (1)

WrongSizeGlass (838941) | more than 4 years ago | (#31465864)

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

Since they couldn't decide on what version of SQL dialect to use for Web SQL they're abandoning it for this new and improved idea developed by someone at Oracle. With Oracle's attitudes about licensing how could this be anything but the perfect solution?

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).

For this I generally use an XMLHttpRequest for a tiny file. If I get my "200" I'm connected, if I don't I'm not.

Re:I must have missed something (2, Informative)

icebraining (1313345) | more than 4 years ago | (#31465946)

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:I must have missed something (1)

BlueBoxSW.com (745855) | more than 4 years ago | (#31466142)

Why? 'cause while it is possible to do in javascript, the appropriate place for it is the application/browser.

Re:I must have missed something (2, Informative)

icebraining (1313345) | more than 4 years ago | (#31466632)

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 (1)

BlueBoxSW.com (745855) | more than 4 years ago | (#31466790)

I'll stick to my guns, having created apps using local data for mobile use. Having the ability to detect net connection would be really useful.

While it's possible to hack this together in javascript, getting system status information from a try/catch type block executed in an asyncronous fashion leads to false positives, false negatives, and code that's generally difficult to debug.

It's not important that it works for you, it's important it work in the field.

A simple synchronous javascript API that allows the browser to detect net connectivity or connectivity to a specific server (ping-like) would be really useful. In fact I'll go so far as to say REALLY USEFUL.

As I stated in the original post, it's my opinion. You might have a different opinion, but trying to prove to me my opinion is invalid is a fool's errand.

Re:I must have missed something (2, Informative)

Anonymous Coward | more than 4 years ago | (#31466990)

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 [w3.org] ?

I'm glad Microsoft is involved in the early stages (3, Insightful)

Hero Zzyzzx (525153) | more than 4 years ago | (#31465540)

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

Re:I'm glad Microsoft is involved in the early sta (1)

NightLamp (556303) | more than 4 years ago | (#31468220)

mod parent up, we've all been there, wait, we are still there.

Re:I'm glad Microsoft is involved in the early sta (1)

shutdown -p now (807394) | more than 4 years ago | (#31468750)

You would prefer IE to just use MSSQL CE?

Need to decouple Javascript before it's too late (4, Insightful)

dirkdodgers (1642627) | more than 4 years ago | (#31465620)

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.

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

larry bagina (561269) | more than 4 years ago | (#31465652)

Javascript is a functional language.

Re:Need to decouple Javascript before it's too lat (2, Interesting)

PotatoFiend (1330299) | more than 4 years ago | (#31466312)

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:Need to decouple Javascript before it's too lat (2, Informative)

Homburg (213427) | more than 4 years ago | (#31466494)

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 [haskell.org] .

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

FlyingGuy (989135) | more than 4 years ago | (#31470110)

Yes, I could also burn my own eyes out with a cutting torch but why would I want to!

Re:Need to decouple Javascript before it's too lat (2, Interesting)

Nadaka (224565) | more than 4 years ago | (#31466630)

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.

It's too late (2, Insightful)

weston (16146) | more than 4 years ago | (#31468226)

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 (2, Insightful)

patniemeyer (444913) | more than 4 years ago | (#31468406)

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...

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

bertok (226922) | more than 4 years ago | (#31470006)

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...

Java had almost everything right, but failed utterly on two important fronts:

- slow initial load time of the interpreter.
- GUI designers for layout and graphical elements

The first problem still hasn't be solved, and it's been more than a decade. When the Java plugin starts, everything grinds to a halt. What's even worse is that I have a fast dual-core CPU and a high-end SSD, and it still takes forever for that thing to load. Meanwhile, .NET apps and Flash both start instantly.

The second problem is only now being solved, slowly, and usually by third-parties. Microsoft did the "right thing" with their new WPF/Silverlight format XAML. It cleanly separates applications into a "declerative UI design language", and a "procedural scripting language". The point of this is that it's virtually impossible to make a good drag & drop GUI designer for a procedural language, but quite easy for a declarative one. Java never had a UI layout language, it just used more Java code.

Note that HTML provides both of these things: fast load times, and separated design and script languages: HTML/CSS and JavaScript, respectively.

And yes, I know that these issues are being kinda-sorta fixed in Java these days, and there's competing technologies like .NET that never had the problems in the first place, but it's too late for Java, and most of the alternatives aren't cross-platform. The Web 2.0 system won, because it was fast, had good GUI tools, and was cross-platform from day one.

Death of Web as I know it. (2, Insightful)

ThePhilips (752041) | more than 4 years ago | (#31465626)

... 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:Death of Web as I know it. (0)

Anonymous Coward | more than 4 years ago | (#31466908)

You do realize that Javascript can already prevent you from resizing your browser window and block copy and paste? Of course in Firefox you can prevent that type of behavior, but hopefully such options would be available for any new technology.

fucking faggots (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31465686)

stop eating shit, you dirty birds.

Three cheers (0)

Anonymous Coward | more than 4 years ago | (#31466130)

This is absolutely amazing, against all probability they've managed to make something even less elegant than SQL. Truly a herculean task!

Now, if we can please have a workable proposal? The original idea of speccing SQLite was better than this IndexDB nonsense -- hell, even bindings between Berkely DB API and the browsers DOM would be better. Microsoft would grudgingly "support" something with real-world potential, if they are promoting IndexDB it's because they know it's such a crap spec that'll it give silverlight a fighting chance.

Re:Three cheers (2, Insightful)

pandrijeczko (588093) | more than 4 years ago | (#31466366)

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.

Re:Three cheers (0)

Anonymous Coward | more than 4 years ago | (#31467192)

It's directly comparable to the Windows Registry >_>

Users like the division (1)

SlappyBastard (961143) | more than 4 years ago | (#31466330)

The few times I've tried to pitch web apps to clients as a genuine replacement for desktop apps, they've glared at me like I was threatening to kill their favorite dog.

Oh no, here we go again. (0)

Anonymous Coward | more than 4 years ago | (#31466506)

Good grief, not again. The problem with clod computing isn't the ability to store large amounts of data locally... the problem with clod computing is latency and record locking in a multi-user environment.

Web as application delivery mechanism (1)

pem (1013437) | more than 4 years ago | (#31467846)

I know I'm a heretic, but all this stuff is way too complicated. Let's say that I code a little Python application I can give out to people. The hard part is they need to download Python (or I could freeze the app and they could download a multi-megabyte file). In any case, once it's downloaded, it's not my deal any more. I can explain to them where there files are, how to back them up, etc. It's perfect for little open source apps.

But with this web stuff, now, if I want to persist data, I need to do it for them, or write some wacky code for backup, or whatever. It's too tightly coupled to the browser.

The best of both worlds would be a browser option that allows the user to associate a website with a local directory. Then, an in-browser application could read and write files on the local filesystem.

This whole deal of "give each application 10MB" or whatever in some invisible space that is on the user's hard disk is just making some default decisions on the user's behalf without making him think, which is a reasonable model for some things. But why can't we use the browser to deploy desktop applications that the user doesn't need to install, and that don't need to be written in Java or use some other probably broken or browser specific special mojo?

The whole thing is security theater as bad as the DHS has. All the fancy stuff doesn't seem to affect the ability of real, dedicated, virus writers to inflict incalculable damage on millions of computers, but the idea that a web application could ask the user "Can you give me a directory where I can store the data I create for you?" sends these trained professionals into a worse tailspin than somebody who inadvertently walks through airport security in actual shoes...

if you want to reinvent the wheel, do it right! (1)

AlgorithMan (937244) | more than 4 years ago | (#31467952)

We have technologies, that are perfectly fine to create everything, that is neccessary...
  • make the webbrowser an X-Server and the webserver an X-Client (no, not vice versa - read about the server/client structure of X...)
  • make the webbrowser a Pulse Audio Server and the webserver a Pulse Audio Client
  • make the webbrowser an SSH Server and the server an SSHFS client, which mounts one of your local directories (that the webbrowser shares - this could be interfaced like the "download" dialog...)

another idea would be a transmission of a binary, that is run in a virtual machine, which runs some minimalistic linux...

It's just insane to put duct tape after duct tape on a filetype and a protocol, to add feature after feature. features, that the specifications were deliberately designed to not support! http for example was designed for just passive consumption (no sessions - this today makes web-developers use session ids in cookies and such) or html was not meant to be able to send data back.
all this added javascript, css, flash, AJAX, all the server-side stuff like php are mere duct tapes to (poorly) add stuff, that was deliberately left out in the first place...

In my opinion it is time to scrap all that legacy shit, start over from scratch and this time, do it right!

Cookies on steriods (1)

yalap (1443551) | more than 4 years ago | (#31468272)

Probably it will go through the same paranora that people had over cookies and eventually most people will give up and accept how much can be tracked about themselves and their web browsing.

Security is important (1)

1,$d (635533) | more than 4 years ago | (#31468662)

The spec has to have a rock-solid security model required for implementors, and a good security test suite must be freely available. Without these, the database will turn out to be a major hack vector. With a great security model, we only have to worry about bugs. As it stands, the spec covers security very lightly.

The spec has these sections that mean people are at least thinking about security. I hope there are actual security experts involved:

If you want this thing to succeed, you have an interest in the security model.

#irc.trollta7k.com (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31468934)

eyes on the real tHe facts and
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?