Hacker News new | past | comments | ask | show | jobs | submit login

It actually scales better because you're distributing the rendering effort on more machines.

You can serve client-side code on demand, the same way you're serving HTML on demand. There are multiple methods of running a rich client HTML application in a modular fashion. For example, you can load new JavaScript and CSS on demand, or you could do a hybrid approach, by reloading the complete page from module to module. Most MVC frameworks for JavaScript support dynamic loading.




It's still not practical. some other reasons:

1. It doesn't perform on some browsers which people use (IE7,IE8). I'm not willing to tell these users to go away or stick Chrome frame in as it makes us look like arrogant assholes.

2. It requires a large memory ceiling even with dynamic loading on a client browser. That kills older browsers and mobile devices.

3. It's an absolute bastard to test properly with Selenium or Ranorex as paths through the application require navigating through anchors rather than HTTP endpoints.

4. The entire UI would be dynamically typed shooting a lot of compile time checks that we rely on.

5. Internationalization is a bastard, particularly with multi-currency support, international date support and multiple languages.

6. It would require more state. State is bad. State means bugs.

7. It shifts the security model to an untrusted zone i.e. the client.

8. We have no scalability problems (5% cluster utilisation) and we shift 100 million requests a day.

Sorry but it doesn't cut it. I'd rather shift a WebStart or ClickOnce behemoth than do this with a client side MVC framework.


Yes, these are valid disadvantages of doing rendering code on the client. In your case, and many other similar to yours, using Go with abstract interfacing wouldn't be practical.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: