JavaScript MVC Frameworks vs. Compile to JavaScript Languages

by Dio-Synodinos on Sep 04, 2012 |

Avoiding spaghetti code on the front-end has been a major challenge the last few years, as more and more logic ends up being executed in the browser. To solve this issue developers have been turning to MVC frameworks and languages that compile to JavaScript, which promise increased productivity and maintainable code.

As part of the new community-driven research initiative, InfoQ is examining the adoption of such frameworks and languages by developers.

 

 

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Is this a joke?! by Maga Zandaqo

I've chosen CommonJS and Backbone, not Dart! Why the hell it shows Dart?!

Re: Is this a joke?! by Maga Zandaqo

ok, seems like it was a bug

Re: Is this a joke?! by Dio Synodinos

Hi Maga, it's actually "Custom JS" and not "CommonJS", so if you want to re-vote, please drop me a line at research@infoq.com. I'd also love to hear any other feedback you might have :)

Re: Is this a joke?! by Maga Zandaqo

Thank you, Dionysios, that's ok now. The problem was that on "Your vote" was not my vote but the last vote at that time and it was vote for Dart, so I was confused.

JavaScript MVC Frameworks fail the DRY principle... by Jose Delgado

Pretty much all Enterprise Web frameworks in all platform implements the MVC pattern on the server-side...
No question that all these referred client-side frameworks have the good intention of avoiding "spaghetti code".
Unfortunately there is no magic cure for that malady. At the end of the day by "repeating the server code" on the client side there are exposing their web applications to unnecessary lengthy-costly-and-many-times-unperformant software development deliveries.

Thank you
jD @ is.gd/r1Z6XX

Re: JavaScript MVC Frameworks fail the DRY principle... by Michael Ahern

The frameworks (like Backbone) replace most of your server MVC logic for UIs rather than duplicate. You still end up with MVC on the server side for API endpoints, but the majority of the UI logic moves client side.

If you have tried to build a large AJAX application fully client sidethen look at a framework like Spine or BackBone you will appreciate how it fits together. With these tools and a Component based coding model (eg JqueryUI, Dijit, ExtJS) to decompose your View into digestible pieces you can now code an AJAX application primarily client side fairly elegantly.

The one case that is not well solved (if you own the logic for both the server and client) is form validation... however, even here - if your application service is Node.JS then you can use the same JavaScript code on BOTH the client and server; Java programmers (such as myself) are a bit behind on having a good framework in this case. I have not researched this last problem in a while, so hopefully someone will comment on this with a good framework to recommend :)

Re: JavaScript MVC Frameworks fail the DRY principle... by Jose Delgado

@Michael Ahern,
Couple of points on your post...
1) Could you please be more specific on your notion of "UI logic". Add some uses cases to understand you better.
2) I am a Java developer too and I found that with jQuery + Spring Web MVC is basically what you need for implemting ANY RIA WEB 2.0. Yes, including validation. As Java developer you just have to leverage JSR 303 for validation. That's it. You DRY on client-side for it.
Please review pragmatikroo.blogspot.com/2011/11/spring-roo-sy... and/or pragmatikroo.blogspot.com/2011/12/synergy-unlim... and/or pragmatikroo.blogspot.com/2011/11/codename-syne...

jD @ pragmatiktoo.blogspot.com

adoption != favourite by denis krizanovic

It's difficult to do this because most people have not used all of them. So perhaps you can ask that question too. "Which ones have you used?"

I think if you want to understand favourite, you also need to ask the "least favourite" question too.

For example, I've only been involved in GWT, and GWT is a mistake. so I would vote "least favourite".

Or, you might want to ask the question in terms of "net promoter score". en.wikipedia.org/wiki/Net_Promoter to see, based on people's experience, if they'd "promote" the usage of this framework.

As it stands now, your answers will reflect age of framework and any marketing done for it. Hence, GWT.

how did u choose the voting candidates? by omri zisovitch

hi
glad to see this vote since i am currently diving into this world of javascript MVC frameworks.
i just wonder how u chose these specific frameworks, some seems a bit awkward to me (coffescript is not really a MVC framework for example), and why other popular ones were left out (dojo, extJS and more)
cheers
ziso

Re: JavaScript MVC Frameworks fail the DRY principle... by Michael Ahern

@1 - I don't know what Roo can give me, so it is hard to comment specifically. The main case I am thinking of is management of page state / URL addressability. At least in the screenshots above, the page state does not appear to be RL addressible - which may or may not be fine for your application. I would not be surprised to learn that Roo has a solution to this problem or a solution to this problem in the pipeline.

Spine, Backbone, one of the 100 other JS MVC frameworks allow you to manage mapping of page state to URLs fairly well - which is the key problem for RIA I was thinking of.

@2 - I'll have to look at closer look at Roo then :) My knowledge here is pretty dated as this has not been a significant requirement on what I am currently working.

A couple projects ago, this issue I ran into with JSR 303 was that the Hibernate Validator (v4.0) implementation of JSR 303 - at least at the time - could not handle the requirements of bag-of-attribute type data structures (where the same type may be refined in multiple different ways - eg. multiple variants on string fields, such as hobbies vs. favorite color) [forum.hibernate.org/viewtopic.php?f=26&t=99.... Again, this was a while ago so hopefully this can be solved by today's JSR 303 implementations without the hacks above.

Re: JavaScript MVC Frameworks fail the DRY principle... by Jose Delgado

@1.1 FYI Roo is a RAD based on the Spring Framework... Spring Framework is a dominant force in the Java Enterprise arena.
I am speaking for myself on this particular jQuery + Spring Framework integration. In other words: I am using Roo baseline and add what is missing to come up with RIA WEB 2.0 applications. Basically jQuery and jQuery components. That's it.
The mapping of page state to URL that you mentioned is pretty easy to implement with the already baseline deployed stack. You don't need anything else.

@2.1
JSR 303 as any Java api, framework or class can be extended or customized to meet any use case. It is inherent on the Java programming language.

On the other hand: The first problem for the ones trying JS MVC frameworks. They have to decide to pick one from the 100 available. This is a very unproductive-time consuming task.

Bottom line whatever they pick they would be ending violating the DRY principle. Not good at all.


jD @ pragmatikroo.blogspot.com/?view=timeslide

Cannot see the voting options by Abbas Zaidi

Hi Guys, i cannot see the voting options, where are they ?

Re: JavaScript MVC Frameworks fail the DRY principle... by Sandeep Tucknat

That's a pretty bold statement without backing. We use GWT with GWT-Platform. We write the code once, it's used on server side and also compiled as JS and used on client side. While we do everything to encode and protect our client side code, we also cautiously mark things that should be done exclusively on client side. The 'unnecessary-lengthy-costly-and-many-times-unperformant' comment just tells me you don't know what you are talking about.

Re: JavaScript MVC Frameworks fail the DRY principle... by Sandeep Tucknat

Check out GWT and GWT-Platform. Does everything you want and more.

Disclaimer : I am not affiliated with either, just a happy end user :)

No JSF or Other option? by Russ Healey

We are using Java Server Faces at the company I am currently developing for. So either a JSF or Other vote would be helpful. There are quite a few more java server based frameworks available as well.

Where are the most popular Enterprise Frameworks? by Michael Mullany

Ext JS has 2 million developers worldwide and a registered community of almost half a million. (I work for Sencha) Even excluding the half a million threads on the Sencha forums for Ext JS, there are more questions for Ext jS on Stackoverflow than almost all these options.

Dojo is also in the same range of popularliry and is very widely used - particularly within Enterprises that use a lot of IBM technology since it's supported as part of Websphere.

jQueryUI is also used widely for smaller less complex apps within the Enterprise.

Dart is a language, not a framework...

Re: Where are the most popular Enterprise Frameworks? by Victor Grazi

I agree with Michael Mullany
Also, I don't have experience with most of these except GWT, which I would not vote for if offered Ext and/or jQuery.
But it forced me to vote to see the analysis.
So I logged in and voted, but when I tabbed to analysis, it told me I have to sign in. Ok, did that again, then pressed analysis, but it told me I had to vote. Argh! Done that! So I voted for GWT again, rinse wash repeat! I gave up after 2 specious votes for GWT.

Re: JavaScript MVC Frameworks fail the DRY principle... by marc prades

While we do everything to encode and protect our client side code

The only way to protect anything on the client is to do it on the server. there is no way you can protect anything on the client. Minification is not obfuscation and it is easy enough to de-minify code and setup break points directly on the browser to spy on the code you deployed. So again , protecting javascript on the client is just impossible , i can take your code , change the api endpoints the assets and make your code my own in no time.

Re: Where are the most popular Enterprise Frameworks? by marc prades

there are more questions for Ext jS on Stackoverflow than almost all these options

Maybe because ExtJs is such a pain to use ?
While , SenchaTouch does the job on mobile , AngularJS is in my opinion better than ExtJS will ever be , and more easily testable. ExtJs is untestable , there is so much magic it is nearly impossible to know where errors come from .

Lacking something? by Domingo Savoretti

Why is Meteor nowhere to be found in the poll?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

20 comments
General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy