5 ms·

Are Serverside Web Frameworks Becoming Irrelevant?

36 points by Garbage 16y ago

r0h4n 16y ago
If smartphones keep getting faster cpu's , then it is there is no problem to process data on the client, and use the server just as a dumb data spitter.
roder 16y ago
I've tried to accomplish a REST API + JS client on a few of my projects, but where I get hung up is session handling. What I've ended up doing is writing the REST backend and writing the presentation layer in something light, like flask or sinatra, just for session handling.
- pilif 16y ago
  you shouldn't need to do session handling if you are going REST. Rest is all about not having state. If you need authentication, authenticate on every request. If your request needs some additional info to give a response, pass that information in when sending the request. It's really a different paradigm and sometimes it can get really painful to move away from the way of thinking that we are used to.
  - roder 16y ago
    I realize that you don't want to maintain state in a REST api. It's not that it's painful to do something I'm use too (ie: session handling), it's just its painful implementing. My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
- necubi 16y ago
  How I've done it is something like this: (1) Client sends auth info to backend server (2) Server sets auth cookie on client (3) Every request goes through a proxy written in Ruby/EventMachine which either just passes through the request to the backend server if requesting something public or first checks that the client's auth cookie is valid if its requesting protected resources. This certainly isn't as simple as it would be in a server-side framework, but otherwise it works pretty well.
staktrace 16y ago
I agree, this does appear to be the trend. Google also has indexing support for AJAX pages (http://code.google.com/web/ajaxcrawling/index.html http://code.google.com/web/ajaxcrawling/index.html) so it's not hard to make a single-page app that is indexable by Google. My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that. One potential pitfall I can think of is cookie management - the JavaScript APIs to manipulate cookies is very poorly defined easy to make mistakes while using. I think this is doable but we need to tread softly to make sure that we don't introduce new classes of vulnerabilities.
- __Joker 16y ago
  "My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that". Can you ( or anybody ) expand on this ?
stcredzero 16y ago
One good thing about JS and a REST backend: there will finally be widespread separation of UI and domain!
- cletus 16y ago
  This whole separation of UI and domain is the kind of Ivory Tower academic nonsense perpetuated by the DDD folks and many, many others. Nowhere is this virulent plague more endemic than in the Java world. As the joke goes, the Java programmer's response to any problem is to add just one more layer of abstraction. And I say this as a Java programmer of some 10+ years experience so please don't take it as mindless Java bashing. As Joel (the classic Joel of old) would say: all abstractions are leaky. To add my own editorial: the less hand-wringing and self-flagellation about the purity of the uberlanguage, uberframework or uberarchitecture, the better.
  - extension 16y ago
    Model-UI separation is a pretty basic principle that decent programmers put into practice every day. I find it tends to aid the design process rather than obstruct it.
  - stcredzero 16y ago
    Separating the domain from the UI is just common sense and good business practice. Having the two melded is probably the most common way for companies to get stuck using an old application. Their business logic (the real value) is stuck in a glob of UI outdated code (which no one cares about anymore). I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly. I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.
patio11 16y ago
No, they are not becoming irrelevant. Frameworks add significant value on the front end as well -- the easiest example is templating, which is a) not natively supported in HTML b) hard to fake with CSS/Javascript and c) virtually required for productivity, consistency, and maintainability. I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination of Apache and your script is morally equivalent to a server-side web framework. Session management. Cookies. Sitewide functionality. Asset packing. SSL. Debugging/development tools. Tests. etc, etc, etc, etc
- jules 16y ago
  There are tools for templating with Javascript, for example https://github.com/jquery/jquery-tmpl https://github.com/jquery/jquery-tmpl I can imagine that's not so good for search engines.
  - castis 16y ago
    I still, for the life of me, cannot understand why this is used. Why would you leave the users environment responsible for templating?
    - jules 16y ago
      I don't really get it either, but one reason I can think of is that it saves some bandwidth because sending the data that gets inserted into the template will probably be smaller than the HTML after templating.
      - turtle4 16y ago
        That seems counter intuitive to me. With JS templating, you are sending all the page structure, data, and markers as to how to insert the data into the structure. Without, you are just sending the structure and data. Assuming you are gzipping the output in both cases, which would eliminate the bandwidth of the duplicated structure items, wouldn't the JS templating naturally be longer?
ehutch79 16y ago
uh, if you stop working with server side frameworks, how do you serve information to the front end javascript framework? do you intend to just expose your database to the end user's browser?
- alttab 16y ago
  You've then just moved all data processing to the front-end, and the MVC framework moves into the client. You are then charging the consumer a tax for the processing and battery power of a presentation that could have been served with an infrastructure designed to handle it. Moving UI to the client does nothing but move the UI to the client - it still has to be done and Javascript performance varies too much for this to be the catch-all option right now.
  - dstein 16y ago
    It's about moving the generation of HTML to the client. The concept of rendering the UI (using HTML) on the server was a step backward right from the beginning of the WWW. Servers are simply not needed to construct HTML. I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks -- Ruby, PHP, Java, will essentially only be for shuffling data from your database to your client. The way it should have been all along.
    - alttab 16y ago
      The point I was trying to make was that on mobile devices where computing power and battery power is a limited resource, not only will it be running significantly more Javascript, but it would also have to render the view - effectively doubling the number of client-side tasks. If all the device had to do was consume HTML and render it, it would impact performance and battery life less. Also, if you build your entire page in Javascript, you could see as much as 50% difference in page load performance across browsers. Until most users that still browse with IE are on a version that is at least as fast as Firefox, you're allowing client experience to vary wildly outside of your control. Basically, you control how you serve your content, but you have no control over how fast the client builds HTML from server-data. In 5 years this may not be an issue, but right now it is. The more work you do on your own infrastructure, the more stable your service would become. Now, I'm still a fan of single-page apps, but for initial page loads it still makes sense from a performance perspective to render it on the server.
extension 16y ago
Even if single-page AJAX becomes the standard for web apps, I don't see apps ever becoming the exclusive form of content on the web. It will always be mostly passive text, images, video, audio, etc. for which the thin client model is perfectly suited.
pilif 16y ago
It might be very tempting to just use a REST API and a JS client for your web application. With the _escaped_fragment_ technique, you can even get indexed by Google (I'm not sure whether the other search engines already do this, but Google still is good for 90% of my search referrals, so it's ok for me). The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afterwards (and maybe missing some stuff that can only be done in the web client). Not only that, by the statelessness of REST you get really good scalability: Each request is independent of each other request, so you should be able to just add frontend- and backend-servers as you see fit without having to worry about global state. Still, after having done just that (build a web application that is nothing but a JS frontend to a REST API - quite like the new twitter) with http://tempalias.com http://tempalias.com (source is available), I can tell you that it's not all rainbows and unicorns to misuse that saying once more. One thing is Sammy, the client-side framework I used. It's quite easy to get lost in one big heap of application that's very hard to maintain. That is totally my mistake though and with a bit of additional experience and some help of require.js or something, I could fix that. The other thing is UI. People are still used to the browsers page-loading-paradigm. In that case, the browsers themselves provide status update during requests. With AJAX, you'll have to do your own loading indicators and every site does it differently and no site as fine-grained as browsers (Connected, Waiting for reply, Loading... etc). While the granularity of notifications can be fixed (best is to leave it as a single notification, but respond really quickly), you still don't solve the problem that it looks different on every site. This is a general problem of pure-AJAX sites. Newtwitter suffers from this. Lately it's quite slow for me and I'm constantly wondering whether some JS has crashed or whether it is just slow. And finally, sometimes, you have to do really convoluted solutions for problems which could ever-so-easily be solved by just being able to send a few dynamically generated bytes. Of course, you could cave in and chose the impure solution, but I didn't want to which caused me some headache in my case, like not having access to the hostname of the <script src>'d bookmarklet runner script (https://github.com/pilif/tempalias/blob/master/public/bookmarklet.js https://github.com/pilif/tempalias/blob/master/public/bookma...) which I now have to pass in on bookmarklet invocation. To be honest though, over time, we'll learn to cope with such issues (and browsers might get a bit better in notifying users about AJAX connections going on) and at that point the advantages could really get into play. After tempalias which was a personal fun-project, we decided to reuse this rest-only architecture for a project my company is currently working on, fully prepared to deal with the issues outlined here because, really, we believe that the benefits might well outweigh the issues.
dasil003 16y ago
It's probably just a question of server-side frameworks being more mature at this point in time, and client-side logic being a more fertile ground for innovation due to longstanding cross-platform roadblocks. A client-server architecture is always a balancing act, and it's just teetering a bit towards the client side at the moment. The future is being able to divide work arbitrarily between front-end and back-end depending on the particular needs of your application.
bambax 16y ago
I think yes, serverside web frameworks may be becoming less relevant, to a certain extent; I just finished a monitoring app for a small company that is entirely in JS, with data stored on the server and computations (graphs, etc.) done on the fly by the client (it's an internal business app, so I get to tell end users what browser to use, etc.) - - - A counter argument is that it's considered "better" to bring the computation to the data than the data to the computation: ie, make the server calculate everything and serve it to a dumb client, because: 1) the server is more powerful than the client 2) one never knows what the client is capable of (the developers don't control the clients), there are many clients and just one server 3) usually, any given calculation only uses part of the data, so if the server computes and sends the results, it makes for smaller data transfers There is however a big counter-counter-argument: I pay for the server, you pay for the client. When there are many clients that ask for results that are not easily cacheable, I think it can be much simpler to just have a dumb server that serves data, and compute on the client.
jchrisa 16y ago
I haven't used a server side framework (other than a few CouchDB server-side JavaScript features) for years. The biggest reason given for keeping a server side component around is that you need some way to serve up data to the UI. So until people converge on RESTful data stores there will continue to be a place for application-specific server side code.
prodigal_erik 16y ago
This trend will be the death of the open content web. Almost nobody out there has the diligence to maintain a standard, documented API when they have the alternative of changing their own client-side code at whim (and breaking any code anyone else may have written). In some ways Lisp was wrong about "code is data"--data is far easier to analyze and repurpose, so obfuscating it behind code is a step backwards.
geebee 16y ago
This is an interesting question. If we really do get that separation of UI, then I think web-based frameworks that are heavily based on MVC+ORM will change dramatically... The author does mention Rails as one of the server-side frameworks... but RESTful services are incredibly easy to do with rails. You don't have to use the view tier at all to use rails - you can instruct the controllers to simply provide a RESTful interface to the controller methods and then go off and build whatever separate UI you please... so I could easily still see myself using Rails even if I don't need a view tier (for the moment, this is what I'd do if I had to build a RESTful interface and I didn't have to use Java...). On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2.
- kls 16y ago
  On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2. I have used all of them and I prefer by far the JAX-RS frameworks like Jersey. They are lightweight but provide a lot of power when developing REST services in Java.
  - geebee 16y ago
    Hey thanks, I'll check that out. They (cxf and axis2) do feel a little heavyweight when all I want to do is expose a method through REST.
bni 16y ago
Some big wins for doing client side UI in webapps: 1. Less latency for the user when navigating the app. Data only updated from REST services as needed. Update when user looks at something else. Tons of optimizations possible. 2. Available offline (Cache manifest). Webapp useable even when 3G signal is lost. 3. Mobile app using PhoneGap with the same code base. Just drop the index.html and js/css files into the www folder. 4. UI can be developed and run from disk, with file:// protocol, no web server needed. No build or network copy step, just open/reload directly from project dir. CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense.
- kls 16y ago
  CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense. I can't agree more, we have wasted 15 years trying to hide our heads from that truth but the reality is it produces a superior experience and it is a easier development strategy. We consistently produce better applications on shorter development cycles with JS based UI apps.
extension 16y ago
For those referring to "REST APIs" as part of single-page apps: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Point being, if your AJAX app is built in the typical fashion, it is very unlikely to be at all RESTful itself. It is however enjoying the many benefits of being built on top of a RESTful protocol (HTML), like running in any standard web browser without any pre-deployed client software.
skillguru 16y ago
No they cannot be. All the complex processing cannot go to web. The web has to be light weight. Then there are messaging systems and other systems with which integration has to happen
JayGodse21 16y ago
I don't think that server side frameworks will become irrelevant. There is still a lot of value they add between the database and the HTTP interface. The part that will become irrelevant is the servlet/ASP/JSP/ERB and similar view-layers, where page-rendering policy is executed on the server. With more & more clients getting ever more powerful processors (including iPhone, Blackberry, Palm and Android), the client can do the job of executing the page-rendering policy. This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS). Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers). The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.

36 points by Garbage 16y ago

r0h4n 16y ago

If smartphones keep getting faster cpu's , then it is there is no problem to process data on the client, and use the server just as a dumb data spitter.

roder 16y ago

I've tried to accomplish a REST API + JS client on a few of my projects, but where I get hung up is session handling. What I've ended up doing is writing the REST backend and writing the presentation layer in something light, like flask or sinatra, just for session handling.

pilif 16y ago
you shouldn't need to do session handling if you are going REST. Rest is all about not having state. If you need authentication, authenticate on every request. If your request needs some additional info to give a response, pass that information in when sending the request. It's really a different paradigm and sometimes it can get really painful to move away from the way of thinking that we are used to.
- roder 16y ago
  I realize that you don't want to maintain state in a REST api. It's not that it's painful to do something I'm use too (ie: session handling), it's just its painful implementing. My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
necubi 16y ago
How I've done it is something like this: (1) Client sends auth info to backend server (2) Server sets auth cookie on client (3) Every request goes through a proxy written in Ruby/EventMachine which either just passes through the request to the backend server if requesting something public or first checks that the client's auth cookie is valid if its requesting protected resources. This certainly isn't as simple as it would be in a server-side framework, but otherwise it works pretty well.

staktrace 16y ago

I agree, this does appear to be the trend. Google also has indexing support for AJAX pages (http://code.google.com/web/ajaxcrawling/index.html http://code.google.com/web/ajaxcrawling/index.html) so it's not hard to make a single-page app that is indexable by Google. My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that. One potential pitfall I can think of is cookie management - the JavaScript APIs to manipulate cookies is very poorly defined easy to make mistakes while using. I think this is doable but we need to tread softly to make sure that we don't introduce new classes of vulnerabilities.

__Joker 16y ago
"My concern is that we are building all of this on top of HTTP, which wasn't really meant to be used this way, and there's bound to be some caveats from that". Can you ( or anybody ) expand on this ?

stcredzero 16y ago

One good thing about JS and a REST backend: there will finally be widespread separation of UI and domain!

cletus 16y ago
This whole separation of UI and domain is the kind of Ivory Tower academic nonsense perpetuated by the DDD folks and many, many others. Nowhere is this virulent plague more endemic than in the Java world. As the joke goes, the Java programmer's response to any problem is to add just one more layer of abstraction. And I say this as a Java programmer of some 10+ years experience so please don't take it as mindless Java bashing. As Joel (the classic Joel of old) would say: all abstractions are leaky. To add my own editorial: the less hand-wringing and self-flagellation about the purity of the uberlanguage, uberframework or uberarchitecture, the better.
- extension 16y ago
  Model-UI separation is a pretty basic principle that decent programmers put into practice every day. I find it tends to aid the design process rather than obstruct it.
- stcredzero 16y ago
  Separating the domain from the UI is just common sense and good business practice. Having the two melded is probably the most common way for companies to get stuck using an old application. Their business logic (the real value) is stuck in a glob of UI outdated code (which no one cares about anymore). I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly. I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.

patio11 16y ago

No, they are not becoming irrelevant. Frameworks add significant value on the front end as well -- the easiest example is templating, which is a) not natively supported in HTML b) hard to fake with CSS/Javascript and c) virtually required for productivity, consistency, and maintainability. I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination of Apache and your script is morally equivalent to a server-side web framework. Session management. Cookies. Sitewide functionality. Asset packing. SSL. Debugging/development tools. Tests. etc, etc, etc, etc

jules 16y ago
There are tools for templating with Javascript, for example https://github.com/jquery/jquery-tmpl https://github.com/jquery/jquery-tmpl I can imagine that's not so good for search engines.
- castis 16y ago
  I still, for the life of me, cannot understand why this is used. Why would you leave the users environment responsible for templating?
  - jules 16y ago
    I don't really get it either, but one reason I can think of is that it saves some bandwidth because sending the data that gets inserted into the template will probably be smaller than the HTML after templating.
    - turtle4 16y ago
      That seems counter intuitive to me. With JS templating, you are sending all the page structure, data, and markers as to how to insert the data into the structure. Without, you are just sending the structure and data. Assuming you are gzipping the output in both cases, which would eliminate the bandwidth of the duplicated structure items, wouldn't the JS templating naturally be longer?

ehutch79 16y ago

uh, if you stop working with server side frameworks, how do you serve information to the front end javascript framework? do you intend to just expose your database to the end user's browser?

alttab 16y ago
You've then just moved all data processing to the front-end, and the MVC framework moves into the client. You are then charging the consumer a tax for the processing and battery power of a presentation that could have been served with an infrastructure designed to handle it. Moving UI to the client does nothing but move the UI to the client - it still has to be done and Javascript performance varies too much for this to be the catch-all option right now.
- dstein 16y ago
  It's about moving the generation of HTML to the client. The concept of rendering the UI (using HTML) on the server was a step backward right from the beginning of the WWW. Servers are simply not needed to construct HTML. I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks -- Ruby, PHP, Java, will essentially only be for shuffling data from your database to your client. The way it should have been all along.
  - alttab 16y ago
    The point I was trying to make was that on mobile devices where computing power and battery power is a limited resource, not only will it be running significantly more Javascript, but it would also have to render the view - effectively doubling the number of client-side tasks. If all the device had to do was consume HTML and render it, it would impact performance and battery life less. Also, if you build your entire page in Javascript, you could see as much as 50% difference in page load performance across browsers. Until most users that still browse with IE are on a version that is at least as fast as Firefox, you're allowing client experience to vary wildly outside of your control. Basically, you control how you serve your content, but you have no control over how fast the client builds HTML from server-data. In 5 years this may not be an issue, but right now it is. The more work you do on your own infrastructure, the more stable your service would become. Now, I'm still a fan of single-page apps, but for initial page loads it still makes sense from a performance perspective to render it on the server.

extension 16y ago

Even if single-page AJAX becomes the standard for web apps, I don't see apps ever becoming the exclusive form of content on the web. It will always be mostly passive text, images, video, audio, etc. for which the thin client model is perfectly suited.

pilif 16y ago

It might be very tempting to just use a REST API and a JS client for your web application. With the _escaped_fragment_ technique, you can even get indexed by Google (I'm not sure whether the other search engines already do this, but Google still is good for 90% of my search referrals, so it's ok for me). The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afterwards (and maybe missing some stuff that can only be done in the web client). Not only that, by the statelessness of REST you get really good scalability: Each request is independent of each other request, so you should be able to just add frontend- and backend-servers as you see fit without having to worry about global state. Still, after having done just that (build a web application that is nothing but a JS frontend to a REST API - quite like the new twitter) with http://tempalias.com http://tempalias.com (source is available), I can tell you that it's not all rainbows and unicorns to misuse that saying once more. One thing is Sammy, the client-side framework I used. It's quite easy to get lost in one big heap of application that's very hard to maintain. That is totally my mistake though and with a bit of additional experience and some help of require.js or something, I could fix that. The other thing is UI. People are still used to the browsers page-loading-paradigm. In that case, the browsers themselves provide status update during requests. With AJAX, you'll have to do your own loading indicators and every site does it differently and no site as fine-grained as browsers (Connected, Waiting for reply, Loading... etc). While the granularity of notifications can be fixed (best is to leave it as a single notification, but respond really quickly), you still don't solve the problem that it looks different on every site. This is a general problem of pure-AJAX sites. Newtwitter suffers from this. Lately it's quite slow for me and I'm constantly wondering whether some JS has crashed or whether it is just slow. And finally, sometimes, you have to do really convoluted solutions for problems which could ever-so-easily be solved by just being able to send a few dynamically generated bytes. Of course, you could cave in and chose the impure solution, but I didn't want to which caused me some headache in my case, like not having access to the hostname of the <script src>'d bookmarklet runner script (https://github.com/pilif/tempalias/blob/master/public/bookmarklet.js https://github.com/pilif/tempalias/blob/master/public/bookma...) which I now have to pass in on bookmarklet invocation. To be honest though, over time, we'll learn to cope with such issues (and browsers might get a bit better in notifying users about AJAX connections going on) and at that point the advantages could really get into play. After tempalias which was a personal fun-project, we decided to reuse this rest-only architecture for a project my company is currently working on, fully prepared to deal with the issues outlined here because, really, we believe that the benefits might well outweigh the issues.

dasil003 16y ago

It's probably just a question of server-side frameworks being more mature at this point in time, and client-side logic being a more fertile ground for innovation due to longstanding cross-platform roadblocks. A client-server architecture is always a balancing act, and it's just teetering a bit towards the client side at the moment. The future is being able to divide work arbitrarily between front-end and back-end depending on the particular needs of your application.

bambax 16y ago

I think yes, serverside web frameworks may be becoming less relevant, to a certain extent; I just finished a monitoring app for a small company that is entirely in JS, with data stored on the server and computations (graphs, etc.) done on the fly by the client (it's an internal business app, so I get to tell end users what browser to use, etc.) - - - A counter argument is that it's considered "better" to bring the computation to the data than the data to the computation: ie, make the server calculate everything and serve it to a dumb client, because: 1) the server is more powerful than the client 2) one never knows what the client is capable of (the developers don't control the clients), there are many clients and just one server 3) usually, any given calculation only uses part of the data, so if the server computes and sends the results, it makes for smaller data transfers There is however a big counter-counter-argument: I pay for the server, you pay for the client. When there are many clients that ask for results that are not easily cacheable, I think it can be much simpler to just have a dumb server that serves data, and compute on the client.

jchrisa 16y ago

I haven't used a server side framework (other than a few CouchDB server-side JavaScript features) for years. The biggest reason given for keeping a server side component around is that you need some way to serve up data to the UI. So until people converge on RESTful data stores there will continue to be a place for application-specific server side code.

prodigal_erik 16y ago

This trend will be the death of the open content web. Almost nobody out there has the diligence to maintain a standard, documented API when they have the alternative of changing their own client-side code at whim (and breaking any code anyone else may have written). In some ways Lisp was wrong about "code is data"--data is far easier to analyze and repurpose, so obfuscating it behind code is a step backwards.

geebee 16y ago

This is an interesting question. If we really do get that separation of UI, then I think web-based frameworks that are heavily based on MVC+ORM will change dramatically... The author does mention Rails as one of the server-side frameworks... but RESTful services are incredibly easy to do with rails. You don't have to use the view tier at all to use rails - you can instruct the controllers to simply provide a RESTful interface to the controller methods and then go off and build whatever separate UI you please... so I could easily still see myself using Rails even if I don't need a view tier (for the moment, this is what I'd do if I had to build a RESTful interface and I didn't have to use Java...). On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2.

kls 16y ago
On the Java side, I think that if all I needed to do was create a RESTful interface, I probably wouldn't bother with Struts2 (or SpringMVC, or other java-specific MVC tiers). I probably would just go with CXF or Axis2. I have used all of them and I prefer by far the JAX-RS frameworks like Jersey. They are lightweight but provide a lot of power when developing REST services in Java.
- geebee 16y ago
  Hey thanks, I'll check that out. They (cxf and axis2) do feel a little heavyweight when all I want to do is expose a method through REST.

bni 16y ago

Some big wins for doing client side UI in webapps: 1. Less latency for the user when navigating the app. Data only updated from REST services as needed. Update when user looks at something else. Tons of optimizations possible. 2. Available offline (Cache manifest). Webapp useable even when 3G signal is lost. 3. Mobile app using PhoneGap with the same code base. Just drop the index.html and js/css files into the www folder. 4. UI can be developed and run from disk, with file:// protocol, no web server needed. No build or network copy step, just open/reload directly from project dir. CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense.

kls 16y ago
CGI, and its followers, were a big ugly hack from the beginning, that is now institutionalized in many developers minds. UI belong on the client, as close to the user as possible, its just common sense. I can't agree more, we have wasted 15 years trying to hide our heads from that truth but the reality is it produces a superior experience and it is a easier development strategy. We consistently produce better applications on shorter development cycles with JS based UI apps.

extension 16y ago

For those referring to "REST APIs" as part of single-page apps: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Point being, if your AJAX app is built in the typical fashion, it is very unlikely to be at all RESTful itself. It is however enjoying the many benefits of being built on top of a RESTful protocol (HTML), like running in any standard web browser without any pre-deployed client software.

skillguru 16y ago

No they cannot be. All the complex processing cannot go to web. The web has to be light weight. Then there are messaging systems and other systems with which integration has to happen

JayGodse21 16y ago

I don't think that server side frameworks will become irrelevant. There is still a lot of value they add between the database and the HTTP interface. The part that will become irrelevant is the servlet/ASP/JSP/ERB and similar view-layers, where page-rendering policy is executed on the server. With more & more clients getting ever more powerful processors (including iPhone, Blackberry, Palm and Android), the client can do the job of executing the page-rendering policy. This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS). Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers). The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.