Hacker News Reader

Comment by joachimhs | Hacker News Reader

Ember.js is a framework for writing web applications on the client side. This experience, and the end result will be a lot different that the type of web apps that you might be used to writing from the server-side.

I've created my share of Java-based server-side generated web applications, and when it comes to writing applications that run well on the web, JavaScript MVC frameworks are the way to go.

I can't comment on how it might affect your career on either the short of long term, though. That said, I expect that the demand for these types of rich webapps will become larger as we move forward.

I'm turned 22 ten years ago myself, but I think making that statement you made is unfair.

View on HN

So you think that client side JS web apps are 'the way to go'. What's wrong with server side MCV web applications?

How does Ember.js in the clients browser scale when you have a a lot of data that needs marshaling / unmarshaling or generally processing and moving around? Surely it's more performant to do this on the JVM on the server rather than relying on the clients computing power (or lack of). Ideally you wouldn't do a lot of data processing in the MVC part of an app anyway but it seems like you're telling me the whole web app needs to be client side?

Most data-processing (if not all) should be done on the server-side. Your API should give your front-end app as much of a complete data-set as possible. Note that data 'appearance' is fine on the front-end for the most part.

So what's the point of making the MVC portion of the application client side when I can just use Spring MVC (or similar) and keep to the same tech stack that the rest of the project is using? Same goes for .NET projects etc?

If you write all of your code to run on the server then you need to pull down a full page from the server every time you want to update your data.

There's plenty of reasons you might want to avoid this in some cases. For example, you might want your forms to be validated without waiting for the user to push submit. You might have rich content in some markup language (like markdown) and you want the user to have a live preview on the same page as they are editing. Or you might have an app with real time data that changes frequently and you don't want the user to sit there pushing refresh constantly.

This functionality is already provided via AJAX. There's no need for me to put the whole MVC later on the client side to achieve this.

You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.

Once you are doing AJAX you are going to be writing Javascript (or something that compiles to it). Ember.js can help with that. So rather than writing a bunch of code to pull down JSON from the server and manually update the DOM in ways that deal with various browser quirks you can say "here's my model, here's how I want it rendered, link it to this REST API" and it will take care of a ton of heavy lifting for you.

It's true that it doesn't give you any magical power that you didn't have before and you can do everything it can do with vanilla javascript or any of the other frameworks. However that's a bit like saying you don't see the point of rails because you can just use vanilla PHP for everything.

You're speaking as if doing AJAX and doing client-side MVC are one step apart. Moreover, you're speaking as if using server-side MVC forces the programmer to use no JavaScript at all. At best, this is naive. Either that, or you deliberately misrepresenting technologies to promote something.

The simplest way to use AJAX with a server-side MVC is by fetching blocks of pre-rendered HTML. This is commonly known as AHAH. It's dead-simple to do, powerful and trivial to use via progressive enhancement. That is what you should treat as the server-side alternative to client-side MVC.

If your app has a lot of rich client functionality, it can be a lot easier to just use JSON data with client side MVC rather than having to constantly regenerate everything on the server, especially when several parts of the page need to be updated at once and a lot more performant.

Sounds like you haven't tried making a large AJAX app. Yes, if all you need to do is validate a form this or any other framework is overkill. You'll likely have multiple forms, lots of views, dynamically updating data, filtered tables, modals, etc etc. You can manage it all yourself, but frameworks like Ember maker this a whole lot easier.

cues Ether beat

Basically, your server side doesn't change much. The difference is that instead of outputting HTML, it outputs JSON.

Instead of writing your own code to handle AJAX on top of jQuery, you write code that handles the real logic and let the framework handle the DOM manipulation. In that way, it's easier to test, easier to debug, easier to provide superior experiences.

Right now, writing AJAX in the browser is equivalent of the JSPs of yesteryear. Remember all that horrific logic that used to creep into your JSPs? That's what jQuery looks like, and this new crop of frameworks is getting us to JSTL or facelets at the minimum.

The difference is that instead of outputting HTML, it outputs JSON.

Which is non-semantic, so it cannot be progressively enhanced, does not benefit from browser updates and is pretty much not crawlable by anyone except Google.

So, you would do most data-processing on the server side. But the data that your client-side application needs you will server to it, most likely via JSON.

You can definately go too far and implement too much on the client side, and this is generally a bad approach.

It's like with anything else. You need to figure out the balance between what you process on the server and what you process on the client.

Reply on news.ycombinator.com