4 ms·

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 l

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

by mbleigh 13y ago

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