8 ms·

I agree that Modern Web Applications are here. The key point is that they don't have to be architected the same as Battlelog to be considered modern. Most of u

I agree that Modern Web Applications are here. The key point is that they don't have to be architected the same as Battlelog to be considered modern. Most of us are too concerned (or straight up scared) of the JavaScript/HTML5 revolution that we can't see what is possible right now. Sharing templates server and client side is a magic bullet that everyone should be using. Web applications are only going to get faster, and if you want to keep up, you're going to have to do implement modern solutions like Battlelog and Google+ do. I can envision a time when full page refreshes are the exception and that isn't a bad thing.

kwamenum86 15y ago
"I can envision a time when full page refreshes are the exception and that isn't a bad thing." Agreed. Different clients should get different views. I don't think we're that far off from having to support the js-light "web crawler" view, although we already have the tools to make this really easy.
Joeri 15y ago
You don't need to involve the server in generating the UI at all. You can have a static index.html, that bootstraps a javascript environment from static js files, whose first order of business is to contact a web service to fetch the initial content and configuration as JSON data. This makes all content static except that which is truly dynamic, which offers amazing CDN and caching possibilities. The JSON data can be cached in local storage, for easy offline support without constantly revving manifest files. Once you get at that point, the dev experience starts to look a lot like traditional desktop client-server app development. Except desktop apps are built using components instead of templates, components that combine rendering and behavior into one encapsulated entity that you can treat like a black box. There's nothing preventing a web app from using that same architecture. In fact, ExtJS does just this. But I don't think it stops there. I think we're going to get meta-configuration languages like mxml to send the layout of these components to the javascript environment, which will, essentially, mean that we're building another browser inside the browser. And so all software evolves until it can render a web page, including web apps.
- ntoshev 15y ago
  If you do this, crawlers can't index your pages. Also your users see the page loaded blank and being gradually populated with content, which is not a good UX.
  - maccman 15y ago
    Your first point is not correct. Crawlers can crawl JavaScript only websites using the Ajax crawling API: http://code.google.com/web/ajaxcrawling/docs/specification.html http://code.google.com/web/ajaxcrawling/docs/specification.h... Your second point has merit. However I'd counter it thus: * You can load a HTML page first, containing a representation of the end content, so you can avoid the flash * You can show some sort of loading indicator on page load. Users are usually fine with waiting for the initial page load - it's only subsequent interactions that need be fast. In other words, there's no reason why the page need be blank.
    - sirn 15y ago
      However by using hashbang URLs, you have to keep that little snippet of JavaScript forever to maintain permalink even after the web has moved on to another solution. It's not a future-proof solution.
      - mattmanser 15y ago
        I'm not sure what you mean by little snippets of javascript, a link is a link. If you change why couldn't you just 301 them to your new format? It's a trivial redirect that you're keeping for the g-juice.
        icebraining 15y ago
        The part after an hashbang is not sent to the server, so you need client side code to load the content. This is because the # in an URL is supposed to be an identifier of a element in the page, not an actual resource.
      - 15y ago
romaniv 15y ago
Most of us are too concerned (or straight up scared) of the JavaScript/HTML5 revolution that we can't see what is possible right now. What I see in practice is the exact opposite. Everyone writing about "what is possible" with JavaScript (custom 3d rendering engine for every website!), very few people are concerned about architectural and practical issues of it all. Web applications are only going to get faster, and if you want to keep up, you're going to have to do implement modern solutions like Battlelog and Google+ do. I can envision a time when full page refreshes are the exception and that isn't a bad thing. Full page refreshes are not what makes web applications slow. I used to browse the web on 133MHz computer over a mediocre modem connection. Today, despite all these promises of speed, many JS-heavy websites seriously lag on anything slower than 1.5MBps and 2GHz dual-core. (Try browsing via Kindle.)
- sarnowski 15y ago
  Even on my BF3 gaming PC, the UI feels slugish and lags on most clicks. In addition, it feels like the heavy-js sites are much more error prone than simple, hard-to-fail get+get+get sites. Battlelog is often not in sync with the real state of the server and your computer. Only page reloads can help in those situations.
colin_jack 15y ago
> Sharing templates server and client side is a magic bullet that everyone should be using. Out of interest, what solutions are there for this currently?
- bphogan 15y ago
  I've been playing with Mustache, as it works in Ruby and JavaScript (and something like 13 other languages.) Have to be a little careful to ensure that you only pass objects to the template, of course, so you don't bleed any language-specific stuff into your template. But what I've tinkered with is very exciting.

kwamenum86 15y ago

"I can envision a time when full page refreshes are the exception and that isn't a bad thing." Agreed. Different clients should get different views. I don't think we're that far off from having to support the js-light "web crawler" view, although we already have the tools to make this really easy.

Joeri 15y ago

You don't need to involve the server in generating the UI at all. You can have a static index.html, that bootstraps a javascript environment from static js files, whose first order of business is to contact a web service to fetch the initial content and configuration as JSON data. This makes all content static except that which is truly dynamic, which offers amazing CDN and caching possibilities. The JSON data can be cached in local storage, for easy offline support without constantly revving manifest files. Once you get at that point, the dev experience starts to look a lot like traditional desktop client-server app development. Except desktop apps are built using components instead of templates, components that combine rendering and behavior into one encapsulated entity that you can treat like a black box. There's nothing preventing a web app from using that same architecture. In fact, ExtJS does just this. But I don't think it stops there. I think we're going to get meta-configuration languages like mxml to send the layout of these components to the javascript environment, which will, essentially, mean that we're building another browser inside the browser. And so all software evolves until it can render a web page, including web apps.

ntoshev 15y ago
If you do this, crawlers can't index your pages. Also your users see the page loaded blank and being gradually populated with content, which is not a good UX.
- maccman 15y ago
  Your first point is not correct. Crawlers can crawl JavaScript only websites using the Ajax crawling API: http://code.google.com/web/ajaxcrawling/docs/specification.html http://code.google.com/web/ajaxcrawling/docs/specification.h... Your second point has merit. However I'd counter it thus: * You can load a HTML page first, containing a representation of the end content, so you can avoid the flash * You can show some sort of loading indicator on page load. Users are usually fine with waiting for the initial page load - it's only subsequent interactions that need be fast. In other words, there's no reason why the page need be blank.
  - sirn 15y ago
    However by using hashbang URLs, you have to keep that little snippet of JavaScript forever to maintain permalink even after the web has moved on to another solution. It's not a future-proof solution.
    - mattmanser 15y ago
      I'm not sure what you mean by little snippets of javascript, a link is a link. If you change why couldn't you just 301 them to your new format? It's a trivial redirect that you're keeping for the g-juice.
      - icebraining 15y ago
        The part after an hashbang is not sent to the server, so you need client side code to load the content. This is because the # in an URL is supposed to be an identifier of a element in the page, not an actual resource.
    - 15y ago

romaniv 15y ago

Most of us are too concerned (or straight up scared) of the JavaScript/HTML5 revolution that we can't see what is possible right now. What I see in practice is the exact opposite. Everyone writing about "what is possible" with JavaScript (custom 3d rendering engine for every website!), very few people are concerned about architectural and practical issues of it all. Web applications are only going to get faster, and if you want to keep up, you're going to have to do implement modern solutions like Battlelog and Google+ do. I can envision a time when full page refreshes are the exception and that isn't a bad thing. Full page refreshes are not what makes web applications slow. I used to browse the web on 133MHz computer over a mediocre modem connection. Today, despite all these promises of speed, many JS-heavy websites seriously lag on anything slower than 1.5MBps and 2GHz dual-core. (Try browsing via Kindle.)

sarnowski 15y ago
Even on my BF3 gaming PC, the UI feels slugish and lags on most clicks. In addition, it feels like the heavy-js sites are much more error prone than simple, hard-to-fail get+get+get sites. Battlelog is often not in sync with the real state of the server and your computer. Only page reloads can help in those situations.

colin_jack 15y ago

> Sharing templates server and client side is a magic bullet that everyone should be using. Out of interest, what solutions are there for this currently?

bphogan 15y ago
I've been playing with Mustache, as it works in Ruby and JavaScript (and something like 13 other languages.) Have to be a little careful to ensure that you only pass objects to the template, of course, so you don't bleed any language-specific stuff into your template. But what I've tinkered with is very exciting.