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?
Related
I've been learning Angular 2 recently, and I must say that this is a great framework if I wanted to build a single-page application.
However, I was wondering how one would integrate angular with a normal, old style websites (say, built on codeigniter) if they only wanted the two way binding functionality?
Of course, I could use angular 2 for that, but with all the routing machinery of angular, it seems rather... out of place. It just seems like I'm trying to use an axe as a hammer.
So, my question is: what would you suggest to someone who wants to build a non single-page website, with old school loading pages, but for the page itself to be very interactive and utilize two way binding? For example, a users list which is a page in itself, but pagination is done via ajax... etc Should I just go with angular2, or maybe another library that's simply more suited for this purpose? Some suggested that ReactJS may just be what I'm looking for.
What do you think?
Although it's true that
client-side routing is just a small piece
of a very large framework, the fact that the structure of a Angular (2) project has exactly 1 index.html file with no server side code, at least implicitly tells us that there's a lot of framework intended for SPAs which a multi-page application may not need.
If what makes Angular 2 a great framework for you is data binding and productivity then have a look at Ember.js. Ember makes it easy to follow best practices rather than spending time on trivial choices.
I am going to create a big application, SAAS type.
Laravel & Angular has been decided to be used in the project. But I am new to both of these as I am cakephp background.
Now I am trying to take this decision. Whether should I keep both angular and Laravel a completely seperate projects. where Laravel is behaving purely as an API Or should I mix these both. I have seen people serving angular templates from laravel.
I'll have a mobile application for the same later, so that's another thing I have to keep in mind.
I am not sure if that's ok to ask such question here but I'll still appreciate any guidance on this here.
I would recommend separating them altogether. In this way, your projects/repos only contain one "environment" or context, which in my opinion makes everything cleaner. It also helps reusability, in that your API becomes completely app agnostic. You can of course still serve them from the same server.
Separating the components also make them easier to test in CI, because you'll only have to test one component at a time.
I'd recommend versioning the API, especially during early development, so that versions of the app can target a specific version of the API. Developing "API first" in iterations minimizes problems with compatibility between the two components as long as there are few breaking changes from the API side.
I'm studying a bit of ember and I like it so far. The problem I have with ember (and most frameworks I saw, both server and client side) is that almost all tutorials and guides are designed for small apps (as TodoMVC). I'm interested about how to handle huge administrative apps (like 30 or 40 pages, or more). That reason made me go for framework-less apps many times. What I saw is that you can use Yeoman or another tool to build a single js file and html. Most people focus in how to split the code in development and it's okay. I want to ask you how to divide the code that is downloaded at runtime. I think (maybe I'm outdated) that the users of administrative apps don't have to wait for the load of the whole app. They use 4 or 5 pages of the whole stack most of the time. I read briefly about require.js but ember doesn't advocate using it. What I need is a way of lazy load templates and javascript code like routers, controllers, etc.
How do you guys manage apps like those I mentioned?
There is a great blog post from #mixonic on this topic. It explains how you can use a before hook in the router to lazy-load scripts for one or more routes in your application. This technique can be used to lazy-load any application code including routes/controllers/models/templates or third party libraries.
http://madhatted.com/2013/6/29/lazy-loading-with-ember
I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.
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