Slashdot Mirror
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."
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.
Struggling to find a day everyone can make? WhenShallWe.com
This DB is simply tweaking the edge, nowhere near addressing the real fundamental problem of web app.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
> ...Internet Explorer, Firefox, and Chrome account for more than 90 percent
> of the usage on the Net...
The Web is not the Net.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
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.
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.
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.
Isn't local storage part of HTML 5?
so they have plenty of time to plan the (seemingly) minor but maddeningly frustrating ways they'll deviate from the standard.
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.
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.
All hope abandon ye who enter here.
Javascript is a functional language.
Do you even lift?
These aren't the 'roids you're looking for.
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.
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.
Twinstiq, game news
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.
"Liberty may be endangered by the abuses of liberty as well as the abuses of power." -- James Madison
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.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
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.
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.
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.
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.
Grass hadn't been invented yet.
Then what did you smoke to get high?
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.
Tweet, tweet.
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...
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!
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
mod parent up, we've all been there, wait, we are still there.
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.
Tweet, tweet.
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.
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...
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:
"Thus, strictly following the origin model described in this specification is important for user security."
If you want this thing to succeed, you have an interest in the security model.
You would prefer IE to just use MSSQL CE?
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.
Yes, I could also burn my own eyes out with a cutting torch but why would I want to!
Hey KID! Yeah you, get the fuck off my lawn!
- slow initial load time of the interpreter.
- GUI designers for layout and graphical elements
True... although third parties would have sprung up to take care of the GUI designer issue if there had been more demand. Sun did make attempts in this area, but they couldn't overcome their earlier mistakes.
The slow startup issue could have been addressed earlier with a resident VM strategy... but they wanted to wait for an perfect isolation API... and they wasted a decade on that and it never mattered.
The bigger problem though was going with a native AWT from the start instead of a mostly Java implementation like the current Swing. Netscape wanted a native look and feel so they caved and put out this mess that was the original AWT that didn't work consistently across platforms and wasn't truly extensible... and that was a lot of people's first exposure to Java. Then Microsoft froze progress there in their browsers and the rest is history.
I have an idea. Let's create a lightweight desktop app that can browse the web and stream audio/video, upload/download files, and submit text for online shopping, and posting to Slashdot. Let's call it web... err... uhmm... web browser. Yeah, that's it. Let's call it a web browser.
If we need to do anything more, develope a "helper application". Even better; an internet-enabled app that avoids screwing around with my browser altogether. I don't know about everybody else here, but I was around in the days of Mozilla 0.9x. It was a big, bloated, slow, joke of an app, even with compiler optimizations. There was lots of joking regarding "about:kitchen sink". People started yelling and screaming for a lightweight web browser, *WITHOUT* email, usenet, webpage developement tools, etc, etc. Thus was Phoenix born, later renamed to Firebird and then Firefox, due to legal issues.
Maybe it's time for a lightweight *WEB BROWSER* version of Firefox. *WHY* the F*** do web browser writers *INSIST* on trying to develope pseudo-operating-systems on top of their web browsers? Are they refugees from the emacs world? Don't they remember what happened when AOL tried to "re-invent the browser" and destroyed Netscape in the process?
If you *REALLY* need to edit a spreadsheet on a remote server, you should be using a VPN. Failing that, howsabout internet-enabled apps like so...
excel https://www.bad.example.com/fubar.xls
or
gnumeric https://www.bad.example.com/fubar.xls
Ditto with word-processors etc. And puh-lease keep your hands off my web browser.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Which is why it makes an easy target for a Scheme compiler, right?
http://github.com/dyoo/moby-scheme
http://planet.plt-scheme.org/display.ss?package=moby.plt&owner=dyoo
http://www.cs.brown.edu/~sk/Publications/Talks/Moby-Bootstrap/
..someone is trying to hack you. So you have to check whether or not it's set either way. The way it is now, that's all you have to check. With your proposal, after checking that, you'd after have to check what it's set to. Which would be more code to write, and run slower, without giving any more functionality.