I have begun to play with Knockout recently and I must say it is truly awesome and the power that it can bring to web applications.
However now I want to do something real world and architect my solution using Knockout. Eg. How should my viewmodels be initialized. Where should they go? I am mainly targeting single page application. So, I am interested in architecting single page applications mainly.
There are a lot of pieces to the puzzle, but here is a short list for me.
DISCLAIMER: I'll make some assumptions about your app too, so some of it will vary. Also, this is just one way to do it. There are may good ways. But this should be a good starting point for you.
Assuming your app is a set of abut 5 main views in a SPA:
Create a master/shell html page to house the app
Create a view / partial page (html) for each view. Each view is hidden til you navigate/route to it.
Create a viewmodel that can be bound to each view Create a
bootstrapper.js that kickstarts everything.
Bootstrapper should crank up any routing engine you use (sammy, history, etc)
Bootstrapper will bind the views to the viewmodels Bootstrapper can
also crank up any seed data and state for your SPA
Tip: Use SoC. Have your viewmodels be models for views. Don;t have them do routing, ajax calls, ui manipulation, etc. Have separate objects for other functions. DRY, KIS, SoC ... all good stuff :-)
I use the Revealing Module Pattern for creation of my viewmodels, though standard Module is perfectly fine too.
If you ave a more specific question, happy to answer that. I tried to keep this short cuz in truth it's not a 5 minute answer. In fact, I'm writing a course for Pluralsight on one way to do this coming in August 2012 :-)
For those who need an updated alternative (2015)...
Another option (and a very good one) is to use Yeoman to scaffold a single-page-app for you as described in Steven Sanderson's blog here
It does all the architecturing you need for you so you can concentrate on writing code. Try best to harness the re-usability of the knew knockout component feature - it's amazingly described by Steve Sanderson so I won't take away the glory of his well done work.
I just open-sourced the mini SPA framework I put together with Knockout being the major component.
knockout-spa
A mini (but full-fledged) SPA framework built on top of Knockout, Require, Director, Sugar.
https://github.com/onlyurei/knockout-spa
Live Demo:
http://knockout-spa.mybluemix.net
Features
Routing (based on Flatiron's Director): HTML5 history (pushState) or hash.
Highly composable and reusable: pick modules/components for a page in the page-specific JS and they will be auto-wired for the page's HTML template
SEO ready (prerender.io)
Fast and lightweight (85 KB of JS minified and gizpped)
Two-tier bundle build for JS for production: common module that will be used by most pages, and page-specific modules that will be lazy-loaded
Organized folder structure to help you stay sane for organizing and reusing JS, CSS, HTML
Using Knockout 3.3.0+ so ready for Knockout's flavor of web component and custom tags (http://knockoutjs.com/documentation/component-overview.html)
All documentation are in the major dependencies' own homepages, so that you don't need to completely learn a new framework
Knockout http://knockoutjs.com
Require http://requirejs.org
Director https://github.com/flatiron/director
jQuery http://jquery.com
Sugar http://sugarjs.com
Related
I have a huge client-side web application written in JavascriptMCV framework ~50 views, around 500.000 javascript code lines. Everything is built in JavascirptMVC formation using separate files for Controllers, Models and Views for each view = web page. The time has come to migrate to one of the modern javascript frameworks - I'm thinking about Angular and I'm starting to make an initial research about time estimations and human resources needed.
Are there some known techniques for doing that? If someone can point me to some article or knowledge base it would be very helpful.
I'm not sure if there are tools or special techniques to do this, but you could create an angular app around your current app.
You create an angular app from scratch, with a shared 'main' view (could be a new html page) which then uses ng-view (with angular-route) to load all your current HTML pages as partials. That way a lot of the page-linking can remain intact.. I do think that from that point, a lot of refactoring is required to make it an actual angular app.. Which raises the question, on what grounds do you think it's beneficial to migrate to a different framework when the old one is still working fine?
I only know one js library and that is jQuery.
But my other coders in the group are changing AngularJS as their default library in new project.
I don't know anything about it. How is it different from jQuery?
I already have a set of functions done for similar tasks in jQuery. Can I still use jQuery stuff with AngularJS?
While Angular 1 was a framework, Angular 2 is a platform. (ref)
To developers, Angular2 provides some features beyond showing data on screen. For example, using angular2 cli tool can help you "pre-compile" your code and generate necessary javascript code (tree-shaking) to shrink the download size down to 35Kish.
Angular2 emulated Shadow DOM. (ref)
This opens a door for server rendering that can address SEO issue and work with Nativescript etc that don't work on browsers.
The official document site
Day one keynote from ng-conf 2016
Resource links
Original:
Basically, jQuery is a great tool for you to manipulate and control DOM elements.
If you only focus on DOM elements and no Data CRUD, like building a website not web application, jQuery is the one of the top tools. (You can use AngularJS for this purpose as well.)
AngularJS is a framework. It has following features
Two way data binding
MVW pattern (MVC-ish)
Template
Custom-directive (reusable components, custom markup)
REST-friendly
Deep Linking (set up a link for any dynamic page)
Form Validation
Server Communication
Localization
Dependency injection
Full testing environment (both unit, e2e)
check this presentation and this great introduction
Don't forget to read the official developer guide
Or learn it from these awesome video tutorials
If you want to watch more tutorial video, check out this post, Collection of best 60+ AngularJS tutorials.
You can use jQuery with AngularJS without any issue.
In fact, AngularJS uses jQuery lite in it, which is a great tool.
From FAQ
Does Angular use the jQuery library?
Yes, Angular can use jQuery if it's present in your app when the
application is being bootstrapped. If jQuery is not present in your
script path, Angular falls back to its own implementation of the
subset of jQuery that we call jQLite.
However, don't try to use jQuery to modify the DOM in AngularJS controllers, do it in your directives.
Update:
Angular2 is released. Here is a great list of resource for starters
I want to add something regarding AngularJS difference with jQuery from a developer's perspective.
In AngularJS you have to have a very structured view and approach on what you want to accomplish. It is scarcely following a linear fashion to complete a task, but rather, the exchanges between various objects take care of the requests and actions, which, then, is necessary as angular is an MVC-Based framework. It also requires an at least general blueprint of the finalized application, since coding depends much on how you want the interactions to be completed.
jQuery is like a free poetry, you write lines and keep some relations and momentum appropriate for your task to be accomplished.
Though, in Angular JS, you should follow some rules as well as keeping the momentum and relations proper, maybe it is more like classical Spencerian sonnet (a famous classical poet) whose poem is structural and tied to many rules.
Compared against AngularJS, jQuery is more like a collection of codes and functions (which is, as already mentioned, great for DOM manipulation and fast-effect achievement), while AngularJS is a real framework which gives the developer the ability to build an enterprise web-application with a lot of data-binding and exchange within a superbly organized-routing and management.
Furthermore, AngularJS has no dependency on jQuery to complete its task. It has two very superb features which are not found in jQuery in any sense:
1- Angular JS teaches you how to CODE and accomplish a goal, not just accomplish a goal by any means. Worth to mention that AngularJS fully utilizes the core and heart of Javascripts and paves the way for you to incorporate in your app, the techniques such as DI (dependency-injection). To work with angularJS you should (or must) learn more elevated techniques of coding with Javascript.
2- Angular JS is fully independent to handle directives and structure your app; you might then simply claim that jQuery can do the same (independence), but, indeed, AngularJS, as several times mentioned within the above lines, has independence in the most excellent possible structurally MVC-Based way.
A last note is that, there is no war of Names, since it is far disturbing to be biased, or subjective. jQuery's magnitude and greatness has been proved, but their usages and limitations( of any framework or software) are the concerns of the discussion and similar debates around.
Update:
Using AngularJS is decisive as it is expensive in terms of implementation, but founds a strong base for future expansion, transformation and maintenance of the application. AngularJS is for the New World of Web. It is targeted toward building applications which are characterized by their least resource consumption (loading only necessary resources from the server), fast response time and high degree of maintainability and extendability wrapped around a structured system.
AngularJS :
AngularJS is for developing heavy web applications. AngularJS can use jQuery if it’s present in the web-app when the application is being bootstrapped. If it's not present in the script path, then AngularJS falls back to its own implementation of the subset of jQuery.
JQuery :
jQuery is a small, fast, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler. jQuery simplifies a lot of the complicated things from JavaScript, like AJAX calls and DOM manipulation.
Read more details here: angularjs-vs-jquery
I think this is a very good chart describing the differences in short. A quick glance at it shows most of the differences.
One thing I would like to add is that, AngularJS can be made to follow the MVVM design pattern while jQuery does not follow any of the standard Object Oriented patterns.
They work at different levels.
The simplest way to view the difference, from a beginner perspective is that jQuery is essentially an abstract of JavaScript, so the way we design a page for JavaScript is pretty much how we will do it for jQuery. Start with the DOM then build a behavior layer on top of that. Not so with Angular.Js. The process really begins from the ground up, so the end result is the desired view.
With jQuery you do dom-manipulations, with Angular.Js you create whole web-applications.
jQuery was built to abstract away the various browser idiosyncracies, and work with the DOM without having to add IE6 checks and so on. Over time, it developed a nice, robust API which allowed us to do a lot of things, but at its core, it is meant for dealing with the DOM, finding elements, changing UI, and so on. Think of it as working directly with nuts and bolts.
Angular.Js was built as a layer on top of jQuery, to add MVC concepts to front end engineering. Instead of giving you APIs to work with DOM, Angular.Js gives you data-binding, templating, custom components (similar to jQuery UI, but declarative instead of triggering through JS) and a whole lot more. Think of it as working at a higher level, with components that you can hook together, instead of directly at the nuts and bolts level.
Additionally, Angular.Js gives you structures and concepts that apply to various projects, like Controllers, Services, and Directives. jQuery itself can be used in multiple (gazillion) ways to do the same thing. Thankfully, that is way less with Angular.Js, which makes it easier to get into and out of projects. It offers a sane way for multiple people to contribute to the same project, without having to relearn a system from scratch.
A short comparison can be this-
jQuery
Can be easily used by those who have proper knowledge on CSS selectors
It is a library used for DOM Manipulations
Has nothing to do with models
Easily manipulate the contents of a webpage
Apply styles to make UI more attractive
Easy DOM traversal
Effects and animation
Simple to make AJAX calls and
Utilities usability
don't have a two-way binding feature
becomes complex and difficult to maintain when the size of a project increases
Sometimes you have to write more code to achieve the same functionality as in Angular.Js
Angular.Js
It is an MVVM Framework
Used for creating SPA (Single Page Applications)
It has key features like routing, directives, two-way data binding, models, dependency injection, unit tests etc
is modular
Maintainable, when project size increases
is Fast
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Templating
Build-in form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication
And much more
Think this helps.
More can be found-
jQuery vs. AngularJS: A Comparison and Migration Walkthrough
"Thinking in AngularJS" if I have a jQuery background?
What are the key differences between jQuery and AngularJS?
jQuery Vs AngularJS – A Good Comparison
What is the difference between jQuery and AngularJS?
Jquery :-
jQuery is a lightweight and feature-rich JavaScript Library that helps web developers
by simplifying the usage of client-side scripting for web applications using JavaScript.
It extensively simplifies using JavaScript on a website and it’s lightweight as well as fast.
So, using jQuery, we can:
easily manipulate the contents of a webpage
apply styles to make UI more attractive
easy DOM traversal
effects and animation
simple to make AJAX calls and
utilities and much more…
AngularJS :-
AngularJS is a product by none other the Search Engine Giant Google and it’s an open source
MVC-based framework(considered to be the best and only next generation framework). AngularJS
is a great tool for building highly rich client-side web applications.
As being a framework, it dictates us to follow some rules and a structured approach. It’s
not just a JavaScript library but a framework that is perfectly designed (framework tools
are designed to work together in a truly interconnected way).
In comparison of features jQuery Vs AngularJS, AngularJS simply offers more features:
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Template
Form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication
We need to change/rewrite an existing series of pages/workflow screens into one standard page. The project in itself will essentially be to build a single web page app inside the context of a larger existing application.
Our goal is to leave the server side implementation the way it is as much as possible. This means we won't be using a REST model, but rather just some form submissions to a java backend. Each end point will point to a JSP.
Each form will be created as a widget. When one widget submits it may affect the value of the other widgets which need to change their values on the fly.
It seems the 2 main options for single page web apps are Backbone.js or Ember.js.
Given our requirements, which of these 2 (or any other frameworks) will fit best? Or is there some other approach all together we should take?
Did you have a look at AngularJS? It is more comparable to EmberJS.
I would recommend you EmberJS for the moment, as it is more mature in term of ecosystem (Routing, Data, ...)
Backbone is lower-level than both precedents.
There are probably a bunch of things you should look into.
Emberjs is 42k minified+gzip while Backbone.js is just 5.6kb. Emberjs packs a lot of power in it which the barebones Backbone doesn't give you.
Analyse if you even need all those features. If your requirements are covered by just Backbone, IMO you should give Emberjs a pass. Shipping all those extra bits for no use is foolish.
With Emberjs, you will have to use jQuery as well. Not sure if you are already using it or not.
IMHO, I would use Emberjs if the single page web app is super complex with lots of feature requirements else Backbone should suffice.
Either will accomplish what you want.
I am partial to Ember as it provides a Routing/statechart framework which really helps lock an application's behavior down. Not to mention that it is MVC, which will help you separate your concerns. Each form or widget in your app will be a view that you define, binding inputs to your model layer.
I know Model-View-Controller well, have known about it for years and used it in terms of server-side development with languages like PHP.
However, I am now working with JavaScript and building a big application with it utilizing SVG, Canvas among other great features modern browsers support. The project is big, so, the architecture behind it must not be fragile.
JavaScript and MVC do not get on like a house on fire, because JavaScript is event-driven by nature. So, are there any architectures or anything else I should definitely learn, understand and implement?
The software will have to deal with data. It already utilizes local storage and web SQL database. I need a Models, right? There is an UI, so I have Views? However, do I have Controllers? What about events? How do I structure everything?
Architecture, architecture, architecture -- that's what I'm interested in. I'm fine with the language of my choice.
First, I'm the author of JavaScriptMVC, so I'm extremely biased in a whole variety of ways. First, there are 6ish things you will ever do in a JS application:
Load Scripts
Respond to user events
Update the DOM
Request data from the server
Convert that data into something useful for JavaScript
Organize your front-end business logic
Your choice of architecture might depend on what tools you want / need.
For general architecture, I do think it's important to separate concerns.
I strongly encourage you to find some way of doing dependency management, and client side templates. They will make your life a lot easier.
JavaScriptMVC uses a tiered MVC approach that's based heavily around custom UI events and OpenAjax events.
I build my low-level widgets with $.Controller in a similar way to how you would build jQuery widgets. The big difference is that the widgets produce a non-ui event that top level controllers can listen to. For example, a tabs widget might produce a "tab.activate" event like:
$('.tab').trigger('tab.activated')
Then, my higher order controller might listen to tab.activated events, and a the model to update the tab content like:
".flickr tab.activated" : function(tabEl, ev){
Flickr.findAll({type : "rainbows"}, function(images){
tabEl.html("//path/to/view", images );
}
}
Flickr.findAll essentially does a query for flickr messages, then calls back with a list of images. Wrapping the service/ajax functionality with models makes them a lot more reusable.
You'll notice that in the callback I update the html of the tab element with the rendered content from a view. This probably isn't the 'best' way of doing it, but I wanted a quick example. Better would be passing the tabs controller the rendered output, for it to do what it will with it. That way if your tab wants to fade in content someday, it will be able to and your master controller won't have to know about the tab's implementation.
The most important thing is to break down your app into the smallest pieces you can. Have them individually testable (and flexible), and combine the little parts into bigger parts as you work your way up to your application.
Take a look at Ext JS. It has a clean architecture that is well-suited towards highly complex javascript applications.
Data handling and server communication is done via stores. Data rendering is done via grids (with in-cell editors), and forms (with a rich set of form controls), which can both talk to the stores. There's also a set of layout classes to abstract away CSS positioning (border layout, box layout, table layout, form layout, ...).
It is however not MVC in the typical sense. The library encourages a programming style that avoids dealing much with HTML and CSS, letting you live (mostly) in pure JavaScript land. You end up thinking in terms of components and data, instead of individual dom elements and style rules. If you don't like that approach, be warned, you won't like this library.
MVC is still the way to go, in my opinion. If you're looking for a good framework to help you achieve that a little less painfully, I would look at JavaScript MVC, it has models, views, controllers, unit testing, jQuery support, etc.
You should learn the Event Based nature of client-side JavaScript and how it blends with MVC based server-side applications.
You should also learn how to properly program inside of the Prototype based inheritance structure of Javascript.
Both of those things will allow you to write you JavaScript so that it meshes with your server-side application framework and is extensible and re-usable.
One thing i have learned over the years of javascript programming is writing UnObtrusive Javascripting which basically means seperating as much as possible structure(HTML) and style(CSS) from Behaviour(JAVASCRIPT).
Althogh not a raw javascript solution, take a look at CoreMVC, the jQuery architechure of MVC.
CorMVC is a jQuery-powered
Model-View-Controller (MVC) framework
that can aide in the development of
single-page, web-based applications.
CorMVC stands for client-only-required
model-view-controller and is designed
to be lowest possible entry point to
learning about single-page application
architecture. It does not presuppose
any server-side technologies, or a web
server of any kind, and requires no
more than a web browser to get up and
running.
If you want a ready-made reference architecture that combines soem industry leading JS libraries with some good JS design patterns for large scale development, have a look at:
http://boilerplatejs.org/
I'm the main author of it and thought of sharing knowledge we gained after developing few large scale javascript products. It addresses following main concerns:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation
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