Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are Serverside Web Frameworks Becoming Irrelevant?

blog.recursivity.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#31

Post by jules »

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?

The difference is that with server rendered templates you're sending the structure multiple times. For example if you're displaying a list of things, you have a list of n times structure + n times data. If you do it at the client side you have 1 times structure + n times data.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#32

Post by lolyaright »

peregrine wrote: post #22
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?

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.

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#33

Post by alttab »

dstein wrote: post #20
alttab wrote: post #10

Earlier quoted context omitted.

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…

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…

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#34

Post by 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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#35

Post by kls »

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 know for the life of me why you would use either for static templating, use a CMS that publishes flat HTML files to your server farm. It reduces a lot of run-time dependencies and requirements and makes them compile-time concerns. Which as a general rule of thumb is better. For the dynamic stuff well that is where you draw your line server or client. I have become a convinced fan of the client.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#36

Post by kls »

pilif wrote: post #12

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

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#37

Post by kls »

bni wrote: post #34

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

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#38

Post by kls »

geebee wrote: post #30

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…

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.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#39

Post by kls »

dstein wrote: post #20
alttab wrote: post #10

Earlier quoted context omitted.

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…

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…

that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete

One thing often overlooked with these is that they lock your application away into islands of incompatibility. If you decide to port from one technology to another you have to go through a tedious process of porting these non compatible technologies. With a front end built entirely in JS, CSS and HTML you bring you UI back to a common technology base that can easily move from technical selection to technical selection.

Re: Are Serverside Web Frameworks Becoming Irrelevant?

#40

Post by geebee »

kls wrote: post #38
geebee wrote: post #30

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…

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.

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.
Post reply on HN