I built a quiz taker app with Ruby on Rails, using the MVC framework. I want to do basically the same thing with pure JavaScript, and add more features with jQuery for mobile devices and special effects, since jQuery is just awesome like that.
I have looked around on sites like TodoMVC for comparisons on frameworks, but I'm foreign to how these frameworks function. Why do they use Collection rather than Controller in their MVC definition? It seems to me that these are just client-side frameworks. Would I use something like Backbone.js for client-side work and Node.js for server-side?
I'm just unsure as to how development with pure JavaScript functions. I need to create a database to store quiz and user information and be able to access that database when viewing most pages, so I feel the MVC framework is the best way to go.
Any suggestions as to where to start?
Wow, that's quite a broad post; let's take things one at a time
Why do they use Collection rather than Controller in their MVC definition?
The exact answer varies by library, but a simplistic answer is that the Controllers in most Javascript apps doesn't really need any framework; they can be raw Javascript and work just fine as they're usually not very complex.
Furthermore, parts what you might consider to be "the Controller" are often provided separately. The primary example of this is Backbone's Router object: it is similar to the implied routing (and routes.rb) in Rails, or the urls.py in Django. Just as those frameworks don't consider routing to be part of "the Controller", Backbone (and similar frameworks) provide routing as a separate piece ... even though it could fall under the C in MVC.
Similarly, much of the DOM manipulation functionality that jQuery provides would normally belong in the Controller of an MVC app, so in a sense jQuery helps you build your controllers; it's just not explicit the way Backbone.Model helps you build your models.
Would I use something like Backbone.js for client-side work and Node.js for server-side?
That's really apples and oranges; to put in server-side terms, Backbone is more like Rails, and Node is more like Ruby (or Mongrel or something). So yeah one's client-side and the other's server-side, but the differences are deeper than that.
Any suggestions as to where to start?
Pick a framework and get your hands dirty! Seriously, you can spend hours reading reviews of the different frameworks, and still be no closer to making a decision at the end than when you started (I speak from experience). But if you just pick one and try it, you'll likely find that it either "gels" with you or doesn't pretty fast.
Personally, I'd recommend starting with Backbone just because A) it's very popular these days, and B) I'm biased: I use it on a daily basis and love it. Also, it probably would fit you well because it was created by the CoffeeScript guy (and CoffeeScript was his attempt to make Javascript more Ruby-like). However, Ember.js is also very popular these days, and Hector mentioned ExpressJS, which I know nothing about but could be cool.
But the point is, pick one, do a hello world, or maybe something a little more complex like an introductory tutorial (Backbone has one around a To Do app). A few hours of coding with it will tell you far more than I (or anyone else on Stack Overflow) ever could about whether it's right for you.
If you are looking for a JavaScript MVC-like framework take a look at Express.js http://expressjs.com
Express.js is more like Sinatra than Rails, but it will give you a good foundation on the server side.
I would definitely look at Google Closure. I have started to use it with LimeJs on a personnal pet project and really got caught with it's compiler and it's modular design.
It's not really MVC, but since JavaScript should be thought more in an asynchronous fashion, I tend to think more of it as event driven than simply a request-pipeline-response way.
So, Closure Library and jQuery / jQuery UI (both on Google API) for the client side and ExpressJs for the server side. Also, take a look at this framework comparison chart, you might find it interesting.
Related
I come from a decade of experience with Java EE, SE and Java with Spring. If there's something that was drilled in me by myself and other fellow developers, was how to make use of design patterns, separation of responsibility, separating definition from implementation, interface segregation, etc. Also, we were always worried about testable code (unit testing and integration tests).
When I was learning Java, there wasn't a single book, magazine or website that didn't implemented things with those rules in mind, to the point of boredom. So we always new how things should be done from an architectural point of view when starting new stuff or maintaining code. With time, projects like Spring Boot and JBoss Seams started to give out of the box a basic project layout witch you simply followed to success(or at least you should...).
Now that I delve deep in Node.js, I miss that so much. There seems to be only a handful of people on the web worried about it and trying to teach newcomers how to write good backend code with Node.js.
People teach you how to boot express and put all of your code (database, logging, mailing, error handling and so on) inside an express route.
Of course, when I started learning Java, there was nothing preventing you from using Servlets directly with some JDBC code thrown inside, or even worse, Scriptlet inside JSPs...
I would appreciate so much to know how you for instance implement a service layer, where do you put your business logic? Do you put it in classes or functions that returns other functions? How to write easily testable code by Mocha for instance... Do I really need a controller layer, or can I trust my routes to cover that responsibility?
I'm interested in JavaScript only on the Backend, using Express.js, Socket.io, RabbitMQ, Passport.js, and GraphQL(in the future). Not interested in any rendering engine or template engines, much less JavaScript on the Browser. I'm already very proficient with Sequelizer and Mongoose.
I know the feeling of switching from Java Spring Boot to the Node.js stack. It was confusing for me in the beginning aswell, but with time you find your set of frameworks you like.
I'm probably not qualified enough to answer your entire question, but I can give you some advice of what framework helped me the most after starting with Node.js.
For me, this framework is NestJS.
It's a progressive Node.js framework to build scalable server-sided applications, based on Express.js. It supports a lot of different design patterns, but I personally use a pattern consisting of controllers, services, repositories and providers. You can use multiple different databases obviously.
Nest.js stands out for me, because you don't need any 3rd-party tutorial or documentation, because their own documentation is done really well and has basically all the information you'll ever need. It is really expandable with additional dependencies (most of them are in-house developed and have great documentation aswell).
What also has to be mentioned, is that as a Java-dev you will probably miss OOP if you switch to JavaScript. In Nest.js tough you only develop with TypeScript and overall it gives you a feeling very similar to Java Spring Boot.
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.
I'm currently on a web application project written in javascript with node.js and Express server-side and it's time to consider the client-side of this application. The two questions are:
Should I consider using a framework or can I write it without such a tool?
And if not, which framework?
I've chosen three of these: backbone, knockout and Ember. I read all the questions I found about them but I'm still hesitating. The points to consider are:
It is good to mix html with javascript like knockout does?
Will my application be easily maintainable?
Will the framework continue and not diappear tomorrow, leaving me in a very uncomfortable situation?
EDIT: And what do you think about JavaScriptMVC?
As #Christian Varga has said in the comments, it depends. However, I would make the following observations:
It is good to mix html with javascript like knockout does?
With knockout you are not forced to mix javascript into the html. See Unobstrusive Event Handling.
Will my application be easily maintainable?
In my experience with knockout , if the application gets especially large the pages do get complicated. However, if you are going for a SPA style page then the code will always get fairly involved. I haven't worked with Ember or Backbone but certainly Backbone does have a reputation for being be good for larger applications.
Will the framework continue and not diappear tomorrow, leaving me in a
very uncomfortable situation?
I think you have picked your three frameworks to consider wisely. Knockout and Backbone both have fairly wide adoption. Knockout is to be shipped with MVC4 which gives you some confidence behind its future. Ember is newer but there seems to be a lot of excitement behind it. There is a good discussion of Ember with various references to knockout and backbone here
Hope this helps you evaluate what will be best for your project.
All those are good frameworks. You can choose anyone and you won't make a huge mistake. Of course, you might like one most than others, but that's a matter of taste. All those frameworks will make your app easy mantainable.
Now, I want to add something more. You asked "Should I consider using a framework"? You can build your own stuff, that's something cool. I'd just recomend to keep in mind good organization of your project. In my short experience, Js is a mess. And these FWs help you to keep your code clean and organized.
1 more thing to add to organization: You should consider some AMD tool, like Require.js
If you're thinking of building an application with scalability and maintainability in mind you might want to consider a reference architecture such as Boilerplatejs.
BoilerplateJS incorporates best practices to be used when building a large scale application. Furthermore it ships with libraries such as knockoutjs and also utilities that would help structure and organize your code.
I have been a user of jQuery (and some of its minor plugins) for a while. The Javascript code I've developed over the years could be described best as... messy. It used a ton of global variables and functions here and there, didn't use standard ways of organizing the code, nor any design patterns whatsoever.
I am currently building the new version of a website, and I have completed doing the backend with PEAR::MDB2 and Smarty templates. The rest is just homebrew PHP with some classes.
Now I am at the point where I'll add the Javascript layer on top of the website to improve the user-friendliness of some features. (while making sure everything degrades gracefully) I want to write better, cleaner, more organized Javascript than I used to, so I did a little research. I read Stefanov's Object-Oriented Javascript to have a better grasp on some concepts I knew only loosely about (prototypes, constructors, etc.) as well. Now I'm stuck at a point where I wonder which Javascript frameworks I should use, and how to organize it all.
After conducting my research, I understood Cappuccino & Objective-J, and Sproutcore were not what I was looking for. To quote Cappucino's about page:
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks
So there's that. Then I found out about Coffee Script, which is more of a one-to-one "compiler" and wouldn't help me with the actual organization of my code.
I also stumbled on some articles that give guidelines:
Using Inheritance Patterns to Organize Large jQuery Applications
A JavaScript Module Pattern
I also found out about Backbone.js, Shoestring, JavaScriptMVC, Google Loader, jQuery Tools, jQuery UI. I don't really know what to do of all this... The things I know:
I don't want to invest too much time in learning something too complex, I want to keep things simple and flexible as much as possible (that is why I don't use Symfony on the backend, for example), yet clean and organized.
I want to use jQuery, the question is, what should I use with it? (that is compatible too)
Right now, I'd use jQuery and jQuery Tools and "organize" all that in a simple namespace/object literal with simple properties and methods and also, since the site is localized, I just plan on using the simple vsprintf (as I do on the backend) with key:value pairs loaded from an object literal provided by the backend. JavaScriptMVC seems interesting, but I fear it would bring way too much complexity for a project that is fairly small sized. That is where I need your advice! Thank you very much in advance.
Ok, my attempt at an answer:
There is no 'best' to way to do it. You now know what's there and I think you might have a preference for yourself for what you want. In that case, pick a framework and learn it inside-out. (sorry to burst your bubble, but each framework has a learning curve, some steep, some very easy, but in the end to use it well you have to invest in it. Just do it, you won't be sorry).
You of course have an preference for clean code, so you might take some considerations into account. You also say you have a preference for jQuery, which is fine, but there are some limitations (as also pointed out in the link provided by eskimoblood).
There are some nice lectures / and tutorials with advice on how to structure your code in jQuery:
How to manage large jquery apps
On Large jQuery apps
Essential Javascript and jQuery patterns (free ebook)
Some style guides:
Jquery core UI Styleguide
Google Closure Javascript Style Guide
Tools for checking your code
JSLint
JSHint (a more forgiving/practical fork)
Closure Linter (haven't tried it yet, but intend to)
Standard works (javascript)
Everything by Douglas Crockford
Quirksmode
There might be more.. perhaps more people can contribute, but I also think that you've almost reached the end of what you can learn before getting your hands dirty. Many of these guides are written in a very generic way, but the interesting thing is that javascript is called upon in many specific situations. It might be useful to just post some of the code that you regard as "messy" and we can help you figure out how to do it better. Good luck!
You should watch the video and read the links in this article and then you should ask yourself again if jquery is the right tool. Maybe you will use dojo, that is much better for larger projects or you take a look at backbone and where you can stay with jquery. After all both of them are more "javascriptish" then something like sproutcore, cappuciono or even GWT. And also much easier to understand when you come from jquery.
One framework that is to consider is definitely ReactJS from Facebook. This framework is pretty slick in many ways.
First thing you have to know is that it is a view framework. It can be used server-side to do the pre-rendering of pages, but it really shines on client side. Since it's a view framework, it can be used with backbone or any other "back-front"-end framework.
One of the main point of React is its rapidity. It keeps a virtual DOM in memory and virtualize all the webpages events. So the virtuals event are used to keep events browser agnostics.
The virtual DOM kind of make programming a dynamic site as if you were programming an old static website. You can just shoot the whole HTML to render to the view engine (as if you were "re-rendering" the whole page) and it will manage the DOM operations. It does a diff between the new virtual DOM and the current virtual DOM and only inserts nodes that needs to be inserted. This way you reduce the number of DOM ops and thus increase your render speed by a lot.
A good place to start is this tutorial which shows how to use "Flux" (the web flow designed by Facebook for its site) in order to realize a Todo application!
How should a complex single-page JS web application be structured on the client-side? Specifically I'm curious about how to cleanly structure the application in terms of its model objects, UI components, any controllers, and objects handling server persistence.
MVC seemed like a fit at first. But with UI components nested at various depths (each with their own way of acting on/reacting to model data, and each generating events which they themselves may or may not handle directly), it doesn't seem like MVC can be cleanly applied. (But please correct me if that's not the case.)
--
(This question resulted in two suggestions of using ajax, which is obviously needed for anything other than the most trivial one-page app.)
MVC architecture of PureMVC/JS is the most elegant IMO. I learned a lot from it. I also found Scalable JavaScript Application Architecture by Nicholas Zakas helpful in researching client side architecture options.
Two other tips
I've found view, focus, and input management are areas that need special attention in single page web apps
I also found it helpful to abstract away the JS library, leaving door open to change mind on what you use, or mix & match should the need arise.
Nicholas Zakas's presentation as shared by Dean is a very good place to start with. I was also struggling to answer the same question for a while. After doing couple of large scale Javascript products, thought of sharing the learnings as a reference architecture in case someone needs it. Have a look at:
http://boilerplatejs.org/
It addresses common Javascript development concerns such as:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation
etc.
The way I build apps:
ExtJS framework, single page app, every component defined in a separate JS file, loaded on-demand
Every component contacts its own dedicated web service (sometimes more than one), fetching data into ExtJS stores or special-purpose data structures
The rendering uses standard ExtJS components, so I can bind stores to grids, load forms from records, ...
Just choose a javascript framework, and follow its best practices. My favorites are ExtJS and GWT, but YMMV.
Do NOT roll your own solution for this. The effort required to duplicate what modern javascript frameworks do is too big. It is always faster to adapt something existing than to build it all from scratch.
Question - What makes an application complex ?
Answer - The use of word 'complex' in the question itself. Hence, a common tendency will be to look out for a complex solution right from the beginning.
Question - What does the word complex means ?
Answer - Anything that is unknown or partially understood. Example : The theory of Gravity even today is COMPLEX to me but not to Sir Isaac Newton who discovered it in 1655.
Question - What tools can I use to deal with complexity ?
Answer - Understanding and simplicity.
Question - But I understand my application . Its still complex ?
Answer - Think twice, because understanding and complexity does not co-exist. If you understand a huge huge application, I am sure you will agree that it is nothing but an integration of small and simple units.
Question - Why all of the above philosophical discussion for a question on
Single Page Application (SAP)?
Answer - Because,
-> SPA is not some kind of core technology that is newly invented for which we need to reinvent the wheel for a lot of things that we are doing in application development.
-> Its a concept driven by the need for better performance, availability, scalability and maintainability of web applications.
-> Its a fairly newly identified design pattern, so an understanding of SPA as a design pattern goes long way in making informed decisions about the architecture of a SPA.
-> At the root level no SPA is complex, because after understanding the needs of an application and the SPA pattern, you will realize that you are still creating an application, pretty much the same way you did before with some modifications and re-arrangements in the development approach.
Question - What about the use of Frameworks ?
Answer - Frameworks are boiler plate code / solution for some commonly identified and generic patterns, hence they can take off x% (variable, based on the application) load from application development but then not a lot should be expected out of them specially for heavy and growing applications. Its always a good case to be in complete control of your application structure and flow but most importantly the code for it. There should be no grey or black areas in the application code.
Question - Can you suggest one of the many approaches to SPA architecture ?
Answer - Think of your own framework based on the nature of your application. Categorize application components. Look for an existing framework that is close to your derived framework, if you find it then use it, if you do not find it then I suggest going ahead with your own. Creating framework is quite an effort upfront but produces better results in long run. Some basic components in my SPA framework will be:
Data Source : Models / Collections of Models
Mark Up for presenting data : Templates
Interaction with the application : Events
State capturing and navigation : Routing
Utilities , widgets and plug-ins : libraries
Let me know if this helped in any way and good luck with your SPA architecture !!
The best thing to do is to look at example uses of other frameworks:
TodoMVC showcases many many SPA frameworks.
You can use javascript MVC framework http://javascriptmvc.com/
The web application that I am currently working on uses JQuery and I would not recommend it for any large single page web application. Most frameworks i.e. Dojo, yahoo, google and others use namespaces in their libraries but JQuery does not and this is a significant drawback.
If your web site is intended to be small then JQuery would be ok but if you intended to build a large site then I would recommend looking at all the Javascript frameworks available and deciding which one most meets your needs.
And I would recommend applying the MVC pattern to your javascript/html and probably most of your object model for the javascript could be done as the json that you actually return from the server through ajax and the javascirpt uses the json to render html.
I would recommend reading the book Ajax in action as it covers most of the stuff you will need to know.
I'm using Samm.js in several one page applications with great success
I would go with jQuery MVC
Check out http://bennadel.com/projects/cormvc-jquery-framework.htm Ben is pretty sharp and if you dig around on his blog he has some nice posts about how CorMVC is put together and why.
Alternative: take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Or have a look at https://github.com/flosse/scaleApp
NikaFramework allows you to create single-page application. Also allows you to write HTML, CSS (SASS), JavaScript into separate files and bundle them into only one output file in the end.
I would recommend to explore Yeoman. It allow you to use existing "best practice" for your new project.
For example:
if you decide to use Angular.js, there is a Yeoman generator, that give you a structure for routing, views, services, etc. Also allow you to Test, minify your code, etc.
If you decide to use Backbone, checkout this generator