Sammy.js, CouchDB, and the new web architecture
1–10 of 41 posts
Re: Sammy.js, CouchDB, and the new web architecture
#2I like this idea quite a bit. No application server means less maintenance and less administrative overhead.
Of course, it also means that the newly-empowered database has to scale out just as easily as an application server. For starters, request authentication becomes the responsibility of the database, and that could mean heavy volume.
Re: Sammy.js, CouchDB, and the new web architecture
#3Good, except that you still have to deal with authentication, authorization, and other security aspects of a server-side component. Server-side code won't go away no matter how fat the client gets.
Re: Sammy.js, CouchDB, and the new web architecture
#4Honest question: How would one go about implementing authentication/security into such a setup? Maybe it could work for 1-writer, many reader apps (blogs) but how do you handle user signups, accounts, and security with this?
Re: Sammy.js, CouchDB, and the new web architecture
#5Honest question: How would one go about implementing authentication/security into such a setup? Maybe it could work for 1-writer, many reader apps (blogs) but how do you handle user signups, accounts, and security with this?
I think CouchDB might have built-in authentication coming soon, but I'm not sure about that.
There's always the option of using HTTP authentication.
Re: Sammy.js, CouchDB, and the new web architecture
#6Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over.
So, here we have the return of the fat client, episode 20.
And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?
Re: Sammy.js, CouchDB, and the new web architecture
#7Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?
The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime.
That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is completely different from all those old things!"
Re: Sammy.js, CouchDB, and the new web architecture
#8Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?
Modern standards compliant browsers are usually cross-platform so HTML is the new GUI toolkit, scripted by JS. Especially with WebGL and O3D in the works we will see the browser become the delivery mechanism for the new-old-school fat client. The difference between the new and old is network awareness. New style apps are often mashups.
Programs are temporarily installed for a session by visiting a specific URL (Chrome's app shortcut even makes it seem like a real installation). You update to new versions by refreshing the page.
Old school, new school, like it or not, this is the foreseeable future.
Re: Sammy.js, CouchDB, and the new web architecture
#9Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?
The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime. That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is c…
I'm not sure about these reasons.
decent, free development tools
Well, you can have these for any mature platform. Be it QT, Flex or even Java. I'm not sure what's more decent about the HTML toolchain. The often cited FireBug is, to me, merely an emergency bandaid that makes development at least possible but still far from enjoyable.
the ability to interpose proxies and application middleware between the client and server transparently
There's nothing stopping any fat-client to speak HTTP. You don't need to a browser for that.
and a very, very large install base for the client runtime.
I'd say installation base is a red herring when talking about cross-platform apps but I'll give you that "instant-on" is an argument. For that I'd point to Air, which can run hybrid in and outside the browser.
I'm not arguing that HTML doesn't have it's place, mind you. But the extent to which it is abused nowadays is absurd.
Re: Sammy.js, CouchDB, and the new web architecture
#10Honest question: How would one go about implementing authentication/security into such a setup? Maybe it could work for 1-writer, many reader apps (blogs) but how do you handle user signups, accounts, and security with this?
[deleted]