Slashdot Mirror
Ajax On Rails
mu-sly writes "Ajax and Rails - probably two of the biggest buzzwords in web development at the moment. In this article over at ONLamp, Curt Hibbs introduces the incredibly powerful Ajax support that is part of the Ruby on Rails web application framework. It's a great read, and serves as a gentle introduction to the cool stuff you can accomplish with ease using the Ajax features of Rails."
Every time I see material surrounding Ruby on Rails, I'm further convinced that it could be the web application programming foundation that starts to displace PHP as developers start to look at the transition from PHP 4 to PHP 5. Getting an increased install base for ruby on rails, as is the case with php (a fairly difficult task, admittedly) would definitely help no end in increasing the framework's popularity, at least amongst those programming smaller web applications.
Business Voyeur
b) Microsoft's own technology being used by Google to loosen Redmond's deathgrip on the market?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Of course Rails isnt the only completely F/OSS web application framework; Rails is best when you want to put relational data online: It's edge is it's simplicity.
On the other hand remember Zope - If you can get your head around Aqusition, the ZODB and Product Deveopment then Zope is a super-fast development platform.
Ajax grew from one of those hated, non-standard Microsoft features.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
You should probably read this paper on scripting
The moral is, no matter how complex a system build on Ruby will get, it will always be more simple to use than a system build on Java, just because Java carries the characteristics of a systems programming language while Ruby carries the characteristics of a scripting programming language.
Scripting is not a holy grail. The only fundamentall advantage of scripting is name-based polymorphism (i.e. dynamic dispatch), it allows you to skip extracting common interfaces in your object model. As the software grows this advantage soon becomes negligible, and may even turn to disadvantage, because you'll have to find and isolate general interfaces manually.
I am sick of seeing this excuse. You can't run around the internet screaming how rails is the greatest thing since the wheel, and how it renders java obsolete because its 100x faster to work with, and then say "its not done" when people actually try to use it. If you are ready to hype something and tell everyone how great it is, then you need to be ready to accept criticism too. If we can't compare it yet because it isn't finished, then stop running around telling us how great it is and how we should all be using it.
You don't understand one of the most important necessary preconditions for a larger web app in corporations - someone to approve it.
J2EE and ASP.NET have rich organizations that they can loan you to take key decision makers (CFOs) out to lunch to help approve expensive J2EE projects.
Compared to the Oracle sales guy flying my previous CFO out to some golf conference to pitch their J2EE-based framework, Rails has NOTHING..
I speak from experience - We had the case of One Oracle Salesguy against EVERY SINGLE internally developer telling this CFO that the Oracle framework sucked and that even Oracle was moving to Tomcat. Guess who won.
That feature - the lunch&conference&golf budget - and that feature alone is enough to make J2EE and ASP.NET win most corporate environments.
ActiveRecord is a *design pattern*. It dictates, to a certain extent, the shape of the database it supports. In reality, using it well is often a relatively good way to get a flexible/good schema from scratch with less db knowledge. It's not completely braindead, but a reasonably aware developer can do much better with the active record limitations than with a blank slate IMHO.
Rails itself could be put on top of any persistence layer. Instiki uses Madeliene instead of AR and it works fine. It just comes, out of box, with AR installed and that is the most natural. If you write your own ORM, it can work with rails. People have had success working with legacy schemas by frontending them with postgres views that behave more in the way that AR expects.
In any case, rails is more suited to new projects with new databases at this time. AR doesn't propose nonstandard database design in principle, it just dictates certain facts (mostly naming conventions for columns/tables) which can often be overridden. The most obvious one is that rails expects non-join tables to have an INT(11) PRIMARY KEY AUTO_INCREMENT field. Not being a DBA, I don't know what database design patterns are out there. Being a performance and efficiency conscious developer, I don't see how AR's patterns could get you into a performance or maintainability muddle by using them on a new project.
No, the fundamental advantage of dynamic languages is programmer productivity. You can accomplish a goal in a dynamic language like Scheme, Smalltalk, Python, or Ruby in 100 lines that would require 500 or more lines of Java. That's also an advantage when you have to modify the code--there's less of it and it's faster and easier to read as a result. It's also much simpler and faster to create unit tests in dynamic languages, leading to more and faster testing of projects. These advantages grow with the size of the project.
The other advantage of dynamic languages is flexibility. While Java has limited support for features like reflection and generics, dynamic languages have offered much more powerful and easy to use versions of these features for years. Java is also missing other dynamic features like closures and metaprogramming. Groovy's feature list is an inverted list of many of the limitations in Java's dynamic capabilities.
Java's main contribution to programming languages isn't any new feature. It doesn't have any significant new features, and most of its main features like object orientation, byte-compilation/VM and primitive concurrency were in other languages like Simula and Pascal in the 1960s or 1970s. Java's primary contribution is that it was well marketed and that its limited dynamic features have inspired a large number of programmers to want more of the flexibility that languages like Scheme and Smalltalk offered decades ago.