On your first point, it depends on the application. For
some applications, this javascript level already exists
or is appealing. I could even see this being very useful
for siliverlight applications which will call back to
the server via ajax anyway.
On the second point, not at all. You should never trust
user data, regardless of when, where, how it was
submitted. Whether you sync via a local SQL Lite db or
just allow postbacks, data is data and you need to be
careful.
"How secure can your web app really be if all data
access is open for anyone with "view source"?"
Security Through Obscurity is generally regarded as a
bad thing.
I think you have Google phobia, You will not use Google
reader now you doubt about Google gears without
developing anything using it.
Khuzema : Phobia?
I use Gmail as my email solution, Google Desktop as my
offline search, I google apps for domains, and I use
Feedburner, which was just bought by Google. I also use
Picasa (owned by Google), GoogleMaps, I have Google
Earth installed and probably a couple more google stuff
somewhere.
Is asking a question about something you're not sure
about a phobia? Or rational thinking?
I don't think the data access issue you mentioned is a
problem. My hunch is that the developers of Gears
intended it (mainly) to be used as local store for
client-side user data, such as preferences/options,
local data caches, etc. - not sensitive information (why
would you do this in an app where the source code is
partially visible??).
As for the maintenance issue with Javascript, I'm not
sure I follow how it's differenct from any other
language - it's still code in the end, and there will
always be folks (like me) who enjoy working on the JS
land.
I agree, its not something that i find very useful. Even
though its from "Google"(and they can do no wrong) I
greet Gears with a healthy dose of skepticism. Just as i
would if Microsoft or Sun put it out on the market.
@commenter
...and exposing your data access logic for someone to
try SQL injection attacks is even more bad.
I've been thinking similar thoughts. It's just a matter
of time until JavaScript is the end-to-end programming
language of choice in some environments. Imagine TDD
domain-driven design where the domain model and tests
are all JavaScript, the data access layer is a
JavaScript ORM against SQL Lite, SQL Server, etc., and
the same ORM runs on the client's browser as well as on
the server using Microsoft's new DLR. Some would argue
that it brings web development up to the same
productivity level that you get with XAML/C# in the
WPF/Silverlight world. One language for markup, one
language for code. It's not a world I want to see, but
you know it's very attractive to many web developers who
hate having to context-switch to the back-end set of
technologies to make their pretty GUI work do something
useful.
What's the problem with having application logic in
JavaScript? Is it something about the differences
between runtime implementations (which I could buy) or
something about the language itself (which I'd be
interested in hearing an argument for)? Or something
else entirely....
My point was that all web applications expose their data
access facilities directly or indirectly - and hoping
that people wont exploit that through making the
interface more obscure is not good enough.
Not only I don't agree with you, but I think you fail to
see the far end of Gears which is not necessarily web,
but RIA's...
It may be. Not because of writing complex applications
in Javascript. Properly structured JS is as good as
anything else. Not because anyone can see your
application. Some of the most secure software in the
world are open source.
The potential risk is with any new "sandbox" where you
have to provide a secure way for applications to store
their stuff and not be able to grab anyone elses stuff
or worse stuff on yoru PC. Can it be done? Sure it can.
Will there be holes that are exploited? It is a pretty
good bet there will be and hopefully they will be
patched quickly. I would much prefer if Google Gears
were open source so that many "eyes" could look at it
and make sure it is secure.
Having said that I think we will all look back on this
moment as the beginning of the next generation of the
web where really complex applications can enjoy the
security and portability of being browser based.