

Are Serverside Web Frameworks Becoming Irrelevant? - Garbage
http://blog.recursivity.com/post/1372343840/are-serverside-web-frameworks-becoming-irrelevant

======
patio11
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
There are tools for templating with Javascript, for example
<https://github.com/jquery/jquery-tmpl>

I can imagine that's not so good for search engines.

~~~
castis
I still, for the life of me, cannot understand why this is used. Why would you
leave the users environment responsible for templating?

~~~
peregrine
Say you have a site that uses a lot of AJAX to make similar calls. Say for
instance send message, recieve message. Instead of sending the entire message
formatting and all back and forth you send json objects and bind them to
jquery templates.

~~~
lolyaright
don't forget to herp before you derp!

Seriously, the whole concept he was trying to convey just whooshed over your
head so loudly that I could hear it from my home in Maine.

------
pilif
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> (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/bookma...](https://github.com/pilif/tempalias/blob/master/public/bookmarklet.js))
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.

~~~
kls
_It's quite easy to get lost in one big heap of application that's very hard
to maintain_

A lot of the issues that you outlines can be dealt with by proper toolkit
selection. It sounds to me that you have outgrown the jQuery (and other small
rapid to develop in toolkits) and need something more robust. As it sits there
are really only two players in the top end game and they are Ext and Dojo. Of
the two I prefer Dojo for a host of reasons. But almost everything you have
outlined are covered by both toolkits. If you are trying to build full on web
apps the smaller toolkits are not a good choice as you are continually having
to bolt on features. Whereas the larger toolkits have application architecture
built into them.

~~~
paulobsf
jQuery alone doesn't give you the structure you need to build HTML + CSS + JS
"Fat Clients" but, these do: \- <http://documentcloud.github.com/backbone/> \-
<http://code.quirkey.com/sammy/>

~~~
kls
Right, I mentioned BackBone in one of my other posts. You can bold on what you
need to jQuery via some supporting projects, but many of the supporting
projects are not at the maturity level of some of the larger toolkits. I do
like BackBone but prefer to use Dojo's approach when it comes to large apps.
jQuery can still be utilized with Dojo as well, where dojo provides all of the
application architecture services and jQuery provides the UI services.

------
bni
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
_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.

------
roder
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
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
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.

------
dasil003
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
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.

------
geebee
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
_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
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.

------
JayGodse21
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.

------
extension
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.

------
ehutch79
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
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
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
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.

~~~
auxbuss
Go and have a look at, say, Sammy. There is not a lot of heavy duty stuff gong
on in JS-land. Particularly on a phone, the amount of JS required is tiny;
certainly not enough to impact power consumption unless one is completely
incompetent.

Also, try phonegap or jquerymobile. Tons of functionality that is immediate
and battery friendly.

You _can_ do this stuff badly, but that's not what we're talking about here.

------
staktrace
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>) 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
"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 ?

------
extension
For those referring to "REST APIs" as part of single-page apps:

[http://roy.gbiv.com/untangled/2008/rest-apis-must-be-
hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-
driven)

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.

------
prodigal_erik
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.

------
jchrisa
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.

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

~~~
cletus
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.

~~~
stcredzero
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.

------
skillguru
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

------
r0h4n
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.

