I'm currently working on a site that uses react/flux with some use of media queries and size detection for rendering... effectively the phone and portrait tablet displays will be similar, and the desktop and large displays will also be similar... I'd prefer to be able to break this into two camps for the initial html sent to the browser (via server-side rendering) This way less is sent to the phone/tablet browsers to render initially... and less jarring change as other features load after initial display.
The only way to do this is browser sniffing.. although minimal.. for the most part if "phone" or "mobile" are in the browser I can send the lighter phone version... otherwise they initially get the desktop view. It isn't perfect, and to be honest, I'm doing more detection than just that.
There's also issues with where/when I can cash rendered output. And when/where I can cash certain results. For example the record id's for a given search will cache the first 10k id's so that paging becomes very fast, with the results limited to that set. Other queries will also be cached.
It really depends on what you are trying to do... growing from a few thousand users to millions takes some effort, planning, and thoughtfulness that isn't always the same.
The way I would design an app for a few hundred internal users isn't the same as for a public site, isn't the same for a very busy public site. You have to make trade offs or collapse.
Why should a phone user on a strained 3g connection get the content for a desktop browser.... By the same token, I HATE when I get a search result for a page on my phone, and that site redirects me to m.site.com/ (no path after /)... I don't just design/develop web based applications, I'm also a user...
The only way to do this is browser sniffing.. although minimal.. for the most part if "phone" or "mobile" are in the browser I can send the lighter phone version... otherwise they initially get the desktop view. It isn't perfect, and to be honest, I'm doing more detection than just that.
There's also issues with where/when I can cash rendered output. And when/where I can cash certain results. For example the record id's for a given search will cache the first 10k id's so that paging becomes very fast, with the results limited to that set. Other queries will also be cached.
It really depends on what you are trying to do... growing from a few thousand users to millions takes some effort, planning, and thoughtfulness that isn't always the same.
The way I would design an app for a few hundred internal users isn't the same as for a public site, isn't the same for a very busy public site. You have to make trade offs or collapse.
Why should a phone user on a strained 3g connection get the content for a desktop browser.... By the same token, I HATE when I get a search result for a page on my phone, and that site redirects me to m.site.com/ (no path after /)... I don't just design/develop web based applications, I'm also a user...