Isotope lets you write templates in javascript. These templates can then be rendered by either the client (using plain-old javascript) or on the server (using Johnson).
The benefit is DRYer code. When updating the DOM on an ajax or web socket update, you can don't have to write a new partial...just point it to the one you already wrote.
Has anyone used this?
Interesting, I would have to try it, however , and I know not a lot of people do it, but I actually use HAML to template .js files. Although there is still that problem the author mentions , of each request being templated on the server and sending back html, unless you are sending loads of kb, or you have really, really high load site I don't think it's such a big deal.
Also ideally you shouldn't be even sending html data back and force, just JSON objects, which are rendered on the page by your ajax request. The only legitimate use I can see for this is if you have heavily ajax website, such as where you load a page once, and the you just keeping doing ajax requests for all interaction and javascript to manipulate view.
So it would help if you would clarify the final goal. Is this for some internal app where you control user environment ( you know for sure which browsers they will use, and that they will have fast enough computers to manipulate all this javascript?) Or is it going to be an app targeted towards 3rd world, where people don't have yet resources available to use all that fancy javascript.
All that said, it's an interesting concept, and I will try it our myself, to see how well it works.
This uses Johnson, which last I checked did not work on Ruby 1.9. So that might hint at some of the immaturity of this particular solution. Eventually the community will come up with something that works really well.
One approach I have used is to make 2 completely separate templates, but try to make them as similar as possible so that it is easy to port changes from one to the other.
This seems like a bad idea. In an Ajax application, I believe that the server should be responsible for rendering all display text. This makes i18n easier, and concentrates everything in one place. The JavaScript should simply receive data from the server, with all display text already rendered, and put it in the appropriate DOM object.
In other words, I believe that in an Ajax application, the need for a JS template engine is itself a design smell.
The situation is different in exclusively client-side JS applications, of course.
Related
I need to ask you guys/gals out there about a concept of website development that I'm not finding a whole lot of documentation about. Maybe I'm using the wrong vocabulary? It's basicly rendering the views (in a MVC type sites) on the client side vs server side.
Here's what I know so far. Commonly in a Model, Controller, View type website, the view is what the HTML/CSS/Javascript design gets programmed to. Now the idea is that the server processes all the HTML/CSS/Javascript, and what gets sent to the client browser, is the finished view. I believe this applies to C#, MS.net, Java, PHP, as well as Rails.
Now, the way client-side works is, the server stops at trying to render views for HTML/CSS/Javascript, and instead only renders views for raw XML data. In addition, a Javascript like program (handlebars.js and mustache.js, eg) is downloaded once, cached, and the XML data is feed through the javascript program which in turn dynamically creates the HTML/CSS/Javascript view. The idea behind this is that only XML data, the initial JS program, and media are the only things needed from the server. Instead of refreshing the page each time, only XML or JSON data is needed.
Now, I can see an advantage for a small business that wishes to advertise, blogs, resellers, etc. 1. Minimize the amount of raw data that comes out of the company server, and 2. Send media and precompiled code to a cloud serving site like amazon.com.
But what if all information needs to be served from the company's servers? It seems to me that a number of arguments towards choosing client-side have already been addressed in Rails 3+
How can I find out more information about this so I can make a more knowledgeable decision as to choose client vs server?
All comments are welcome! Thanks (^_^)
Servers only touch PHP, Java, ASP.NET(C# and VB.NET), etc. JavaScript is a Client Side Code. the MVC Model is more for the Server side code on how you break it up. It tries to keep the logic away from the design. a good example of how this works would be Magento.
Also, client-side code is vulnerable to hackers
http://php-html.net/tutorials/model-view-controller-in-php/
I'm using .NET MVC for all my serverside logic and serving out initial pages, but my application is very heavy on the client-side so I have adopted Backbone.JS which is proving to be very useful.
I'm unsure how to architect my system to incorporate both technologies though. The way I see it I have two options
Scrap the 'V' from MVC on the server-side, return JSON Data to the
client on pageload and use backbone clientside templates to build up
the GUI from the base JSON/Backbone Models.
Return the initial pages from the server fully rendered in .NET MVC.
Also return the data that was used to render them and call the
collection.reset({silent: true}) method to link up the
returned data to the view. Am I right in thinking that this will
allow me to subsequently make changes to using the add/remove/change
handlers on the views?
1 Troubles me as I'm afraid of letting go of any part of server-side MVC, its where my core skill lies.
2 Troubles me as I'm concerned I might be introducing risk and work by having two different rendering methods on client server.
Whats the correct way to combine Server-side MVC with backbone.js 1 or 2 or some other way?
You are not really scrapping the V, you're just changing it's representation from HTML to JSON. You are troubled because you feel more comfortable with the server side stuff, and that's not really a valid concern... you'll get done what needs to be done, and learn/create the Javascript patterns as you go.
This is one way to do it, and it really helps if you need a javascript disabled fallback or you're bound by accessibility guidelines. The part you're missing is that you will have to re-render the page once it's loaded to attach your models up to the DOM elements. Alternatively you could use a tool that handles this mapping for you, but that's added complexity you'll have to weigh out yourself.
In the Careers usage of backbone, we are not bound to support javascript-less scenarios, and we so we just load the templates + js on the initial load, then let the router take over and use something more like your first idea. Since it sounds like you're just getting started, the biggest thing that helped us really get moving was realizing that it's way easier to make changes to your model and then let your views subscribe to model change events (instead of the other way around).
I don't know what the Accepted Way is, but I've found it problematic to combine V from the server side and then weaving Backbone (etc) in. In very controlled situations it can work out, but if your app is going to be extremely heavy on the client side, my suggestion would be to forget about rendering on the server side and just return JSON and let Backbone handle the rendering of your content through some sort of templating (Mustache, etc).
Yes, you have full control over the Backbone events, so you will have a handle on them to do what you wish.
I hear you about giving up part of your skill set on the server side. I was the same way but if this is what your project calls for, I think you'll find it easier to let the server side rendering go for this.
Good luck!
Being some random rails dev, and getting around all those backbone/underscore javascript stuff…
Backbone seems interesting, but in a functional point of view (I mean the way you can get your data back from the db and your page can be updated), I can't see any real good reason to move forward to backbone. I'm saying, compared to the RJS approach rails bring.
With backbone, more things happens on the client side; but can't see any fundamental difference besides this fact
Any backbone-evangelist's feedback appreciated
It's definitely going to be a matter of preference, but here's some rambling as to why you might want to go with something like Backbone over something like RJS.
RJS is great for when you just need to return code like $('#post_#{#post.id}').slideUp() or something like that. When you want the backend to be in control of the front-end directly. This does make sense for a lot of apps, for sure. But when you start getting into more complex stuff: change the post title, change the post body, change the post tags, change the post title in the 'recent posts' sidebar, etc. This can get difficult to maintain quick. If you change the markup subtly you can break all of your RJS. Also, using RJS, it's pretty difficult to change the whole page and keep the user sane (eg, you will break back buttons and generally stomp all over the state in the browser).
So, for bigger/more end-to-end applications, you can institute something like Backbone as a way to keep your code organized, and move the logic to handle the display of your data to the client. Some benefits:
You will put less load on your server, since the client will do a lot of rendering work.
You change some markup in a client side template, it's natural and simple to modify the corresponding Backbone.View if there are changes to make there, instead of at the bottom of potentially several controller actions in Rails.
You can easily handle navigation between multiple pages/states, and keep that logic on the client.
It's very easy and low-barrier to organize your javascript strictly into whatever makes sense for your app (eg, collections.js, models.js, views.js, or maybe app.js for smaller stuff, or maybe post_view.js, posts_collection.js... whatever you need)... again rather than having javascript spread into procedural chunks all over Rails.
If you have an application that lends itself well to being on a single page (eg, lots of shared elements like navigation/sidebars/etc between pages for example), then it's going to be a pretty good fit for something like Backbone.
Your Rails app can act more like an API which any number of front-ends can use - the Backbone one for the web, an iPhone app, and so on.
There are surely downsides, too. You have to write at least some of your application's view/controller logic in Java(/Coffee)Script, and you have to be careful, when you don't reload the page for long periods, not to cause memory leaks and javascript errors that can kill your app. When is it not about tradeoffs, right?
A high profile example of someone not using Backbone when it otherwise might have been considered a good idea can be found at this 37signals post about Basecamp Next (and the corresponding HN discussion).
Let me know if I can clarify anything here for you.
Is it common practice for people to NOT use rail's built in support for ajax? Or is it very flexible and it can really help speed things up and there is no need to go custom?
If by ajax you mean ajax view helpers, in rails 3 they are implemented quite well, and there really isn't a reason not to use them. If you mean RJS, it is a much faster way to get stuff done, but if you want to build highly dynamic and responsive interfaces, there is no shortcut to writing the javascript yourself.
Rails 2 was heavily tied to Prototype and was pretty obtrusive; it seemed a lot of people didn't use. Rails 3 is far more unobtrusive and framework-agnostic, and I expect it will be used a lot more.
Let me put it this way..
Using built in ajax functionalities will will save lot of your time and get your app up an running with no-time. But the problem is once your app starts growing and when you need more and more cool ajax features, its hard to manage.
Another thing is, If you are working on a team and there are UI designers to implement UI. sometimes they find it difficult to deal with built-in rails ajax functions. As they prefer go with pure Ajax framework and HTML.
Basic concept here is to let the UI designers to implement a user friendly interface while rails supports back-end features
** I really like the rails3 approach of Unobtrusive javascripts. which makes the clear separation of java scripts and server code
So as a sum up - Its all depending on the requirement. If you are looking at a small scale project with defined ajax functionalities you may go with default rails ajax support.
But if your app will grow and if you want to continuously implement your user experience its a good idea to have your own custom ajax implementations up on proven framework like jquery
cheers
sameera
I am not sure what you mean by built-in support for ajax. Because Rails has very good support for Prototype and jQuery.
But in rails 3 there is (good) push towards unobtrusive javascript, and that is indeed imho what most people do.
If you are talking about rjs, generating javascript with ruby code: that is imho best avoided. Sometimes it is good to get you started, and doing things unobtrusively is sometimes a bit harder at first, but it is generally much better.
The rant against rjs: it is not unobtrusive, you mix two languages, it only works for very straightforward cases (granted most cases). But because you can't do everything with rjs, there is bound to be a need to let some 'real' javascript slip in.
At first i really liked rjs: one language to do everything in. Until you discover the boundaries, and then you are stuck.
So i would suggest, for anybody new beginning in Rails: skip rjs. It will help you in the long run. Do javascript unobtrusively.
It is the same division in CSS: you want all your stylistic definitions separate from the content. Well, actually in js you want the same: you want your behaviour separated from the content. This makes for very clean HTML, clean CSS and clean js.
I'm working on my first Ruby on Rails aplication and it's quite big (at least for me ;) - database has about 25 tables). I'm still learning Ruby and Rails and I never wrote anything in Javascript nor Ajax.
Should I add Ajax to my application from the beginning? Or maybe it will be better to add it latter?
Or in the other words: is it (relatively) easy to add ajax to existing web application?
Jeremy Keith has written a great article on this topic, which he refers to as Hijax
In short:
Plan for Ajax from the start.
Implement Ajax at the end.
Depends on how important Ajax is for the application. Since you are probably going to use Ajax for progressive usability enhancements only, I would say it is best to start with a traditional non-Ajax software, and add Ajax features only when you have the first features working. You can do this feature by feature, or write the whole software first, and then start ajaxing it.
Adding Ajax may be easier if you familiarize yourself with unobtrusive JavaScript techniques. Use jQuery instead of Prototype.js, or LowPro in addition to Prototype.js. For the latter, see e.g. Jarkko Laine's PDF book Unobtrusive Prototype.js.
If you are planning to do AJAX, I would do it from the beginning. It will help you structure your controller actions and views, especially with respect to generating some data in partial views, correctly from the very beginning. Knowing that some actions need to be able to render just parts of the page will change your design. This isn't to say that you can't go back and retrofit the design, but I think it's easier to get the design right if you design with this in mind up-front. You should also consider how to make it work without AJAX (or javascript at all), too so that your design is as fail-safe as possible. That doesn't mean that all functionality has to be available, but that important functionality works in the absence of javascript. For example, action links that use AJAX should have a default url that will invoke the correct action via a GET request if the javascript isn't enabled. Forms that post via AJAX should also work if posted normally. Dynamic behavior (like an image gallery) should have a usable, alternative view that works, etc.