My first post on this subject described the general waste of resources that Server-side Web Frameworks incur, and the slideshow describing the alternative "Thin Server Architecture" had a number of very clear diagrams describing the alternative. This article meet the criticism I have received, question by question, to further clarify how to lower the cost of web application development.
1. c: Some frameworks are good for some things and some for others. Surely this "Thin Server Architecture" is just one choice among others.
a: No actually, it is not a choice among others. It is the total removal of any web framework on the server whatsoever. That's what it is. It is "No View on the Server", and it is "Put the client on the client". If you consider "lowering your development and maintenance costs dramatically" a choice among others, be my guest. But I would generally consider that a question of whether to have a third ear at all compared to the question of where to put it.
2. c: Oh, you can't use this method for web based applications for users who can't use JavaScript, like some mobile users, or people with disabilities. Therefore, we can't use it.
a: That is absolutely true. If you have to create an application that has that kind of restrictions, you can't use Thin Server Architecture. Luckily the user base of Gmail and other applications of its kind shows that with some luck there might be a sufficient user base out there for consumer facing applications (at the very least) of that kind after all...
3. c: The page will load in weird ways which users are not used to. Nobody will want to use a web application like that.
a: What have you been smoking? The users will react badly to getting things quick? To not have to reload the page at every single click? It's like the notion that humans were unable to survive speeds quicker than a galloping horse when the steam train was invented. Also, you can simulate classic loading using JavaScript if you like.
4. c: There is no need to go to such extremes. We already have AJAX support in JSF and it works well, for minor things where that kind of 'effects' are needed.
a: Since the idea of using Ajax on a separate client (on the client) is opposite to generating the client on the server for every action, this Frankensteinian technique works well for nobody. It is a little bit like tying a jet fighter to a sinking Titanic. You will get a little lift, for a while, and then all will be engulfed by the next wave.
5. c: If you have to shuffle all data to the client using Ajax, it'll be too much data and the page will be slower that if it is created by the server-side web framework at once.
a: Eh, hello? There is still the same amount of data, no matter how you get it over. Using Thin Server Architecture you get the page in place super-fast, then load and pre-load resources under the hood so that the application acts snappy when the user starts to interact with it. Oh, and you only ship the data after that.
Måns Jonasson's research in this area shows a 33% decrease of server resources when starting to move View logic onto the client, from the server.
6. c: We have already invested so much money and training in our server-side web framework of choice, so we'll use it anyway, for all future. Nobody has the strength to ever learn anything again. We're not interested in lowering costs, we just want to do what we've done for years. Go away! Yaah!
a: Well, good luck then :)
7 . c: JavaScript is a Girlie Language. it is only used by teenagers with acne from Finland . Real men use languages that was ridiculed in precisely the same way ten years ago, so there!
a: Well, since JavaScript has no true OO, it can oddly enough not be used for anything at all, whatsoever, except for small scripts that blink a button when you hover over it.
This is really strange, considering some guys are actually claiming that JavaScript is more similar to Lisp and Self than anything else. and what's even more confusing is that people have been building these fairly complicated frameworks in JavaScript, with data models, rpc calls, message buses and rich dynamic, cross-browser charting and graphics, to boot.
Also, there is supposedly companies who provide really great IDE support, of various flavours.
What's more, there already truly amazing solutions for bringing this on big time .
So my take on this is that this is the near future. If you don't think so, and have experience to disprove me, please comment here or mail me, because I'd be more than happy to hear what you have to say.
Cheers,
PS
1. c: Some frameworks are good for some things and some for others. Surely this "Thin Server Architecture" is just one choice among others.
a: No actually, it is not a choice among others. It is the total removal of any web framework on the server whatsoever. That's what it is. It is "No View on the Server", and it is "Put the client on the client". If you consider "lowering your development and maintenance costs dramatically" a choice among others, be my guest. But I would generally consider that a question of whether to have a third ear at all compared to the question of where to put it.
2. c: Oh, you can't use this method for web based applications for users who can't use JavaScript, like some mobile users, or people with disabilities. Therefore, we can't use it.
a: That is absolutely true. If you have to create an application that has that kind of restrictions, you can't use Thin Server Architecture. Luckily the user base of Gmail and other applications of its kind shows that with some luck there might be a sufficient user base out there for consumer facing applications (at the very least) of that kind after all...
3. c: The page will load in weird ways which users are not used to. Nobody will want to use a web application like that.
a: What have you been smoking? The users will react badly to getting things quick? To not have to reload the page at every single click? It's like the notion that humans were unable to survive speeds quicker than a galloping horse when the steam train was invented. Also, you can simulate classic loading using JavaScript if you like.
4. c: There is no need to go to such extremes. We already have AJAX support in JSF and it works well, for minor things where that kind of 'effects' are needed.
a: Since the idea of using Ajax on a separate client (on the client) is opposite to generating the client on the server for every action, this Frankensteinian technique works well for nobody. It is a little bit like tying a jet fighter to a sinking Titanic. You will get a little lift, for a while, and then all will be engulfed by the next wave.
5. c: If you have to shuffle all data to the client using Ajax, it'll be too much data and the page will be slower that if it is created by the server-side web framework at once.
a: Eh, hello? There is still the same amount of data, no matter how you get it over. Using Thin Server Architecture you get the page in place super-fast, then load and pre-load resources under the hood so that the application acts snappy when the user starts to interact with it. Oh, and you only ship the data after that.
Måns Jonasson's research in this area shows a 33% decrease of server resources when starting to move View logic onto the client, from the server.
6. c: We have already invested so much money and training in our server-side web framework of choice,
a: Well, good luck then :)
7 . c: JavaScript is a Girlie Language. it is only used by teenagers with acne from Finland . Real men use languages that was ridiculed in precisely the same way ten years ago, so there!
a: Well, since JavaScript has no true OO, it can oddly enough not be used for anything at all, whatsoever, except for small scripts that blink a button when you hover over it.
This is really strange, considering some guys are actually claiming that JavaScript is more similar to Lisp and Self than anything else. and what's even more confusing is that people have been building these fairly complicated frameworks in JavaScript, with data models, rpc calls, message buses and rich dynamic, cross-browser charting and graphics, to boot.
Also, there is supposedly companies who provide really great IDE support, of various flavours.
What's more, there already truly amazing solutions for bringing this on big time .
So my take on this is that this is the near future. If you don't think so, and have experience to disprove me, please comment here or mail me, because I'd be more than happy to hear what you have to say.
Cheers,
PS
Comments
Cheers,
PS
If there was a JIT compiler or some other way to speed up code execution, I think most people would come to the same conclusion you have.
Another idea that would speed up adoption is to have standard js libraries pre-compiled with firefox. Windows has an api to create a form, etc. Why not have an API to create a form in javascript. If the library was not installed, it could download automatically (but lose the precompiled benefits).
While windows bored everyone with similar looking forms for every application, it did help to speed development on the platform.
This would truly move firefox/IE/Safari to a development platform that could actually challenge windows.
And when it comes to execution speed, it really is sufficient already. TIBCO GI has a browser-based IDE for creating web-based apps that lives in the browser and consumes WSDL services in the browser. In JavaScript. Also, most View and styling actions are not in need of that much speed either. What is needed is to get away from the latency that bogs things down by freezing everything while involving the server.
Then there's some customer examples at TIBCO's site, most notably Bear Stearns.
Also, Gmail, Google Calendar, and documents, et.c. all work in this manner. You load the app, which is in JavaScript, and then the rest of the communication with the Google servers are data only.
The speed is sufficient, but not what it should or could be. Gmail is fast enough, after all I use it. But there is still that java like UI delay when clicking around. I am not talking about latency. I still don't care for java apps for this same reason.
I have also used one of the javascript IDE's, I think is was for Rails, and there is no way I could use it as my everyday editor. Just too slow.
I do use Google Docs, which is acceptable in speed though.
My point is not to argue but to only point out that something additional is needed to propel js to the next level of adoption. For people to actually realize it can be used to program a client application. Perhaps compiled libraries and a standard windowing API would help in that regard.
I'm not really arguing that they are, my argument is rather that - when building web-based applications it takes less resources and gives quicker user interaction - compared to applications which originate all content from the server.
But while on the subject of speed, the as/js engine Tamarin, which was donated to the Mozilla foundation from Adobe, is currently doing JIT compilation for JavaScript, and will be part of future version of Firefox, possibly also other browsers.
That's not to say I love JavaScript programming. JavaScript is difficult to program on the client side due to browser compatibility issues. Experience among developers is also sparse when it comes to working in quirks mode. This is my only problem with the thin server concept.
However, this is the precise problem that GWT is designed to solve. You get to keep you server thin (only serving data), but you don't have to code in anything but Java. This allows you to reuse your client code, when necessary, on the server. It also makes it easier to hire developers since you're only looking for Java.
Good article!
Also, you must have a server, ad PHP is great as a thin server, as long as you only handle incoming RESTive requests (POST, GET or what have you) from the JS client and return raw data.
This goes for all server-side frameworks. PHP happens to have a weak spot in my heart since when I managed to solve a four-class three day dynamic WSDL parsing conundrum I had tried to do in Java in just five lines PHP (it's built-in, no jar file versioning. it it just. there.).
I'm a big fan of quick development. :)
I wrote the basics using a java servlet for cross-page sessions (anyone got a better mechanism?), and combinations of DWR, jquery, ext-js, trimpath, trimquery, and other toolkits for in-browser JS processing.
If you architect a web services layer well enough, and do the state tracking on the client, you have a stateless, completely scalable, low-overhead web tier.
The best part is that timeouts basically disappear. If state is on the client, then stale sessions don't pollute the expensive server memory.
The worst part is the code security. You need to be disciplined in service invocation. client credentials should probably be encrypted on the client and passed to the server on every request.
-- MV
@carl: Could you please post another comment with the links to you articles, to simplify for future readers? Thanks!
Also, I think that it would be interesting to see if we could come up with some kind of minimal specifications on what a thin server should look like, a bit in the same way as REST, but centered on services, sessions, security, et.c.
The SOFEA guys have a fairly strict model, which gives a lot more proofs and examples, but which I feel is a little bit too strict and almost misses the point;
Ruby On Rails opened my eyes and showed me another way to design applications. Using a clean MVC architecture with some moderate AJAX usage results in applications that are easy to understand, easy to use and expose themselves as a bunch of resources. Users can work with urls, save application state as links, mail them around, you get the picture.
If I really needed a rich UI I would go for flex, but a fat Javascript Client will get you nothing but trouble. Why would you want to use the browser for something it was never designed for?
Apart from that RoR still has the same problematic \<\%=foo\%\> approach that mixes in the client metaphor on the server that both ASP and JSP (And PHP, yes) has as well.
RESTive RoR, on the other hand, is my game, since you then do not put the view on the server.
Also, the answer to the question of why to use the browser for something it was not designed for, is like the answer to why one would try to build a tree-house on a sapling.
The answer is that the sapling was not designed to support a tree-house, it would break immediately. However, since 2003, that sapling has grown into a fairly large tree, so if you look again at the browser which was not designed for 'something', you'll see that now it is. ^-^
You could check out the links in the blog post to TIBCO, WaveMaker and Dojo, for instance.
"The second problem (logic-to-presentation interface) actually mimics
the logic-to-data interface and it also has something to do with a later
issue (templating or view/controller). As in the logic-to-data interface
problem, where the logic level (ex: Perl or Python) currently embeds a
lot of data stuff (ie. SQL), the logic-to-presentation interface also
suffers from a lot of confusion, especially when you have templating systems
that allow you to mix code and presentation. PHP is a particularly bad
example of this problem.
This could be solved by explicitly denying the logic level to output
any kind of presentation code. Presentation level stuff (ie. templates
or view/controller) would be in charge of doing any presentation stuff,
getting all the data/logic from the applicatin server (through REST calls,
with data in JSON, XML, SOAP, whatever), with the application server being
explicitly prohibited from outputing any kind of HTML markup code (it just
wouldnt be taken into account or rendered)."
Taken from the application logic article. I must stress though that the muddling of logic and presentation is just as bad in RoR, JSP, ASP as in PHP.
And also, it is quite easily solvable as long as you don't have any presentation in your scripts at all.
For my smaller stuff, I just have a simple "$cmd = _POST['cmd'];". And then I switch on that command to call further resources.
Also, when it comes to templating, Dojo has a very strong templating system that works inside the client itself, so that even inside the browser there is a separation of presentation and logic.
Regards,
Peter
I see this as a rapidly expanding area, as more and more sites leave the 1995-era of click-and-wait.
SQIAR (http://www.sqiar.com/solutions/technology/tableau) is a leading Business intelligence Company.Using Tableau,SQIAR rapidly transform your sea of uncorrelated data into meaningful interactive and actionable visual insights.SQIAR Provide Services in United kingdom and USA.