4 ms·

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

by 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.
- auxbuss 16y ago
  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.
kls 16y ago
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.

by dstein 16y ago

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.

auxbuss 16y ago
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.

kls 16y ago

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.