The JavaScript in my web application has grown into one huge file. I want to break it up into modules so it's easier to manage.
I don't know if there are any established best practices for anatomizing the codebase of a web application, or if it just varies too much from project to project?
In particular:
should each module be responsible for an app-wide concept, such as "layout", or "clientside storage", etc?
or should modules be for concepts specific to the app being built (like "comments" or "calendar"), and each module be responsible for managing its own layout, its own clientside storage, etc?
or a mixture of both?
If you take Separation of Concerns and Single Responsibility into account then each module/component etc. should be responsible for doing what it does and nothing else. Break down your modules by re factoring into small, easy to manage chunks that do it's job and nothing else.
In terms of your JS application you could take a look at some client side MVC frameworks (such as knockout, sproutcore, spine etc. to name but a few) these frameworks help to logically separate out views and layouts to controllers and models. You might also be interested in using something like require.js to load your modules as and when they are needed.
There is a very good book by Alex McCaw which is worth a read.
MVC is just one pattern, but it is a very popular pattern and addresses some of the concerns you have.
Best of luck.
All things being equal, you are better to create your modules around concepts specific to the app. This is more object oriented, and tends to group together code that is more likely to change together. This in turn makes your code easier to understand, more tolerant of change, easier to develop and extend (the benefits of "modularity").
Related
Could anyone explain me what is the pourpuse of create new modules in angularjs application, I have already read the documentation, but we are not quite sure about when is appropiate to create a new module or use our own application module when you create a new service, directive, etc..
I would like to add some thoughts after reading a bit more about the subject:
JAndy, you are right in the general concept, but to be more specific in when do you have to use angularjs modules I think I got a clear answer in this post
Basically we have 3 ways of structuring our angularjs projects:
angular-seed
Yeoman
Structure the project in Modules
Depending of how big is your project you can take one aproach or another.
Basically writing new modules in angularjs helps you to pack functionalities that are related, one of the advantages of this approach is if a new developer comes into your team he can get a general overview and find things easier than if you only have one module, another one is to reuse functionality accross other projects.
I'd like to answer this question in a more general style than being specific.
Why was the ISS not build as one gigantic station instead of multiple independent modules ? The reason behind modules is to separate responsibilities, decouple a construction, etc. In terms of programming it means to have logic, spread over multiple small modules. That way, you not only know exactly where to look if anything goes wrong or you need to extend some functionality, it'll also guarantee that your whole ISS( your application ) will not entirely fail if one of your modules fails. This of course, also requires certain aspects of
programming styles, most important in this context, to hold module interaction and communication loosely coupled (which I just assume).
So whenever you want to implement new stuff, which does not fit in any other existent code or module, you should create a new, independent module, which is specialized to fulfill a certain task.
Even if I'm not using AngularJS on regular bases, I'm sure the same idea of modularization will fit in there.
What is the best way to deal with multiple client side templates?
I noticed that if I keep them in my "mother" html file, it soon gets bloated with stuff, so I thought that maybe it would be better if I just put them in separate js files and load them one by one.
Another idea of mine was to avoid putting them separately as templates, but rather write them as strings and sort of couple them with the backbone.js views which are going to use them. I know that this would bring a lot of negative from designers, web developers, and software engineers in general, but for the projects I am working on, this seems like a very speedy way to develop because I have logic and layout at the same place. Plus, by reverse engineering, I proved that a bunch of prominent web services are doing the same so ...
One option is to use RequireJS, which includes a 'text' plugin for templates.
You can then use the r.js optimizer to combine all of these (plus JS modules, if you go that route) into a single file.
The optimizer can be run either as part of your build process, or in-process if you're using node.js.
You can have them in separate files, but combine into one file on a server side.
And take a lot of negative from me for your idea to keep templates in strings :). It might work until they are simple, but when they get more complex it gets badly, because html structure is not so obvious, so it is harder to write css and so on.
As #stusmith said, require.js is a good option.
also, take a look at the boilerplate's examples
http://backboneboilerplate.com/
https://github.com/thomasdavis/backboneboilerplate/blob/gh-pages/js/views/backbone/page.js
cheers
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 am planning to rewrite an existing Silverlight application using HTML, JavaScript and CSS. This will be a rich internet application connecting to a server only for data (JSON based web services) - so there will be no server-side presentation framework such as JSP or ASP.NET. The application consists of about 8 screens, most of them in a tabbed layout. The question is...
What is the best way to write such an application in a modular fashion? I would like to write the individual screens as standalone modules communicating with each other only via events. I would also like to use some sort of an MVC framework to decouple the presentation layer from the model.
Any thoughts on which frameworks I should look at? Have you had a good experience using them? I am starting to look at Backbone.js, JavaScriptMVC and SproutCore. Am I missing anything that is worth considering?
Thanks in advance for your time.
P.S. If you'd like to see the application that I am trying to rewrite, an online demo is available here - it is a realistic trading application built for learning and comparing technologies.
I haven't yet had a chance to try SproutCore, but I hear good things about it and want to look into it at some point. I would recommend trying out at least Backbone and Sproutcore to see which of the two fits your needs and your programming style better.
I do a lot of work with Backbone, and what your suggesting sounds like it would be a very easy fit with backbone. I follow an event-driven architecture with my backbone apps and I find it works very well. it keeps code clean and separated, and allows me to add functionality easily by binding to events that my objects raise.
there are a lot of great tutorials and screencasts for backbone out there, too. here a few of them that should hopefully give you some of the information you need (including my own blog posts):
http://lostechies.com/derickbailey/category/backbone/
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ (introduce event-driven apps in backbone)
http://joeybeninghove.com/2011/08/16/backbone-screencast-introduction-views/
http://peepcode.com/products/backbone-js ($)
http://tekpub.com/view/mvc3/6 ($ and specific to ASP.NET MVC integration)
again, don't just pick one and never look back. it's worth your time to at least do some simple trial applications in backbone and sproutcore, if not additional frameworks.
hope that helps.
With Sproutcore, you can create so-called frameworks so separate your application. Every SC project has a frameworks directory, you just add a directory for your custom frameworks, and include the frameworks in your buildfile.
It's not a bad idea with SC to at least separate your Model layer into its own framework, for loose coupling and testing purposes (SC is heavily MVC). It might make sense to separate your screens into their own frameworks, depending on how beefy they are. One of the benefits of this approach is you can reuse your frameworks in other projects if needed.
SC also includes a robust Statechart mechanism, so using custom events is quite natural, and because of the statecharts its relatively easy to insure that the events are handled only when the app is in the right state.
Have you tried the Relay framework? Your write your individual screens as standalone modules and use relay's event system to link them together.
http://relay.github.com
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