3 ms·

I'm not sure I agree with the "work of beauty" statement. A browser plugin? Rendering all pages on the client via some massive JS framework? Intercepting all pa

by azov 15y ago

I'm not sure I agree with the "work of beauty" statement. A browser plugin? Rendering all pages on the client via some massive JS framework? Intercepting all page loads and hooking into browser navigation? Compiling templates into Python & Javascript? Is all this complexity really justified? I know that web apps is all the rage those days, but given the native plugin, pickiness about browser version, the fact that they apparently not care about being indexed by search engines, and all the trouble they went through to make it all work together - wouldn't they be better off to just implement the whole thing as a native app?

spitfire 15y ago
This is a throwback to thick client-server computing. Welcome to 1992 everybody! I'm not a web dev, but I like the client side rendering. (Even if I hate JS with a passion). This is a fantastic move as it lets you very clearly seperate presentation from business logic and the database. Also, the rendering HTML/JS can be easily cached. So you get a normal page load the first time you try the app, every time after that you get _instant_ results. Nice.
- maxwell 15y ago
  Why do you hate JS?
  - robmcm 15y ago
    It's an immature language with lots of design mistakes. When the bible to JS developers is called, 'JavaScript the good parts' it's a worry...
kwamenum86 15y ago
If you render the initial view on the client you still get indexability. Twitter actually still uses the old version of their site for this purpose.
- anjc 15y ago
  So does this mean you've to support two...paradigms and keep the results similar for each version?
  - kwamenum86 15y ago
    Yes and no. If you have a templating solution that works well on the client and server then this shouldn't add much complexity. Rendering the initial view on the server has the added advantage of supporting javascript-disabled clients too. I muddled my point by mentioning Twitter - it was very nearly a non sequitur. They're supporting two paradigms but not because they want to. My understanding is that they don't have a single solution that works equally well on the client and server so they are using two different solutions.
    - anjc 15y ago
      Ah ok understood, thanks.
natesm 15y ago
"Work of beauty" is relative. The field that we're talking about here is video game server browser design, which isn't exactly known for being cutting edge. In general, game designers have almost always produced interfaces that are passable at best, because no one really cared. The only one I've used that was moderately decent was Valve's[1], the rest are a tacky mess with scrolling that barely works and filters restrictions that make it hard to find the game you actually want. Battlelog is really good. It responds almost instantly. You can middle click open server info pages, then middle click open the stats for every player on that server. Updates don't require a patch to the client, just change the HTML and JS that Battlelog is sending out (this was already done to add queues when servers are full). It could certainly have been done in game with embedded WebKit/IE or something though, prepackaging the plugin alongside. I don't really mind either approach, since Battlefield 3, for once, is a game on Windows that has absolutely no problem with the use of alt+tab. [1] http://www.blogcdn.com/news.bigdownload.com/media/2008/11/left4deadserverbrowser.jpg http://www.blogcdn.com/news.bigdownload.com/media/2008/11/le...
exogen 15y ago
1. The browser plugin is just to launch the game, not render the pages. 2. The "massive JS framework" won't seem so massive once you browse a few pages – the payload savings will likely pay off pretty quickly. Notice that the AJAX data for the index page was 4KB, vs. 18KB for the fully rendered page. 3. Cross-language templating languages aren't so rare (Mustache being a very popular choice). Consider this: once you want even just one tiny widget on the page to update via AJAX or push notifications, you've already got the code to support half of these features.

by azov 15y ago

spitfire 15y ago

This is a throwback to thick client-server computing. Welcome to 1992 everybody! I'm not a web dev, but I like the client side rendering. (Even if I hate JS with a passion). This is a fantastic move as it lets you very clearly seperate presentation from business logic and the database. Also, the rendering HTML/JS can be easily cached. So you get a normal page load the first time you try the app, every time after that you get _instant_ results. Nice.

maxwell 15y ago
Why do you hate JS?
- robmcm 15y ago
  It's an immature language with lots of design mistakes. When the bible to JS developers is called, 'JavaScript the good parts' it's a worry...

kwamenum86 15y ago

If you render the initial view on the client you still get indexability. Twitter actually still uses the old version of their site for this purpose.

anjc 15y ago
So does this mean you've to support two...paradigms and keep the results similar for each version?
- kwamenum86 15y ago
  Yes and no. If you have a templating solution that works well on the client and server then this shouldn't add much complexity. Rendering the initial view on the server has the added advantage of supporting javascript-disabled clients too. I muddled my point by mentioning Twitter - it was very nearly a non sequitur. They're supporting two paradigms but not because they want to. My understanding is that they don't have a single solution that works equally well on the client and server so they are using two different solutions.
  - anjc 15y ago
    Ah ok understood, thanks.

natesm 15y ago

"Work of beauty" is relative. The field that we're talking about here is video game server browser design, which isn't exactly known for being cutting edge. In general, game designers have almost always produced interfaces that are passable at best, because no one really cared. The only one I've used that was moderately decent was Valve's[1], the rest are a tacky mess with scrolling that barely works and filters restrictions that make it hard to find the game you actually want. Battlelog is really good. It responds almost instantly. You can middle click open server info pages, then middle click open the stats for every player on that server. Updates don't require a patch to the client, just change the HTML and JS that Battlelog is sending out (this was already done to add queues when servers are full). It could certainly have been done in game with embedded WebKit/IE or something though, prepackaging the plugin alongside. I don't really mind either approach, since Battlefield 3, for once, is a game on Windows that has absolutely no problem with the use of alt+tab. [1] http://www.blogcdn.com/news.bigdownload.com/media/2008/11/left4deadserverbrowser.jpg http://www.blogcdn.com/news.bigdownload.com/media/2008/11/le...

exogen 15y ago

1. The browser plugin is just to launch the game, not render the pages. 2. The "massive JS framework" won't seem so massive once you browse a few pages – the payload savings will likely pay off pretty quickly. Notice that the AJAX data for the index page was 4KB, vs. 18KB for the fully rendered page. 3. Cross-language templating languages aren't so rare (Mustache being a very popular choice). Consider this: once you want even just one tiny widget on the page to update via AJAX or push notifications, you've already got the code to support half of these features.