Are Serverside Web Frameworks Becoming Irrelevant? • Hacker News Board

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#21

Post by bambax » Mon, Nov 08, 2010, 5:03 PM UTC

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#22

Post by peregrine » Mon, Nov 08, 2010, 5:21 PM UTC

castis wrote: post #17

jules wrote: post #7

Earlier quoted context omitted.

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.

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

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#23

Post by bgrins » Mon, Nov 08, 2010, 5:21 PM UTC

castis wrote: post #17

jules wrote: post #7

Earlier quoted context omitted.

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.

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

I don't think that it is useful for a standard site, one that needs to be indexed by search engines and needs all of it's content to be available on page load. I have made use of it in single page web applications before, though.

It completely blows hand generation of HTML out of the water for maintainability. You can keep your templates inside of the HTML page using a element with a special type, and keeps a lot of that view logic out of your JavaScript. It also provides a nice alternative to using a hidden element and cloning it, then switching attributes, text, and values.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#24

Post by turtle4 » Mon, Nov 08, 2010, 5:24 PM UTC

jules wrote: post #19

castis wrote: post #17

Earlier quoted context omitted.

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

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.

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?

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#25

Post by jchrisa » Mon, Nov 08, 2010, 5:27 PM UTC

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#26

Post by r0h4n » Mon, Nov 08, 2010, 5:28 PM UTC

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#27

Post by prodigal_erik » Mon, Nov 08, 2010, 5:38 PM UTC

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#28

Post by bgrins » Mon, Nov 08, 2010, 5:44 PM UTC

turtle4 wrote: post #24

jules wrote: post #19

Earlier quoted context omitted.

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.

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?

Here is a contrived example, that shows the pros and cons of each, as I see them. Pretend you have an 'link' object in JavaScript and you want to generate the view for that link using templating:

  var link = { url: 'http://news.ycombinator.com, title: 'Hacker News' , extraStuff: someBigObject };

With JS templating:

  ${title}

  $('#template').tmpl(link);

* Pros: if you have to generate 100 links, you only passed down the template div once. Also, if the extraStuff property is really large, there is no bandwidth spent on sending it up, since it runs on the page

* Cons: if you generate 0 links, you still passed down the template div once. If you have this view defined also in a server side template, you have duplicated view logic (really annoying).

With server side templating:

  $.load('url/to/template', link);

* Pros: If you generate 0 links, no extra data is sent or received. Also, your view logic is all in one place (on the server).

* Cons: If you generate 100 links, there are 100 extra HTTP requests, and you have to deal with timeouts, loading indicators, etc.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#29

Post by __Joker » Mon, Nov 08, 2010, 6:21 PM UTC

staktrace wrote: post #3

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 cook…

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

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#30

Post by geebee » Mon, Nov 08, 2010, 7:42 PM UTC

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.