31–40 of 41 posts
Yes, 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?
Good, 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.
In this case it will just move into the database. You'll have to start writing procedures and rules in the database instead of in your web framework and only expose those instead having only trusted code interact with the DB.
Yes, 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 (Chrom…
I'm sorry but I fail to see what 3d technology in the browser has to do with application UIs. The two fundamental problems with HTML are the complete failure that is the box model, and the W3Cs complete ignorance of real world requirements.
As an example for the latter just look at the pityful HTML widget-set that hasn't changed one bit over the last 15 years. Every OS GUI toolkit in existence has native widgets for comboboxes, date pickers, sliders and various other amazingly useful primitives. I don't see any plans for finally bringing any of that to HTML. Instead we'll continue to see every new javascript framework reinvent them to varying degrees of success, along with a long list of other baseline functionality (client-side form validation, anyone? WebSocket really soon now?).
All the while the W3C invents fancy audio/video tags, 3d widgets, a questionable canvas API and lots of other stuff that hardly solves any real problem we developers are fighting every day, in any app.
I don't think the evolution of RIAs will wait for the W3C to get their act together. I rather think the alternatives to the browser will see a raise in popularity in the foreseeable future, as the HTML/JS combo gets maxed out and more people start looking for ways to notch the expirience up further than possible within the browser constraints...
Earlier quoted context omitted.
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 s…
> and a very, very large install base for the client runtime. You are underetimating this. For evrything else, (air, java, Qt, C#) I have to start a new app. My firefox is always on.
Earlier quoted context omitted.
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.
Is that really good enough, though? For example, suppose that I write a blogging platform, and I want to ensure that a user can only query their own blog entries. How would I do that if the query is coming from the client (which always has to be untrusted) directly to the database? What prevents someone from rewriting the js client side so that it queries blog posts from other users? Or to prevent it from just suckin…
Earlier quoted context omitted.
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.
Is that really good enough, though? For example, suppose that I write a blogging platform, and I want to ensure that a user can only query their own blog entries. How would I do that if the query is coming from the client (which always has to be untrusted) directly to the database? What prevents someone from rewriting the js client side so that it queries blog posts from other users? Or to prevent it from just suckin…
http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy
Then as long as the client can keep its identification token secret from others, you can implement "user can only query their own blog entry"
I suggest you look into couchDB a bit further. CouchDB is a different beast altogether from relational databases. Therefore, the assumptions you make about what a database can and cannot do coming from a relational world doesn't always apply.
When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state. We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappu…
I find the grafting of cocoa onto javascript a bit stomach turning. Its like watching a man read the news to you on TV. Different mediums require different methods. I don't think anyone has really gotten this right yet. I agree jQuery isn't the whole solution, I don't think Sammy.js is the whole thing either. But I do think there will be something built on top of this stack. I have started to try and create something…
Honest 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?
Example of how he does authentication: http://github.com/jchris/toast/blob/master/validate_doc_upda...
http auth + document update validation function
It's unintuitive, but this setup actually supports a huge number of connections and runs really fast. Go figure.