Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've spent the last couple days researching different arguments for and against different MVC frameworks but what's become very apparent is that there's absolutely no correct answer to this question as it's heavily dependent on a number of different factors specific to the underlying project.
The advice I am repeatedly coming across is select a framework on the following points: Ease of use, productivity, testability, community, documentation
While that's all well and good advice, I still think that there are a few more things to consider specific to the actual code-base you'll be working on.
That being said, hypothetically if you were to arrive at work one day and asked to select the "best" Javascript MVC framework for your code base to handle the entire front end of an existing product (keeping in mind that there is a current codebase and you'd want the framework to be able to handle the "transition" period as you shifted to the new framework over time), what are the factors/questions you believe would be necessary to consider to make a well informed decision? These can be factors/considerations/questions about the MVC frameworks themselves AND/OR the current code base / technologies current in use (ie. Ruby backend, other libraries currently in use, product functionality, etc).
Scalability and performance are extremely important as this product would have a fairly large volume of users.
Just due to stability and maturity of certain frameworks alone I've factored down realistic choices to Angular, Backbone + Marionette and Ember (although this one is still up in the air). Each one is a different beast by its own right and functions very differently, hence the need for my original question on what factors and questions would you ask to figure out which is the "ideal" (I use that word very loosely) choice?
Your question is probably going to be closed since it is both "too broad" and "primarily opinion based", making it not a good fit for this site.
But since I was faced with exactly this same decision not so long ago, I'll share my impressions of the three frameworks. Please also read this article (from someone more experienced than me) if you haven't already.
AngularJS
Pros: "Magically" hooks up functionality between the view and the logic and allows getting a lot done with minimal code. Frees you from having to do a lot of DOM manipulation. Easy to start off simple and build up (for the most part).
Cons: AngularJS's strong points can also be seen as its weak points - many say that it does too much with its "magic" and that this makes it hard to troubleshoot when something goes wrong. Also, the "freedom from DOM manipulation" can turn into an "obstacle from DOM manipulation". Forces you to find plugins and libraries or make your own components that "do things the Angular way" for some tasks that would otherwise be trivial. Also violates separation of concerns by forcing you to place a lot of code in your HTML.
Backbone.JS
Pros: Provides a framework for imposing order upon your code and data structures without taking over your whole site design. "Plays well with others", as #dandavis has said in the comments section above.
Cons: Doesn't provide much in the way of UI support. Requires either bolting a UI framework on top of it (such as Marionette), or doing most of the manual labor yourself.
Ember.JS:
Pros: Provides a lot of UI assistance (with the help of handlebars, which is built into Ember) without violating separation of concerns. Events are hooked up in code (in a rather clean way too). Like Backbone, provides a framework for adding rigid structure to your app.
Cons: Requires mastering a lot of different concepts and setting up a lot of moving parts. Can require a lot of code and separate pieces to accomplish relatively simple things. Assumes the use of handlebars templates rather than plain HTML (which can be a plus or a minus, depending on one's preferences).
In the end, I went with AngularJS because I happened to like all the "magic" and ease-of-use that it provides. The following also helped me rule out the two other options:
Minimal UI functionality in Backbone meant I would have to hook it up myself (which I was trying to get away from in the first place), or go off and compare/contrast a whole bunch of other frameworks to put on top of Backbone. That would have been too much of a time investment at the time.
I ruled out Ember because much of the HTML markup work was delegated to another person, and it would have been unreasonable to force that person to learn how to use handlebars templates. That was a pretty big strike against Ember for my particular case.
Related
This is basically the same old, same old x vs y, what is faster?, but I do hope my version is applicable. Also, React and Angular differ like GTK and Qt (or even more), and comparing them is stupid - one is an out-of-the-box can-do-anything framework, while the other is a View framework designed to only do that. If my question still is unanswerable or subjective and should be closed, please write me a comment how to improve it in the future, if possible. Thank you.
This is a question about Angular 2+ vs React in terms of performance. My team shall build one SPA for identical functionality with each framework.
Assume:
development time for both versions should be equal / similar
non-view related functionality (where Angular differs from view-only React) is unimportant to the measurement and development time, updates to the view happen frequently and are the bottleneck
measured is steady-state performance after initial page-load (so all data for the page is within memory)
both applications are built the way the relevant handbook would recommend
client-side rendering only, with mostly dynamic data (so not much server-side rendering or ahead-of-time-compiling)
Javascript VMs are difficult to reason about, but my two questions are exactly about their behavior:
Would there be a clear performance winner after current-gen JIT has done its part (optimizing as far as possible) or would the final performance be equal?
In the year 2027 we will still use webbrowsers (probably Chrome 256 or Firefox 384). Assume both frameworks still exist and kept their core strategy / mechanics the same as today. Browser Javascript VMs / JIT improved further and further, but I keep my current laptop to measure performance. Which framework would probably win in 2027? Or to rephrase the question: which strategy is theoretically more optimal / 'closer to the metal' (or in this case: closer to Javascript execution models)?
PS: I'm pretty sure in 2027 we will not use either, and this question is also not about which framework anyone should prefer, but only theoretical performance. The question about which framework would be 'closer to the metal' came up one night with friends and should not be used by anyone to make a decision. Never make important life decisions drunk or late at night.
My experience but not the final decision
I started with Angular and wanted to see what React could do. React is certainly not bad, but what I immediately noticed was the disorder that can prevail. That depends on the developer, of course, but with Angular and TypeScript everything looks more orderly and structured. Template and code are separated and with React you have the JSX, i.e. HTML in JavaScript which is JavaScript. Reminds me a bit of PHP and I never liked that, because when a project gets extremely big, you really lose track. For one component you could easily have 3-5 files and that is bad in my opinion.
With Angular you can also lose the overview, but you have a uniform structure with a few deviations.
If your application becomes really very very big then it makes sense to use Redux but why people making life complicated. If you just want to check if a user logged in or not for a middle large e-commerce site then services would also do the job.
In my opinion, the user should focus on working. Redux it is fine but we should not add every new tool which comes each week to our project either is reduce cost and time dramatically. But if you add new tools then you should also have people who can handle it later. It doesn't mean if you use every tool that your application is good or you are a good developer automatically. In my opinion, keep everything as simple as possible and use the tools you really need to fulfill your requirements.
And by the way I don't understand why the people still want to use Vaadin, Spring Boot together with Angular in combination. Maybe someone can explain it me?
I have been using JavaScript and jQuery for quite a while now and want to extend my skill set further, during my search I came across two popular names Angular and Backbone and while reading about them I found one line common in both them which somehow also seems to be their USP i.e.
It is designed for developing single-page web applications
This makes my confused.
What is that I cannot do with JS or jQuery and I would require these?
I have created web application on single page, where users can perform CRUD operations on single page through asynchronous calls so why so much importance of for these others libraries?
And as a middle level web developer who has have good hands on JS is it right path to move to these two or here is something else I should look into before these?
Please help?
Structure.
In an ongoing project that started about 4 years ago we built the front end with jQuery. We were able to do just about everything that we needed creating several single page applications that were quite functional.
As the project progressed and the code base grew we started experiencing some major problems with maintainability of the code. We ended up with hundreds or thousands of lines of JavaScript code per page in a tangle that was almost impossible to navigate. This could have been avoided if we were more careful of course but at the time we focused on making sure the back end architecture was robust.
Many years ago the community learned that code needs structure to be maintainable. We developed MVC patterns, multi-tiered applications etc. But JavaScript was never a big player in the field and we largely ignored it.
Over the last 6 months or so we introduced Angular into the project and started sorting out some of the mess in the project. The results are remarkable. Not only is the code simpler and easier to create, the structure makes it easier to implement tests, easier to maintain and generally a huge improvement over what we had before. We still use jQuery but now we have been burnt by the lack of structure and know a thing or two about the architecture of a JavaScript application. Angular and its like provide you with the tools to architect a good application.
When you are creating larger scale web applications it is wise to check out Backbone, Angular or perhaps Meteor. jQuery supports neat tricks, but it does not help you structure your code in a maintainable way. Larger scale web apps build on jQuery need their own vision on how to separate the code into layers with their own responsibility.
The other frameworks give more support.
I would suggest checking out at least one of the libraries. Perhaps you eventually won't use them, but it will benefit how you work in jQuery.
Well Now a days there has been quite a hype about Angular.js and especially SPAs (Single Page Applications). Well to be honest, I had the same question in my mind about a month ago when my team decided to shift from Jquery to Angular.
Whenever it comes to Jquery, one of the first thing that comes in our mind is the DOM manipulation. While using Jquery we always think of manipulating the DOM. Show/hide elements, animating elements, getting data from tags you name it. But Angular offers something more than that. It offers you an architecture, a way to structure your applications at the front end.
So whenever you go for Angular.js, change the way you think about creating web applications (and believe me its worth it). Most of Angular's structure uses the concept of Dependency Injection which is a neat way to maintain your code.
Backbone is only a library whereas Angular.js is a complete framework to create and manage Single Page Applications
Talking about the fact that Angular.js should be used when we are creating large scalable apps, it is true. In my case the team I work with is full of Jquery Ninjas. We have been creating a great app for the last 3 years and believe me it became difficult for us to maintain and debug thousands of lines of Jquery. This is the main reason we have decided to revamp this app into Angular.
Kindly see some of these Helpful links. You will get a better idea.
http://net.tutsplus.com/tutorials/javascript-ajax/3-reasons-to-choose-angularjs-for-your-next-project/
"Thinking in AngularJS" if I have a jQuery background?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My goal is to migrate an existing web application to a RESTful single page application (SPA).
Currently, I'm evaluating several Javascript web application frameworks.
My requirements are as follow:
RESTful data layer (like ember-data)
MV*-structure
Dynamic routes
Testing-support
Coding by convention
SEO-support
Browser-History-Support
Good (API-) documentation
Production-ready
Living community
Backbone
The current application is using backbone.js. Overall, backbone.js is a nice project, but I'm missing well-defined structures that determine where what has to happen and how things must get implemented. Working in a bigger team with changing developers this leads to some kind of unstructured code, difficult to maintain and difficult to understand. This is why I'm searching now for a framework, that already defines all this stuff.
Ember
I looked into ember.js the last days. The approach seems very promising to me. But, unfortunately, the code changes almost daily. So, I won't call it production-ready. And, unfortunately, we can't wait for it to be version 1.0. But I really like the idea behind this framework.
Angular
Angular.js is a widely spread framework as well, maintained by Google. But I could not get familiar with angular. For me, the structure seems kind of unclear, explanations are missing of the overall responsibilities of each part of the framework, and the implementations feel circuitous.
Just to get this straight: this is just my personal impression and might be based on missing knowledge.
Batman and Meteor
As I understood, both frameworks need a server part as well. And since we just want a RESTful backend - no matter what language, technic or software, this is not what we want. Further, the backend API does already exist (RoR).
Knockout, CanJS and Spine
I did not go any deeper into these three candidates. Maybe this will be my next step.
So my questions now:
Am I missing any good SPA-frameworks?
What framework would you suggest/recommend?
Would you avoid any of the mentioned frameworks?
What is your experience in bigger SP applications?
PS: I'd would like to recommend a great blogpost from Steven Anderson (core developer from Knockout.js) about the "Throne of JS"-conference (from 2012) and javascript frameworks in general.
PS: Yes, I know there are already some question on SO. But since the development is so rapidly and fast for SPAs, most of them are already out-of-date.
I recently had to decide on a JavaScript SPA framework on a project too.
Ember
Looked at Ember early on and had similar thoughts as you about it - I really liked it but it felt like it was still too early to use... about half the tutorials I read didn't work with the current version because something had recently changed in how templating works.
Backbone
Backbone was the first frameworks we seriously looked at. I'm not sure I understand why you think it doesn't have "well defined structures"? Backbone is pretty clear about how to divide up Model and View code. Maybe you mean there's not some kind of app template? Anyway, Backbone seems really focused on the model/REST-binding part, but doesn't really prescribe anything for view binding. If model binding's important to you and you're using Rails it should be a breeze to do this. Unfortunately, the web services for my app didn't really match up, and I had to write my own .sync and .parse methods for everything. The separation of Model and View code was nice, but since we'd have to write all our bindings from scratch it wasn't worth it.
Knockout
Knockout is like the Yin to Backbone's Yang. Where Backbone is focused on the Model, Knockout is a MVVM framework and is focused on the View. It has observable wrappers for JavaScript object properties and uses a data-bind attribute to bind properties to your HTML. In the end we went with Knockout since view binding was mainly what we needed for our app. (...plus others, as discussed later...) If you like Knockout's view binding and Backbone's model bindings there's also KnockBack which combines both frameworks.
Angular
Looked at this after Knockout - unfortunately we all seemed pretty happy with how Knockout did view binding. It seemed a lot more complex and harder to get into than Knockout. And it uses a bunch of custom HTML attributes to do bindings, which I'm not sure I like... I may take another look at Angular later, because since I've come across multiple people who really like the framework - maybe we just looked at it too late for this project.
Batman, Meteor, CanJS, Spine
Didn't really look too closely at any of these. Though I know Spine is a similar framework to Backbone with explicit Controller objects, and is written in CoffeeScript.
Afterword
As I mentioned, we ended up using Knockout because, for our project, focusing on view binding was more important. We also ended up using RequireJS for modularization, crossroads and Hasher to handle routing and history, Jasmine for testing, as well as JQuery, Twitter Bootstrap, and Underscore.js (and probably more libraries I'm forgetting at the moment).
Javascript app development is more like the Java ecosystem than the Rails ecosystem. Rails provides a solid core of stuff you're going to use for every app (Rails framework), and the community provides a lot of customizations on top of that (gems). Java provides... a language. And then you can choose Java EE or Spring or Play or Struts or Tapestry. And choose JDBC or Hibernate or TopLink or Ibatis to talk to the database. And then you can use Ant or Maven or Gradle to build it. And choose Tomcat or Jetty or JBoss or WebLogin to run it in. So there's more emphasis on choosing what you need and what works together than choosing THE framework to use.
it's been a year since we started development on our Cloud services project with numerous SPAs, so it was a big decision, which javascript framework to use for our UI to satisfy our RESTful architecture needs.
and after a lot of researches we ended up using Dojo framework .
main features you'll love:
educated community and a team that came up with a perfect design pattern. great conventions and modular/object-oriented architecture. with CrossBrowser programming attitudes :)
MV* structure. build UI widgets with external .htm templates and for production, build all your javascript & templates into a single, minified and small .js
build classes with inheritance. property setters, a lot of function tools.
pub/sub mechanism (named topics in dojo)
a lot of UI controls, from validation form control, dialogs/tooltips to a heavy featured, highly customizable (but lightweight) chart & data-grid solution.
a good unit test system named DOH. it also have a robot to reproduce mouse/keyboard actions.
a querying tool (like JQuery) named NodeList with all jquery features and even a lot of it's plugins.
and the good but not so complete part. it has a JsonRest module to use with your REST services. its a handy tool but it lacks a lot of features.
to overcome these issues, we developed an AJAX poller, error handling and universal, loading & notifications solution.
we did it very easily using dojo framework conventions and structures.
if you don't want to do that, perhaps you have to use another framework for this part.
looking at great SPAs around the web you'll find out all of them are customized and using multiple frameworks. but our experience with Dojo alone was fantastic. and therefore I suggest you to don't think of any other framework since all of them are incomplete for a SPA. but ultimately you have also another option (which I don't recommend and have no details information on). go with a JAVA framework that is capable of building SPAs, by automatically generating UI & javascript.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would appreciate your opinions. I have been put in charge to redevelop a major site that does quite a bit of traffic. As of the past few months, I have been using Backbone.js to develop applications. I have been researching the last couple of weeks on whether Backbone would be a good fit for the redevelopment of the new site.
My initial concern was SEO. Found a great post here that talks about progressive enhancement and a bunch of stackoverflow questions that have helped to. I can't seem to shake the feeling that building a static site and enhancing it with Backbone is quite a feat and will take much more time.
Now my question is, have we not passed the stage where we have to build sites that have to work with javascript disabled? Is it essential that our site is still functional for screen-readers etc?
My idea was to serve the relevant meta seo information from the server into my main app.html file so search engines will still be able to crawl the different urls. The Backbone app will be launched from whatever url you visit that is relevant to the app.
I have just visited the new hulu.com, and cant seem to come up with a reason as to why not re-develop the website into a Backbone application. Most if not all websites I have visited, will not function without js. Go to hulu.com with js disabled and you will be able to see what I mean. So in closing is it safe to build a website that will not function without js and will the above suffice for SEO?
Thank you
I think there will be a lot of opinions on this. Here's mine.
As a default mind setting I always find backward-compatibility and graceful fallback important. I normally believe a site should be able to fulfill it's main purpose: delivering content (content sells).
However.. what if the purpose aka content is delivering some kind of functionality, like a online calculator or drawing application.. Then the user would already need and expect things like javascript to be enabled. In those cases I'll happily make design/layout things easer on me, using javascript. Think of a site like jsfiddle: who would care if this site didn't display it's ui properly because javascript was disabled.. Nobody.
As to SEO: I think there are a lot things that influence this. If you sell apples and you own the domain apples.com, your pretty much set anyway. Again, content sells, that is how most engines try to index.
Apart from that, in this (horrible) day and internet age, the most popular search-engines will both filter and rank the search-results to the user.. so if one wants to optimize a site for the search engine.. then for who's personal bubble (search results) do you try to optimize?!?.
I have more faith in something that was semantically coded, maintainable and has a pretty stable foreseeable future (instead of having to rebuild the same thing over and over again, every 6 months or so). Simpler put: make the core/base 'simple' enough to 'always' be rendered in a useful way and then add the spice using javascript and css-edge-technology to flavor the content.
Have you looked into node.js at all? Since your porting the view rendering to javascript anyways. It would be a little friendlier to have more components speaking the same language. Plus the asynchronous processing model releases a lot of server stress that threaded processes usually cause. Threaded processes spend a lot of time (and power) waiting to execute. But in javascript, folks usually set up callback methods. So instead of waiting for the previous process to finish, node just leaves behind a callback method to be executed when needed, meanwhile the rest of the application is still going full speed ahead.
node is really light too. You can use it along side other server side technologies and it wont take up much space. It has some pretty powerful features, but, personally, I find it best for view rendering (it's javascript after all). It also makes setting up servers and routing reeeaally easy. So setting up the stuff you mention in your 4th paragraph would be a sinch.
Anyways, that's my 2 cents.
The previous programmer left the website in pretty unusable state, and I am having difficulty modifying anything. I am new to web design so I don't know whether my skills are a mismatch to this kind of job or is it normal in the real industry to have websites like these
The Home page includes three frames
Each of these frames have their own javascript functions ( between <head>, and also call other common javascript functions (using <script src=..>
Excessive usage of document.all - in fact the elements are referred or accessed by document.all only.
Excessive usage of XSLT and Web Services - Though I know that using Web Services is generally considered a good design choice - is there any other way I can consume these services other than using xslt. For example, the menu is created using the data returned by a web method.
Every <div>, <td> and every other element has an id, and these id's are manipulated by the javascript functions, and then some appropriate web service and the xslt files are loaded based on these..
From the security perspective, he used T-SQL's for xml auto for most of the data that is returned by the web service - is it a good choice from the security standpoint to expose the table names and column names to the end user??
I am a lot confused about the state of the application itself. Should I learn about the intricacies that he has developed and continue working on it, or should I start rewriting everything? What I am perplexed a lot is the lack of alternatives - and whether this is the common way web projects are handled in the real world or was it an exception?
Any suggestions, any pointers are welcome. Thanks
No, it is not acceptable in this industry that people keep writing un-maintainable code.
My advice to you is to go up the chain and convince everyone that this needs to be rewritten. If they question you, find an external consultant with relevant web development skills to review the application (for 1 day).
Keeping this website as-is, because it 'works' is like keeping a working model Ford-T car on today's highways, very dangerous. Security and maintenance costs are likely the most persuading topics to convince anyone against keeping this site 'as-is'.
Next, get yourself trained, it will pay off if you can rewrite this application knowing the basics. Todays technology (asp.net MVC) allows you to implement core business value faster than trying to maintain this unconventionally written app.
Tough spot for an inexperienced developer (or any) to be left in. I think you have a few hard weeks a head of you where you really need to read up on the technologies involved to get a better understanding of them and what is best practice. You will also need to really dig down into the existing code to understand how it all hangs together.
When you done all that you really need to think about your options. Usually re-writing something from scratch (especially if it actually works) is a bad idea. This obviously depend on the size of the project, for a smaller projects with only a couple of thousand lines of code it might be OK. When looking at someone elses code it is also easy to overlook that all that weird shit going on could actually be fixes for valid requirements. Things often start out looking neat, but then the real words comes visiting.
You will need to present the business with time estimates for re-writing to see if that is an option at all, but I'm guessing you will need to accept the way things are and do your best with what you have. Maybe you could gradually improves things.
I would recommend moving the project to MVC3 and rewriting the XSLT portions to function using views and/or partial views with MVC. The Razor model binding syntax is very clean and should be able to quickly cleave out the dirty XSLT code and be left with just the model properties you would need.
I would then have those web services invoked from MVC serverside and for you to deserialize the object results into real objects (or even just use straight XQuery or Json traversing to directly pull stuff out for your model) and bind those to your views.
This could be a rather gargantuan leap for technology at your company though. Some places have aversion to change.
I'd guess this was written 6-7 years ago, and hacked on since then. Every project accumulates a certain amount of bubble gum and duct tape. Sounds like this one's got it bad. I suggest breaking this up into bite size chunks. I assume that the site is actually working right now? So you don't want to break anything, the "business" often thinks "it was working just fine when the last guy was here."
Get a feel for your biggest pain points for maintaining the project, and what you'll get the biggest wins from fixing. a rewrite is great, if you have the time and support. But if it's a complex site, there's a lot to be said for a mature application. Mature in the sense that it fulfills the business needs, not that it's good code.
Also, working on small parts will get you better acquainted with the project and the business needs, so when you start the rewrite you'll have a better perspective.