Slashdot Mirror
Brad Neuberg, Google Gears, and the Future of the Web
Linux.com has an interesting look at Google Gears and one of its leading evangelists, Brad Neuberg. "For Neuberg -- as for most developers -- the idea of expanding the Web's capabilities is intriguing in itself. But both inside and outside Google, his argument is that there's more at stake than just a particular piece of technology. In fact, he does not even seem particularly concerned whether Gears or some rival project takes on the role he envisions. What matters, he says, is that finding a solution to the problems of the Web is essential not only to the continued evolution of the Web, but also to its continued freedom. "
How does a guy who says 'Lets keep it working so it can still be used' qualify as news... I thought it was just common sense!
that the buzzwords like "web {[0-9]}.0" or "semantic web" are missing from a topic discussing future of the web
Why do we have to continue developing the web and forceing it do things way outside is problem domain. USENET did not have to evolve, ftp did not have to evolve, smtp did not, gopher did not, etc etc.
Why can't we leave the web alone, use it for what we use it for now and develop a new rich application protocol if that is what people want. It might end up replacing the web like the web replaced gopher, which replaced Archie before it, or it might become an addition to the suite of internet protocols. Why does my web browser have to be all things to all people?
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
I'd be more impressed with Google's forays into Javascript if they could make their existing stuff work right. After several years of deployment, Google Maps still displays incorrectly in Firefox 2 if you spin the scroll wheel too fast. That's about where window refresh was at Microsoft Windows 2.x or so - broken.
Brad Neuberg looks like quite a happy guy.
The most awesome Web 2.0 tool that Google didn't invent...
http://blog.pipes.yahoo.com/about-pipes/
From... YAHOO?!?
Pipes lets you use a GUI to write little 'programs' (functions appear as elements in a flowchart) that aggregate and process data from almost any source on the web. For fun, my first pipe was a simple experiment, I took the slashdot RSS feed and performed a flickr search on all the "imporant" keywords in each story title, then presented a list of stories+photos. Was easy, educational, funny in many cases, and not completely useless.
You mean mobile internet?
-- (this is a sig) My Computer Programming Forumhttp://www.programers.co.nr/
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
After reading the article (really!) I can see how Gears is more than just offline storage, but extending the browser to do what it should. Right now it is only available as a FF plugin right? Could it be expanded into the google toolbar? ported to IE in the toolbar?
I want to look at this as a way to make even more powerful webapps, but until it gets more widespread it only seems appealing to apps that have a clear offline use.
"how can they call it a MINE if everything here is THEIRS?!?!" -Straight Jacket
"I like to make browsers do things that they weren't supposed to do," Brad Neuberg likes to say.
I'm sorry to say, but that is an idiotic statement!
Call me old-fashioned, but I want to control where my data is stored and I want to make sure the programs I use to work my data is around years later. That is why I story my data locally (and a backup offsite) and keep my software locally on my PC. I decide when to migrate to a new version or application and only after I have verified it works with my data etc. With Web-Apps I have absolutely no control when new releases are forced on me and potentially cannot deal with my 10 year old data. I still use Office 97 - works just fine - no need to upgrade. And the data itself ? Will it still be available 10 years from now when stored at Google or some other service provider. What happens if the Google business model some day no longer works ? Will they then charge me to get to my data ?
So.. yeah, will this finally fix tables so they work the same on all browsers?
Sometimes new tech should take a back seat to making existing stuff work properly.
The world is a perfect example.
first, a few observations I very much agree with:
1) even with HTML-5 and Ajax, HTTP is still not an ideal protocol for delivering applications
2) by now, web browsers has got huge momentum
reckoning with those two facts-of-life, new frameworks are being developed to solve the online vs. offline and other dilemmas (GWT, Gears, OpenLaszlo, Silverlight, Air, etc)
Now, I would like to add one more (OSS) project to this growing list:
Dr.i.n.e. - project:
http://code.google.com/p/drine/
Based on the ideas of Wine project, this one uses java+xml APIs of Google's Android to give developers a single framework for developing mobile/web/desktop-convergent applications.
Basically, every line of java code that you write gets automatically "ported" to the web, desktop and also to Android phones, without requiring source code modifications/branching. It's a mammoth undertaking, but I believe in it (so far has been my "labour of live"). I also see that project needs some initial publicity to get off the ground...
You can check out Dr.i.n.e. project's concepts and tech. overview here:
http://www.soften.ktu.lt/~alex/drp/
cheers,
Aleksandras G.
If I were to develop a web-based desktop application, I'd use a web framework which allows me to develop a webapp just like it was a desktop app. The only such framework I know is Wt ( http://www.webtoolkit.eu/ ): C++, Qt-like API. I gave up on Rails after discovering it.
We aren't trying to replace Ajax with another model.
Pity. This means that you're compounding the biggest practical problem in desktop computing today.
The web browser is by far the most flaky, least secure, and worst designed component in all current-day desktop operating systems. All of these problems stem from a single fact, namely the monolithic structure of every common non-trivial browser, ie. a single process space and hence a single point of failure. Even separate plugins just expand the single monolithic state space of a browser.
Millions of browsers crash daily, losing umpteem millions of accumulated windows and tabs representing a large amount of work in progress, just because one bad site has triggered a bug somewhere in the collosal body of code embodied in any modern browser. Every non-trivial application has both known and latent bugs, and their number is proportional to the size of the program code, so it's not surprising that these huge programs contain huge numbers of bugs. When a bug is triggered, the only strong defense available stems from MMU-guaranteed address space partitioning, or VMs/processes in other words, yet modern browsers are designed like oil tanker behemoths with a single unpartitioned eggshell delaying the onset of doom. The result is the reliability disaster we see daily.
This situation is already bad enough today, but worse, it isn't scalable for tomorrow.
And your upholding of the current model of web design pushes ever more state into that single fragile monolithic egg, and so it just makes matters worse.
Gears may look cool from the conventional worms-eye view, but you should fly up and look at the bigger picture sometimes too Brad. You're adding features to a major disaster.
Instead of "not trying to replace Ajax with another model", you *should* be seeking new models, models that promote physical browser partitioning. By adding to the status quo, you're just compounding the problem.
First off, the web isn't even stable. Why try to bloat it further? Didn't anyone take a lesson from Microsoft? Bloating before you've stabilized what you have IS BAD and leads to Vista.
JavaScript, ActionScript, embedded video, even IMAGES, can all be exploited with quite a bit of ease. Ever wonder where all those botnets come from? It ain't from e-mail attachments. People have had that lesson drained into their heads for over a decade now.
No, the botnets come from loading exploited web sites that ask the user to install something (usually an ActiveX control) in order to continue. That something is typically a virus, trojan, zombie client, etc.
How did we get to the point that web sites can install malicious software on PCs?!
The answer: The Brad Neubergs from 20 years ago. The advocates to pair some sort of client-side scripting language with HTML to create an infinite number of possibilities. And now every user has a technology built-into their browser that they should have disabled by default. But if they get proactive and disable it half the web's functionality goes away now because we've had nearly 20 years of web development with the assumption of a javascript on the client.
What we need is a push away from this stuff. Get back to what the web was originally created for: serving hypertext document. If you want a thin client into your application WRITE THE THIN CLIENT APPLICATION. You want compatibility? Write it in JAVA. Or MONO. Or whatever.
Just ask yourself this: did we need Javascript on the web 20 years ago. If we didn't have javascript embedded into every browser out there today would we have anything like the Storm botnet? Would we have as much installed malware out there today?
I say no. And I think it's a pretty safe and obvious no.
So instead of creating new attack vectors for kids and crackers, how about we look at securing what we have now? How about we start advocating white-lists built into each browser that allow things like Javascript and the like. How about we, BY DEFAULT, keep Javascript disabled.
Ah, but mister Brad won't be so keen on that. A user will go to one of his web sites without Javascript, won't see ANYTHING and the site will simply not work, and they'll move on to another web page.
So let's keep bloating the web! Let's keep bloating the browser. And say FUCK ALL to protecting the end user.
I have that concern with tossing browsers and replacing them with a proper IAHE.
The O/S is already the perfect IAHE. It fully integrates all comms and all applications, and it does so securely and efficiently.
In contrast, by adding another IAHE as middleware, you would be adding overhead, creating bottlenecks and new single points of failure, adding complexity, increasing bug rates and reducing robustness, and gaining nothing much at all.
You're dead right that the rise of the monolithic browser was a disaster, but replacing it with middleware is almost as bad. Let the O/S do what it's best at: comms and apps integration, and that obviously includes Internet comms and web apps.
A distinct IAHE is not needed. In fact, by making it a distinct layer you would intrinsically reduce the ability of the O/S to do its job well. An extra IAHE is a bad idea.
<flamebait>Yeah, and they're all dead.</flamebait>
USENET: Effectively dead. Now, before all the geeks pop up and say, no, comp.lang.* is great, or alt.binaries* is where it's at, YOU (we) ARE GEEKS. Normal people have never heard of it. Normal ISPs no longer offer NNTP servers, or not full ones, or if they do you only find out about it if you ask the guy behind the "Beware of the leopard" door. The last and only time I saw an ISP welcome pack mention USENET was about '97, and even that was a JANET-affiliated provider working the academic demographic. As for full, free & public NNTP servers...FTP: Well, I admit, still in massive use, but I thought all the cutting-edge slashdot kids used SCP instead these days? I remember recently there was a story about an FTP exploit and the overall tone was "archaic, obsolete, why do they still even have it..."
SMTP: Also dead, IMHO. Killed by spam, RIP. I realise this is my most contentious claim, and rest assured I realise exactly how ludricious, unsubstantiable and trollish it is - but at the same time it's fundamentally true. As the Korean meme goes, "Email is for old people". Well, not just in Korea, in my experience. My parents' are the only social emails I get. Everyone and everything else has moved onto a social network like Facebook (yes, I know
Gopher Seriously, what? (Note to the inevitable sarcasm-impaired indignant poster brandishing a Wikipedia link: don't bother, I know what it is really...)
So in a nutshell, the reason it has to evolve is: "evolve or die".
Which, like I say, is an answer you reach yourself:
Why can't we leave the web alone, use it for what we use it for now and develop a new rich application protocol if that is what people want. It might end up replacing the web like the web replaced gopher,Which in turn leads to the real "why" underlying all this - which is why evolve something, instead of starting with a nice clean slate? Well, answering that would turn this post into a novel, but I think that's just the way the real world tends to work, a world of deadlines, budgets, compromises, pragmatism, and where people often don't know what they want until they stumble onto it... Sure, you often end up with a right old mess and it's contrary to the sensibilities of the good design/architecture/algorhythm-conceptualising Geek, but hey...
(PS. Hey, slashdot! You know, when you use a CSS reset stylesheet to zero all margins and padding, you're supposed to recreate your own sensible, good-looking format for things like our friend the <dl> definition list...)