backbone or ext/sencha touch or both - javascript

We have a website written in the traditional Jquery selector-callback spagetti code. We are planning to begin migration to backbone to help clean things up.
We use mustache and use the same templates for rendering in php server-side and javascript client-side. But there are some mustache alternatives (handlerbars/dust) that we are interested in but can't explore because there is currently no php alternative. We are considering moving all server-side rendering to node so we can use the same logic/code for client and server rendering. We would be porting all our php view classes to javascript/backbone and just use php as our data/controller layer.
In parallel, we are preparing to develop a sencha touch website/app which would normally be written using the sencha/ext approaches in javascript.
The actual templating will be very different between the sencha and main site, but much of the view models could probably be the same.
There are three approaches I can think of:
use backbone as the main view models including inside sencha
use sencha everywhere using the sencha/ext classes/approach in the main site
keep them separate and either deal with duplication or try to abstract out the essential logic to other classes.

One advantage of the ExtJS route is you can use the same models, stores, etc and just have separate views, grids, whathaveyous for mobile/non-mobile. Then you can just serve up the same JSON/XML from PHP. The JsonStore/XmlStores will be the same on each platform. Been a while since I've used ExtJS so cannot offer more concise example.

Related

best practice/architecture to combine multiple js components in a spa

I would like to have the following architecture for a single page application:
each page or a widget can be an independent reusable module (reusable for this project however it might be used on others as well)
there will be a core application that will use all those external modules. the core application will be able to communicate with the modules and vice versa.
each module can be written in any technology (react, angular, vanilla)
each module should be deployed independently (something like dynamic-lazy-loading)
the core app should be responsible for the config of the modules (api urls etc)
I have not been able to think about a good way of achieving everything i stated nor find anything on google.. but i might be missing the keyword for such architecture.
Any ideas, best practices or just some relevant input? thanks!
after researching this subject bit more, the architecture that i think that will match my requirements is based on web-components (can read more about it here - http://webcomponents.org/ and would recommend using a library like polymer).
the advantage of a web-components is that they can hold everything they need in them (html,css,ajax requests, basically anything that can be in a html document) and using shadow or shady dom imply those components into the document just like we would have done once with iframes.
by using this architecture, you will be able to migrate your components without caring about the wrappers technology (angular 1/2,react, knockout, vanilla js etc). for example, in order to use it in angular, we just wrap a component with a directive and thats it.
the other bonus is that you can even host those components in different servers and therefore deploy them separately.

Styling and Connecting the Backbone to a Ruby Server

So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!

iCanHaz.js - separating templates?

Using ICanHaz.js is really nice - it's dead simple to create, load and render templates from javascript objects. However, in a somewhat big javascript application, the .html-file that initiates my application and contains all the ICanHaz-templates has become really crowded with template-script tags.
So how should I separate my templates to make things clear again? Are there an alternative to IcanHaz.js that applies better to larger projects?
Most client side template engines have the same concept.
You could load the templates remotely using XHR but that will add a terrible overhead of the HTTP request.
A better alternative could be creating each one in its own file, and having a server side script merge then in to your HTML page.
Finally, the last option is to add them inline in your javascript rendering functions - this will work for very small templates.

extjs application architecture

I am developing a extjs application, and I am just a starter.
It's quite different develop mode for me, and I feel puzzled.
My first question is about client-end architecture, I'm developing a little app now, so I wrote all js codes in only one html file, what if I need to develop a huge app?
like this: [Article Manage(leaf in tree)] -> [CURD List(Data Grid)] -> [Edit Article(Dialog Box)]
There will be lot of leaf in my tree, so there are many XXX Manage.
What should I manage my client-end js files(file structure or something else), and how to load these files dynamically? Is there any exists demo?
um.. maybe what I really want to ask is:
How to put my code for every module into different js files and 'include' the dynamically?
I've got the answer, just use loader property of a container component, this method fit me well. Thanks to all of you.
There are no patterns set in stone, but here's one way to Write a Big Application in Ext 3.x.
Another good resource for ideas, generic to JavaScript, is Nicholas Zakas's video on Scalable JavaScript Application Architecture on YUI Theater.
In my mind the big things to do are:
Write standalone components (think: UI container, data structure, etc) with no dependencies to other components on the page.
When you want to two components to interact, have their parent container wire them together.
Have some kind of logical directory structure for development (doesn't matter what exactly), splitting out each of your "components" into its own file -- even if you plan on combining them into a single file for deployment.
Not sure if I correctly understood your question, but I'll try to answer. For bigger applications use MVC pattern which allows you to split your application to components such as Stores, Controllers, Views etc. Then you can easily send data from server in JSON for example (using server-side technologies - php, java,...) and read it by Stores proxy. If you look into Samples & Demos they're also loading some bigger structures using php script which returns JSON.

Which Javascript framework/library to use to manage views/screens in an HTML application?

I am developing an rich Javascript application, using jQuery and some plugins. The application I am developing is becoming rather large and unwieldy. My main problem is managing views: I need to switch between views, some of which share the same components (like embedded views or partials). Currently my "screens" are all contained in various divs, and I am switching between them by hiding one and showing another. This makes navigation quite complex.
My question is: Is there a lightweight Javascript library that can help?
Following requirements:
No generation; I want to change the code on the deployment server, so frameworks requiring some special compilation are out of the question (like Sproutcore or GWT)
Model binding is not a necessity; I am getting the values from various forms and submitting them via Ajax requests
Want everything loaded upfront (i.e. not fetching screens with AJAX)
Must work with IE7
mootools, you can select what components you need from the framework.
http://mootools.net/core/
It turns out that what I was looking for all along was Dojo.
Dojo provides as part of its library the dijit subset library, which covers all the needed UI metaphors, including containers.
Also, as required, it does not involve any compilation as do many of the other Javascript (MVC) frameworks, and it supports IE from version 6.

Categories