Since Rails is already an effective Rich Internet Application framework because of the way it makes Ajax so easy, what is the argument for combining Rails with Flex and using Flex as the front end instead of HTML? A programmer friend of mine said he uses this combination because Flex is great for RIAs. My argument is that Rails is already great at that - why add additional complexity? Another big disadvantage of doing this, it seems, is that you cannot use HTML in your front end any longer because Flex makes this extremely problematic. That seems like a very high price to pay for whatever benefits this combination of technologies offers.
I think you want to consider this in terms of what your client app needs to do. If you can accomplish everything you need within rails, then there's no real need to go to flex. If you need more client-side control, then you can build a flex app and make the rails app just a web service.
It all depends on your definition of what a RIA (Rich Internet Application) really is. To some, an AJAX enable web application might fit the bill. To others, a RIA includes highly stylized elements, a high level of interactivity, and a good bit of animation.
If you're one of the people that think along the lines of the first requirements, then great. An AJAX enabled RoR app is going to be enough for your RIA. For those who belong to the second group, RoR is yet another way to provide the data backend for a RIA that uses Flex/Flash for it's presentation.
Personally, I believe that RoR combined with Flex is going to give you a much richer, dynamic, and engaging RIA than a standard AJAX enabled web application.
I wasn't aware people used Flex and rails all that much. But using Flash/Flex does give you a bit more processing and visualization power. Also, you can have native AMF support from Flex for efficient data transfer.
Related
Just got a new website project for my company internal use. The whole website isn't that complicating but requires quite a lot of real time interaction. Basically, it's an interactive time line table where we can freely drag and drop each elements to move and resize them.
At first I wanted to use this opportunity to learn Python+Django (I'm given a huge amount of time) but then I read around and a lot of people mentioned Rails is better for creating rich interactive website.
So, for a website with a lot of drag & drop interaction like this, is Rails really the better choice? Is Rails built-in ajax that much easier to work with compare to Django+jQuery? How flexible and customizable is Rails' built-in ajax? I want to learn RoR just as much as Python by thee way.
I don't think AJAX functionality will define which framework you find yourself preferring.
I can't answer most of your question relating to ajax, but still think this post could be useful for you: it's highlighting a huge difference between ROR and django -- mainly RoR uses magic, django doesn't.
I prefer django for exactly that. Others may prefer RoR for the same reason I don't.
What's wrong with "magic"?
Rails' developers are of the opinion
that this sort of "magic" is a good
thing because it makes it easier to
quickly get something working, and
doesn't bore you with lots of details
unless you want to reach in and start
overriding things.
Django's developers are of the opinion
that this sort of "magic" is a bad
thing because doesn't really save all
that much time (a few import
statements isn't a big deal in the
grand scheme of things), and has the
effect of hiding what's really going
on, making it harder to work out how
to override stuff, or harder to debug
if something goes wrong.
Both of these are, of course, valid
stances to take, and generally it
seems that people just naturally
gravitate to one or the other; those
who like the "magic" congregate around
Rails or frameworks which try to
emulate it, those who don't congregate
around Django or frameworks which try
to emulate it (and, in a broader
sense, these stances are somewhat
stereotypical of Ruby and Python
developers; Ruby developers tend to
like doing things one way, Python
developers tend to like doing things
another way).
So I think one will click for you regardless of out of the box ajax support.
Speaking as someone who mostly works on Rails, I would say take a day with each framework, follow a "getting started" screencast or tutorial, or pick up a book. ( For rails, I recommend Beginning Rails 3 ). Then, keep going with whichever one you feel more comfortable with.
One amazing resource rails has is Railscasts. Railscasts almost single-handedly converted me from PHP to ROR. I don't know if Django has a similar volume of quality screencasts available or not.
All frameworks are pretty heavily focused on the server-side of the equation. Now, Rails has a lot of things that help make writing views (your drag and drop stuff) nice, such as HAML (a fantastic template language)... and while I don't know enough to post links I'm sure Django has similar helpers. It's worth noting that both Django and Rails can use jQuery or any other javascript framework.
But, in the end, just by the nature of the web as stateless, there's going to be a degree of independence between your client-side templates and javascript, and what's serving that from the server side.
The real question you should probably be focused on is: Do you want to become a jQuery ninja, or do you want to scale up a notch and focus on Javascript itself, perhaps using tool suites like MooTools or Prototype. Your drag and drop stuff is client-side, so that's where your toughest decisions will have to be made.
Good luck!
I used to worry about things like this and would try new frameworks all the time because people would say it was a big improvement over the last one I was using until I realised I wasn't doing anything. Now I just pick one and stick with it. The fact that I know it much better than any others means I am more productive, even though the other frameworks probably include nice little tricks and shortcuts, and because I know it better I can debug problems faster.
Basically what I am trying to say is that just about every popular web framework can do everything that you want it to. Some are better than others but what really matters is that you become an expert in at least one of them. Being able to dabble in lots is not helpful, you really need to know one inside and out. Committing some code to the project helps this process.
Mainly depends on which programming language you prefer to work and most comfortable with. Some prefer the flexible syntax of Ruby others like the cleanliness of Python. Also need to take into consideration the production environment (aka what OS is it going to be hosted on).
Django does not do interactive web applications, it is agnostic to the whole "frontend" part, this is done in Javascript with little to no support from Django (except for transferring data from AJAX calls).
So if you want to use Django for this, you will have not only to learn Python but also to learn loads of Javascript.
I like this solution as hand-written Javascript feels a lot clearer than any of these generating tools to me, plus there are plenty of libraries that make writing advanced Javascript GUIs a breeze these days, check out Jquery UI or ExtJS.
From there, the server side will only be AJAX calls that (de)serialize data in JSON, nothing else.
Both Rails and Django are good. Try them both out and see which you like better.
How much does it matter what server side language is used for building a web app to take advantage of HTML 5? It seems to me that the ruby community will probably have the fastest uptake, and as a result the most support. Does that seem right? If I want to make a serious investment in HTML5, what server side language should I use?
It doesn't matter which server-side language you use, they all support HTML 5.
You just have to make sure you write good markup that can be validated.
You will gain experience writing HTML as you build more complicated web applications with server side languages. I'd focus on one of those first and let the HTML come to you as you need it.
One of the best ways to learn is by validating existing HTML and fixing all of the errors and warnings. This will help teach you the common mistakes made when writing HTML and get you more familiar with the rules.
As far as server side languages go, you have several options and there are tons of resources already online to help you make the right decision.
http://articles.sitepoint.com/article/server-side-language-right
http://forums.whirlpool.net.au/forum-replies-archive.cfm/90884.html
It's all about picking the one that is right for you. And, the best part is, if you pick a language that doesn't suit you, you can learn a new one later.
Also, here is some information on Books for Server Side Languages which may prove helpful.
It doesn't matter at all.
Whatever server side platform you use should not be based on what revision of HTML you will render. The two are completely decoupled. That is unless you opt for some framework that generates the HTML for you.
The server-side language you use has no bearing on HTML5.
Presentation frameworks, if you opt to utilize one, may take a while to take full advantage of HTML5.
I agree that the server side language may not matter much, though any framework you choose such as django or Ruby on Rails will hopefully have html helpers that you can use to build a view.
FWIW RoR 3.0 outputs valid HTML 5
http://guides.rails.info/3_0_release_notes.html
Vaadin and Apache Click seem to be equally good, which one should I choose for developing my web application. Or rather, what are the Pros and Cons of each framework.
I'm a committer of Apache Click but hopefully you will find my opinion objective.
I don't know Vaadin at all, just had a cursory look at their website and examples and mission statement.
Apache Click and Vaadin are meant for different problem spaces. Apache Click is targeted at traditional enterprise web applications while Vaadin targets the Rich Internet Application (RIA) space.
Apache Click is a traditional share nothing, stateless framework. Unlike traditional action based web frameworks Click provides a slightly higher level of abstraction by using Pages and Components. At the of the day Click isn't a revolution. Its just one of many approaches of doing web application development. In my opinion its a very good approach, both from a developer and maintainer point of view. (In enterprise environments the developer and maintainer are often not the same individual, so I differentiate between the two roles).
However developers sometimes have requirements that cannot be satisfied by traditional web applications, which is where RIA comes in. They provide a richer user experience (think desktop) but this does not come for free. RIA comes at a cost in terms of complexity, productivity and time-to-market. It makes sense though, if the requirements are for a richer experience, you need to do more in order to deliver that experience.
My advice here is: think carefully about your requirements. Don't simply assume that RIA is better, there is a price to pay, so make sure you get return for your investment.
Lastly, if your requirement is for RIA, then you should compare Vaadin with Flex. If your requirement is for a more traditional web application then compare Click with Struts, Stripes, Wicket, Tapestry etc.
Kind regards
Bob
I use both ;-)
Click is the best for classic web applications (pure html with no/ small/ handmade javascript).
It is very lightweight (small size and stateless), less verbose (you can do your html in html with velocity/freemarker power ;-).
A real php-killer.
Vaadin is the best for desktop like enterprise applications.
It is statefull, heavyweight, verbose, but amazing.
Grails, Play!, Spring MVC is a real step back after Click/Vaadin.
So my advice: use both!
For most of your pages you will use Click, for complicated tasks - Vaadin.
I've been using Click since 2006. I've built various web applications with it in the last 4 years. All apps (B2B) are still going strong and continue to be maintained/added to now. The best things about Click IMO include:
Very little magic and almost no plumbing. It's all just plain java (and jsp/velocity/freemarker take your pick; or alternatively use all 3 if you so choose; I have for some scenarios because it's so easy to).
It's super fast (It doesn't mean your app won't be slow, it just means Click will never be the reason why your app is slow)
It is so easy to integrate your favourite java lib eg. Ibatis SQLMAP, Spring, displaytag, DWR etc.etc.
You don't need to buy a book to understand/use it (although you may need books for all the other 3rd part libs you plan to use).
Most of my code written 4 years ago still works with the current release. That is just awesome.
Click fits in your head. The whole framework that is. It is so simple you don't have too many questions even as a beginner.
The guys that maintain Click are super responsive and very noob friendly.
It's simplicity helps my apps adapt to new/old tech. i.e I can easily do AJAXy stuff if I want or not.
The form features make handling html forms very easy/fast.
The table features make displaying data super easy/fast
Click's features help me write apps very quickly. Makes the need for scaffolding unnecessary imo.
If you want a light weight, fast, easy to understand framework which helps you build applications as fast as you or your team are personally able to, check out click, it will be worth your while.
Before making your choice you should evaluate all options by taking them out on a test drive.
I'm not familiar with Click, and someone should correct me if I'm wrong, but I understand Click basically a technique to link your server side code to web pages. The UI is page-based and you define the UI with components corresponding to HTML elements. Ajax is not (yet) supported, I gather.
Vaadin operates at a higher level of abstraction. With Vaadin you get to concentrate on your business logic, and build your UI naturally with views, layouts and other components (check out the Sampler). You don't need to care about RPC, page transitions, HTML or templates. Vaadin gives you a fully cross-browser compliant Ajax UI that looks and works great out of the box. It's very easy to get started, and the forum is very active (>700 messages last month compared to 96 on the Click mailing list).
Disclaimer: I'm a member of the Vaadin team and have not used Click.
I would choose, and I already did in a few projects Click (over all other frameworks).
The main selling point for me was that I was able to learn Click and be quite productive in one week-end (Vaadin - but other frameworks too took me much more).
The free and available documentation for Click is much better - you can compare the sites yourself (even if the Vaadin site looks cooler, the Click site is simply more useful - at least it was for me).
The live examples are much better - I always look at them as a snippet repository, and just copy what I need from there (since I'm a lazy programmer :) ) - there's a "Page Java" and "Page HTML" link for every example that shows the source code for every available example.
Regarding the message traffic, I don't think that should be a criteria, since having so good free online docs, and the framework being so much simpler, the users simply don't need to ask that much.
Disclaimer: I'm just a simple user that have used both frameworks.
Is Apache wicket an option as well ?
My experience is with jboss/ejb/jquery, but looking at technologies for starting a new project. I've done a quick bit of research myself abd Vaadin seems to be very well regarded.
Surely Apache Wicket is something you can not ignore if you are comparing UI frameworks. ( I am doing same.) I dropped Vaadin because of poor documentation ( maybe I am not a good Googler.)
Currently comparing Wicket, Click, and ZK.
Click and Wicket are ahead so far for the following reasons:
Generates pure HTML instead of rendering UI using JavaScript which happens in GWT, Vaadin, and ZK. You can use HTML5 features then.
Even with native HTML, server-side binding of UI forms is possible.
You don't need to worry about communication with the server. ZK also does this but with their own language ZUML.
I have found server-side memory footprint higher in ZK in the case of components like the ZK Grid. (Memory footprint for Click is not known to me yet.)
I'm working on a application that requires a feature-rich media view, including images, videos, and smooth sequencing based on capture time. The backend is currently written in Rails.
What's currently the best, most mature option for implementing RIAs with Rails on the backend? I've looked at Flex, Laszlo, and ExtJS. ExtJS is interesting to me because I'm really not a fan of pure Flash UIs, but it seems highly targeted towards business apps, not entertainment applications like this.
Any suggestions or insights from others doing similar efforts will be very much appreciated.
Thanks!
I second zdmytriv for that book Flexible Rails, it's awesome. It's fairly outdated now though but lays out how simple it is to create a solid Project Management application with Flex and Rails. Everything in there has now become "RestfulX".
Check out RestfulX, it's a must. The RestfulX Google Group is very active too and they've made a lot easy.
We built this website in Flex with RestfulX and it was very easy. That application uses the Rails Paperclip gem to do image processing in a Flex admin panel like ScrapBlog (Scrapblog was built in Flex), and we could use some cool layout effects built into Flex 4. RestfulX made that pretty easy, and the gems made it even easier :p. They have generators too like Rails so it's real easy to get up and running with a DataGrid/CMS-like interface in 5 minutes.
I don't know anything about the other things you've mentioned, but I do know that it's pretty fun and easy to integrate Flex with Rails now-a-days.
As a side note, you can do hardcore SEO with Flex and Rails too, thanks to SWFAddress. We're doing that with that site above.
Cheers
I can recommend Flex and also this book Flexible Rails, whole book dedicated Flex with Rail cooperation. List of sample applications from the book here
Flexible Rails http://ecx.images-amazon.com/images/I/51QysfVDlVL._SL500_AA240_.jpg
If you're serious about considering Ext as an option, you should really search and maybe post in their forums about others using Rails, I know there are quite a few doing so successfully. I just ran across this example that seems like a pretty fully-baked app doing just that, so it's definitely possible.
Without knowing exactly what you're trying to do, I think that saying Ext is "targeted towards business apps" is a fair general statement, in terms of the widgets that come with it out of the box. It's highly geared toward window/form-based Ajax apps. That said, Ext Core is very similar to jQuery and other core frameworks, and everything in Ext is built to be highly extensible (hence, "ext"). In terms of being able to build what you need off of it, it is very powerful and flexible. You can certainly implement a flash viewer easily, and there are existing plugins that will do exactly that.
Sounds like Toby had a bad experience with Ext, but many other people enjoy it and find it very natural to code in. The syntax definitely has a Java/C# flavor to it in some ways (although it's really hard to directly compare any JS framework to a static language), and it has roots in YUI (which is even more verbose). For someone coming from C-ish backgrounds, it will likely feel very comfortable. If you're more used to Python or Ruby or something else, then it might not be as enjoyable, I don't know. Something you'd have to try for yourself.
Take a look at WebOrb from themidnightcoders.com. Among many features, it allows for AMF protocol for serialization of data. It is smoking fast.
IMO, if you want a true RIA experience, you'll need to focus on either Flex or Silverlight. There are pros and cons to each.
I did a GWT project a while back and am working with Ext right now. I have some C# / Swing GUI experience, none in Flash.
I like Ext a lot. It looks great, and I found the programming model close enough to the C#'s and Swings of the world as to be familiar and fairly pleasant. The documentation is not excellent, but definitely good enough. For Java at least, there is a solid remoting mechanism (third party, called DJN... most likely there are others, too). A couple of minor bugs here and there.
The major negative is support. They have a forum but there are a distressingly large number of questions and problems that go unresolved. They have paid support in theory, but were sufficiently unresponsive to basic 'how does your paid support work' type questions that I was not encouraged to buy any. There is only one book that I know of, it looks promising but it is not out yet.
I found GWT impressive and had no real problems, but at the end of of the day I am much happier with Ext.
Have you taken a look at Google Web Toolkit yet? In my opinion it's a great way to build rich and performant web applications. The toolkit is quite mature (Google Wave is build with it) and has a lot of good tools to make development easy.
Here's a previous Stakoverflow post.
I don't know about best, but I did a project using ExtJS and hated every minute of it. Frustratingly verbose code, overly complicated programming model, confusing documentation, and difficult to make it do anything it didn't want to.
That said, it looks very awesome, has incredibly powerful widgets and the client and users loved it.
I haven't helped at all, have I?
I think if you requirements include doing anything with video and audio, you are going to need a Flash solution.
Take a look at netzke -- client-server components with Sencha Ext JS and Ruby on Rails.
Netzke is a framework that allows for a beautiful blend of client- and
server-side code (JavaScript and Ruby, respectively) into ready-to-use
GUI components. It's most useful for creating complex data-rich
backend applications with Ruby on Rails on the back end, and Sencha
Ext JS in the browser.
I am building a site that has a lot in common with a person-on-person chess site. I was thinking of using Rails for the front-end(User Registration, Navigation, etc) and something like Scala or Erlang for the engine(Game state and maybe AI). I was wondering -
Is this a good situation to use that type of design?
How exactly would be best to divide up the functionality between the components?
How would they best communicate with each other?
I'm open to any technologies or ideas.
If you're using Rails for the front-end, why not use Ruby?
If you like the idea of using Scala, why not use Lift for the front-end?
Chess is turn-based, and has a very simple board that can be handled with HTML and/or Javascript enhancements - so the basic model flows quite nicely with existing web frameworks.
With this in mind, Rails is a great choice for creating a web-based application. Rails is not just limited to crud applications, and in fact I think can write your entire app in Rails/Ruby - you don't really need to have an external engine.
Within the browser space, polling for turn updates can be done using XMLHttpRequest and a database can maintain the current game and turn state.
Looks like a simple Lift application to me. I'm not experienced with Lift, mind you, but it doesn't seem particularly more complex than the chat application that is so often demoed.
I would start by reading http://www.htdp.org/ How to Design Programs. The questions you have asked are very broad and difficult to answer without prefixing statements with "I believe that..."
I would code it in clojure (but that's just me).
I'm currently developing a suite of online games, using Scala. It's been absolutely fantastic - my game logic is much easier to get right with the static typing etc, and dealing with server/client protocol (a flash client, in this case) is made simpler via the use of Google Protocol Buffers.
If you're a huge fan of RoR, by all means use that. I think most statically typed languages are terrible to program websites in (Java, I'm looking at you here), but Scala gets rid of 90% of the pain, and gives even more safety.
Of course, it might not be your cup of tea. But I'd try just doing the entire thing in Scala, and adding another layer if that doesn't quite do it for you.
For question 1 Yes
And for 2 and 3 you need to give more information in order to get an answer that could help you.
Now I'm doing something like you but for the front end I'm going to use Grails. The reason are very simple: I like Grails, Scala and I want to mix them :)