4 ms·

Congratulations. With this arbitrary limitation you just eliminated the cheapest, most scalable and most simple part of the entire web application - HTML templa

Congratulations. With this arbitrary limitation you just eliminated the cheapest, most scalable and most simple part of the entire web application - HTML template rendering, to replace it with fragile and invisible to search engines JavaScript logic. I believe people in firm grasp of their common sense would take the practical hybrid approach and do what makes sense for each specific scenario, rather than rely on ideology to architect their app for them.

mbleigh 13y ago
If you're running a mostly-public content site that depends largely on search engine traffic, static is probably not the way to go (yet). If your application lives mostly inside of a login, there's little reason to force yourself to render HTML from the server rather than building reusable APIs that can be shared across web, mobile, etc.
- mantrax4 13y ago
  False dichotomy. Building reusable APIs has nothing to do with forcing yourself to consume them with client-side JS. Maybe that approach works as a training wheels type of guide for developers who can't stay focused, but a service layer is pretty much the norm for any competently written web app, whether a particular API call is materialized with client-side or server-side view rendering. Few additional points about thinking intranet apps get a pass for being intranet: 1. Even on the intranet, it's good for people to be able to bookmark specific point of their navigation and query type (i.e. page, sorting order, filtering criteria, via URL query); it matches how they use the web, and improves their workflows and performance. People don't react well when the web app you developed just decided to pick up all the limitation of native apps, with none of the benefits of a native app (native UI, performance, OS integration etc.). Don't make it a crappy wanna-be-real-app web app, just make it a good web app, acting like a web app. Now, sure, if you try really heard, you can emulate it with a big number of static pages (so it works when you refresh) and manually synching everything with the browser History API, but whoops, you just blew your budget, deadline and doubled the number of tests your app needs to pass QA checks since your app now has complicated history management where it didn't need any (aside form ideology), instead of letting the browser and server work it out using the good old school ways of handling page state. 2. It's pointless waste to develop two set of practices, tools and processes for creating & maintaining public apps, vs. internal apps. What for? Feeling good inside that you saved 3% CPU on the server in view rendering? Please. I've gotten people fired over insisting on using their own pet practices like these (with no provable real-world benefit) over common sense, and wasting the business time and money. 3. In my practical the line between an intranet app and Internet apps is thing. So if an internal app becomes public (in a limited or full-blown capacity), it's a good idea you don't have to drop all the UI code and start over, mkay. I write intranet apps for a living (they mix server-side and client-side rendering).
  - mbleigh 13y ago
    I wasn't referring to intranet vs. internet apps, but rather apps that generate public content that can be viewed without authentication (e.g. Twitter) vs. apps whose information is entirely restricted to authenticated users (e.g. GMail). Basically: does the app generate stuff that needs to be crawled by a search engine? While client-side routing and state preservation used to be a very difficult thing, these days it's actually pretty straightforward (ngRoute, Backbone router, Ember router, etc).
Joeri 13y ago
The most scalable way of rendering templates is doing it on the client, since that means users get a dedicated machine for rendering the templates.
- mantrax4 13y ago
  You're confusing server CPU usage with scalability and performance. HTML template rendering on either the server or client is embarassingly parallel, as it just takes a viewmodel (basically) and populates a template of HTML with its variables, with zero other calls and dependencies. You can scale this particular step to infinite number of servers, without any bottleneck appearing (hence, it's horizontally scalable). And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach. Request/response lag is critical in the way an app is perceived. Also when it comes to CPU, as I already said in my previous response, view rendering is the cheapest step computationally you have in an app. Any other service takes more time and resources than that. So view rendering is never the bottleneck, and "optimizing" it away with complicated client-side shenanigans is the very definition of premature optimization.
  - bhantol 13y ago
    "And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach." Nope. The template fetch is only the first time. Because the template/HTML is either cached on the browser or is compiled/inlined with the Javascript with the build pipelines. "Request/response lag is critical in the way an app is perceived." Yes it is and it is worse with server rendered pages. A typical size of a page fully dynamically generated on the server side could be a few times larger than that fetching of data/content.

mbleigh 13y ago

If you're running a mostly-public content site that depends largely on search engine traffic, static is probably not the way to go (yet). If your application lives mostly inside of a login, there's little reason to force yourself to render HTML from the server rather than building reusable APIs that can be shared across web, mobile, etc.

mantrax4 13y ago
False dichotomy. Building reusable APIs has nothing to do with forcing yourself to consume them with client-side JS. Maybe that approach works as a training wheels type of guide for developers who can't stay focused, but a service layer is pretty much the norm for any competently written web app, whether a particular API call is materialized with client-side or server-side view rendering. Few additional points about thinking intranet apps get a pass for being intranet: 1. Even on the intranet, it's good for people to be able to bookmark specific point of their navigation and query type (i.e. page, sorting order, filtering criteria, via URL query); it matches how they use the web, and improves their workflows and performance. People don't react well when the web app you developed just decided to pick up all the limitation of native apps, with none of the benefits of a native app (native UI, performance, OS integration etc.). Don't make it a crappy wanna-be-real-app web app, just make it a good web app, acting like a web app. Now, sure, if you try really heard, you can emulate it with a big number of static pages (so it works when you refresh) and manually synching everything with the browser History API, but whoops, you just blew your budget, deadline and doubled the number of tests your app needs to pass QA checks since your app now has complicated history management where it didn't need any (aside form ideology), instead of letting the browser and server work it out using the good old school ways of handling page state. 2. It's pointless waste to develop two set of practices, tools and processes for creating & maintaining public apps, vs. internal apps. What for? Feeling good inside that you saved 3% CPU on the server in view rendering? Please. I've gotten people fired over insisting on using their own pet practices like these (with no provable real-world benefit) over common sense, and wasting the business time and money. 3. In my practical the line between an intranet app and Internet apps is thing. So if an internal app becomes public (in a limited or full-blown capacity), it's a good idea you don't have to drop all the UI code and start over, mkay. I write intranet apps for a living (they mix server-side and client-side rendering).
- mbleigh 13y ago
  I wasn't referring to intranet vs. internet apps, but rather apps that generate public content that can be viewed without authentication (e.g. Twitter) vs. apps whose information is entirely restricted to authenticated users (e.g. GMail). Basically: does the app generate stuff that needs to be crawled by a search engine? While client-side routing and state preservation used to be a very difficult thing, these days it's actually pretty straightforward (ngRoute, Backbone router, Ember router, etc).

Joeri 13y ago

The most scalable way of rendering templates is doing it on the client, since that means users get a dedicated machine for rendering the templates.

mantrax4 13y ago
You're confusing server CPU usage with scalability and performance. HTML template rendering on either the server or client is embarassingly parallel, as it just takes a viewmodel (basically) and populates a template of HTML with its variables, with zero other calls and dependencies. You can scale this particular step to infinite number of servers, without any bottleneck appearing (hence, it's horizontally scalable). And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach. Request/response lag is critical in the way an app is perceived. Also when it comes to CPU, as I already said in my previous response, view rendering is the cheapest step computationally you have in an app. Any other service takes more time and resources than that. So view rendering is never the bottleneck, and "optimizing" it away with complicated client-side shenanigans is the very definition of premature optimization.
- bhantol 13y ago
  "And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach." Nope. The template fetch is only the first time. Because the template/HTML is either cached on the browser or is compiled/inlined with the Javascript with the build pipelines. "Request/response lag is critical in the way an app is perceived." Yes it is and it is worse with server rendered pages. A typical size of a page fully dynamically generated on the server side could be a few times larger than that fetching of data/content.