Rails Has Turned into Java
discursive.com
discursive.com
"One of the basic tenets of the Python language has been that code should be simple and clear to express and to read, and Ruby has followed this idea, although not as far as Python has because of the inherited Perlisms. But for someone who has invested Herculean effort to use EJBs just to baby-sit a database, Rails must seem like the essence of simplicity. The understandable reaction for such a person is that everything they did in Java was a waste of time, and that Ruby is the one true path."
Rails might have deteriorated in ease of use, but I cannot imagine it being worse than Java EE was in 2004. Modern Java EE is a world of pain, even simple apps are difficult to build. The entire front end stack is antisocial, difficult to extend and anachronistic.
I don't think anyone working with a modern java web stack could read this post about rails 'being like java' without a dark chuckle.
Better yet, what framework do you believe offers all of these things and does a significantly better job at decoupling than rails?
(I'm not being critical; I'm really just curious and would like to learn about different frameworks).
I don't think the thing that will be to Rails as Rails was to Java EE exists yet though. The competition has merely caught up, perhaps a little ahead on some fronts and a little behind on others. But there is nothing that is clearly much much better. Things like Meteor and Opa are a step in the right direction, but they don't go far enough (yet).
Does anybody remember this video: https://www.youtube.com/watch?v=Gzj723LkRJY
This is not the original Rails video, it's the second one I think, but they're fairly similar (couldn't find the original). Back then when I saw the first Rails video I remember finding it amazing. Now it's just boring.
I think rails is better than the competition if my goal is to make fairly standard websites. It would be a rare exception where I think something else is more suitable.
The thing is these frameworks have caught up so much on the expressiveness front that their other advantages can easily start to outweigh the small advantage that Rails has there. But if you are building a low traffic CRUD site (like most sites), then yeah use Rails. If you are building say a chat application, I wouldn't use Rails.
"If you have high traffic it might make financial sense to forgo some productivity and choose a framework that can run on lower amounts of hardware"
I've worked on numerous sites that are in the top 1000 traffic wise according to alexa. I never once felt that it was worth moving them off of rails/ruby. You are probably talking about the top 0.01% of sites or even lower than that.
No, certainly not! I think Rails is fine for 99% of web sites, and probably the framework that has the highest percentage of sites where it would be my top choice. But Play is also fine for lets say 98% of web sites. Rails even works fine for things like chat applications, but there it would not be my top choice (at least not for the component that serves the messages). That's all I'm saying. Rails is my favorite framework, I just don't think that it is better than everything else in every respect.
You are probably looking at this from a different perspective. Of course it's not worth moving an existing site off Rails if it is already done, or when you'd have to learn a completely new language and framework to do it. But if you are at the start of a project, and you already know e.g. Scala and Play, the situation may be different.
But, this isn't Sinatra vs EE6, its Rails vs EE6, so its not a proper comparison.
To compare with Rails you've got to look at other parts of EE6: JSF + CDI + JPA, which is an awful mess. JSF by itself is enough to kill its usability for many modern applications, the amount of state JSF carries around is ridiculous.
In my opinion if I need an entire separate framework (or container) to manage it, I think its broken. I've switched to Ebean for Java ORM and am vastly happier now.
JPA also gets the award for the worst programmatic query building API I've ever seen. As a result it seems like the majority of people just use JPQL strings which is really annoying as its also SQL but not quite SQL.
By Rails 2, they were already saying you shouldn't be using scaffolding. I had sort of realized that scaffolding "wouldn't scale," to misuse the expression; by your second or third app you usually didn't bother with it, instead generating a migration and a model and doing the rest by hand.
I wasn't using Java prior to Rails, but I am using Java now and I would say the essentially disparity between the two at the outset was simply maintenance. Rails didn't have a past to worry about back then. My impression is that it still does a lousy job of handling upgrades—though at least with bundler et. al. they have finally achieved a semblance of stability. I suppose I should be able to check out code written 9 months ago and arrive at a working Rails app. There was a time during Rails 1 and 2 when you experienced real fear that running "gem install" might hose something, or that on a new machine the gems you needed might not even be "out there" on the internet to be installed. Java still goes further on these fronts, and probably always will, since "corporate" technologies will always be about retaining as much of the investment as possible.
Frameworks upon frameworks is a recipe for complexity, potential performance problems, bottlenecks, and environmental/context-specific issues regardless of the language that you're using.
Will there ever be a language or simple framework that is popular, solves all problems, and doesn't get more complex as its ecosystem matures? I won't bet on it, but if you figure it out, someone will still eventually compare you to a no-longer-hipster-cool framework as an insult.
I know this makes me sound old. I own that.
And, yes, I admit it, I'm a jerk.
The fact is: Java works, and it works well. Ruby/Rails is getting there, as we see from larger and larger code bases being build on Ruby/Rail and needing more and more of the hated 'Java' features - because they work.
Any language can be used for a small project and work very well - precious few can still continue to work well at scale.
I've found a lot of the HN crowd to be biased in this area. I believe that comes from most of HN working in startups which means less legacy code, smaller code bases, and more focused products with less management bureaucracy and changes. A sizable part of HN is also younger and hasn't yet worked in an environment of sufficient scale to require Java's(c++, advanced RoR, etc) features.
I could be way off here - but if you're knocking this kind of complexity and haven't worked on a massive project - it might simply be your frame of reference and you should stop knocking it.
If you're Twitter or Facebook, don’t use Rails out of the box. For the rest of us who want to work on small applications, Rails is still beautiful. And when I say small, I mean applications around the complexity of a Basecamp or Github.
Sure. But how well does it work? I think it's obvious right now that the JVM is a fantastic piece of engineering, and java took us far, but that it's aging and inflexible.
Here's my problem with java explained succinctly in anther thread:
The reason I agree with you is that last year while on a vacation without a computer I spent some time thinking about languages and made a guestimate that if I had stuck with Java and never spent any time learning new languages, then my productivity would have been a bit higher.
However, and for me this is a large issue: I really enjoy learning new languages, and twisting around how I think about programming.
I mostly retired in January except for helping some customers in emergencies, and for my own retirement projects I use Clojure exclusively. In retirement, I am damn glad I am not doing my passion projects in Java :-)
http://harmful.cat-v.org/software/ruby/
But there was a stretch from around 2005 to maybe 2008 where Rails seemed to defy criticism. It grew and grew, despite the criticism. I tried it for a project in 2006 and I became a fan. The easy use of 3rd party code, via gems, was much easier than anything I had known in Java or PHP.
I do not know a way to say when some of the criticism began to stick, but clearly things have changed. I have my own personal experience: once a fan of Ruby and now a fan of Clojure. And others have moved on -- there was recently the conversation about multi-threaded Ruby apps, and it seemed to me all the smart people agreed that jRuby is the future of Ruby: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto...
If I had to pick one moment when some of the criticism against Rails began to take hold, even among those who had once favored Rails, it was Zed Shaw's insane rant:
http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
Even though the tone is insane, he made some points that stuck in people's heads, including mine. This was important to note:
"I believe, if I could point at one thing it’s the following statement on 2007-01-20 to me by David H. creator of Rails:
(15:11:12) DHH: before fastthread we had ~400 restarts/day
(15:11:22) DHH: now we have perhaps 10
(15:11:29) Zed S.: oh nice
(15:11:33) Zed S.: and that's still fastcgi right?
Notice how it took me a few seconds to reply. This one single statement basically means that we all got duped. The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average."
And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like "lein uberjar".
We deployed a new server last night.
`cap staging deploy:setup` `cap staging deploy` `cap staging deploy:migrate`
You do have to know how to setup Unicorn but…
Deploying an application can be done with 1-3 commands in any language, since it has little to do with the language itself. All you need is a build or deployment script, which can be written in Bash or whatever.
If we're talking about shared hosting, that's a whole different ball game.
That's simply not true and not fair. Rails of v1-v2 era were much worse than what we have now. Tooling improved immensely since the rant (bundler, rvm) and the most popular ruby implementation itself improved. Granted, it's somewhat harder to start rails today than it was four years before, still we are much better off.
I think the biggest thing that made Rails fall from grace (to whatever degree it has) was the way it ground to a halt for what seemed like ages while they worked on Rails 3, and then when 3.0 came out, a lot of people found it unimpressive on its own merits, and even more so when viewed in light of how long it took. (This is largely because a big part of the Rails 3 work was refactoring and trying to make it less monolithic, which are good things, but the kind of good things that get you yelled at by people who don't care about them.)
Admittedly, Rails had a major role in Ruby's ascension into the programming glory; however, in the course of this, it overshadowed the language itself. It created a bubble within the community.
But the real tragedy is that by virtue of Rails being most visible and vocal, the whole Ruby community is appraised and influenced by their actions and rhetoric.
> And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like "lein uberjar".
Then don't pick Unicorn. Yes, Unicorn is a fantastic app server, but it requires that you know the app server very well, and as with all stand-alone app servers, the configuration is more complex.
Instead, pick something like Passenger. Passenger runs as an Apache module and is just as easy to get running as PHP.
That's not bad, as Ruby is a very powerful language.
I don't use Refinery, Devise, OmniAuth, Unicorn, Rack Rewrite, Fog, AMQP, or Heroku.
I use Passenger with Apache or Nginx, self-host, and write my own core functionality like authentication.
Rails is still great at having an idea and throwing together a proof of concept in one day; running "rails s" still works out of the box. It still allows you to defer the hard choices, until you actually have to make them. If you've cornered yourself by making your stack too complex too early, that's your own damn fault—in Java you have to make those architecture choices day 1.
Dynamic typing: if you treat Rails like Java, it acts like Java.
I agree with you that Rails still excels at allowing you to slap together a quick prototype, but I think that the world has caught up with Rails (and possibly bested it at this point).
If you think you're saving yourself from reinventing wheels by adding Yet Another Gem into your gemfile, then you'll quickly find yourself constrained by the code of other people instead of your own code and mental model.
Your app becomes a mat woven of interdependent Things That Almost Do What You Want and you'll spend more time wrestling with other people's code than the time it would've cost you to write and maintain exactly what you needed in the first place and no more.
It's sort of like that time you thought Devise was going to save you all this trouble but soon realized you merely moved the battlefront from (A) a diff'able domain that you control to (B) Google SERPs, Stack Overflow answers, and a Github wiki page of customization boilerplate and copy-and-paste'able incantations that sorta do what you want.
>in Java you have to make those architecture choices day 1.
That's just not true. Very easy and advantageous to start out with say a simple container-less app with in-memory/flat file persistence and build up as you need. It's no different in Java and much more the norm in other JVM languages like Scala/Clojure.
Perhaps the Java bit isn't true... or isn't true anymore; I haven't done much serious development in Java since I started doing Rails consulting in college. I remember it being XML hell where you needed to plan ahead a lot more in terms of choices, but that said I've probably become a much better developer too.
You don't need to use any of these. I once tried to use Devise for a project. I fiddled with it in an attempt to make it work exactly the way I wanted, but eventually I gave up and just rolled my own authentication. It's not hard at all to do in Rails, and you end up with much simpler code. I also tried New Relic, but I didn't see much point to it (maybe it's more useful for apps with a ton of traffic) and they sent me spam until I asked them to stop several times.
New Relic is awesome, but expensive and they do have an aggressive marketing automation thing going on with the emails and such. But, you can't blame them for that, they have to pay the bills and more power to them for that.
Omniauth looks like something I would use, though.
As for New Relic, I certainly can blame them for spamming. I realize that everybody's gotta eat, but there is no excuse for them to send me "I wanted to connect regarding your interest in the New Relic trial. So far I have not been able to successfully reach you." after I already sent them two emails telling them to stop emailing me. Annoying anyone who hands over their email doesn't strike me as a particularly ethical business strategy.
[1] http://www.farbeyondprogramming.com/2011/05/rails-user-authe...
If you Frankenstein your app together at every chance you're failing to manage complexity because you end up dealing with a dozen APIs (or dozens!) all designed in different styles by different developers. At this point you not only need to know Ruby and Rails but also the API of every framework you have added.
I'm not saying don't use gems but eventually if you don't write any code yourself you're going to have a complex mess you don't understand. And that's not Rails's fault.
It takes just about the same LoC now to do in Spring what I'm doing in Java. The difference is that the performance in Java is much higher.
Let's see an actual comparison with some numbers:
* Lines of code, and number of tasks necessary to get a development environment set up.
* Memory used with one client accessing the system, and with, say, 10 clients accessing it.
* Some performance benchmarks.
I keep my ear to the ground, and have used enough languages in my time that jumping to a new one isn't that big a deal, but I'm pretty happy with Rails and use it by default these days. It's a great way of getting something up and running quickly, while maintaining some order and sense of purpose to the code. It's what I'd use unless there are very clear reasons not to, such as huge scale requirements from the get-go, heavy involvement with web sockets or something like that where thinking a bit before coding is in order.
I'm obviously biased, but I don't think any other framework can do this?
For me, I haven't yet found anything that matches the ability of Rails to quickly go from just an idea into something that you can start pitching to customers.
While Rails and the entire community is dizzyingly large, with rapid innovation, new libraries, and a new set of best practices seemingly every few months, this ability to quickly create stuff differentiates it from Java completely.
But well, it's a fashion thing. People need new things, people need to kill the father, people need new chapels. Nevermind that what we have right now does the job perfectly and is lots of fun, we need something NEW.
One of the developers came to me just last week and showed me a POC in Java that was cleanly assembled, easy to understand, and lacked all the enterprisey stuff that scared me away from Java years ago. That's why I wrote the article.
I'm not burning the chapel to build a new one. I'm setting sail for the fatherland in search of Silk and Spices. (I didn't mean to make sense with that ending, but you read it, didn't you?)
I am not an entrepreneur so take this is a shovelful of salt, but I wouldn't venture into creating a business on a technology that I have to learn along the way.
Also, I am now confused that Rails is turning into Java, yet you recently saw a beautiful piece of Java. Rails is just like Java and its "darker" Enterprise Side ™, you get to pick and choose what you want to use, no one is forcing RefineryCMS and Devise and whatnot down your text editor :D
Build it all yourself and it takes forever, but you understand it all.
Buy it from somebody else, and you get it quickly, but you're at their mercy for efficient understandable code.
No language or framework is immune. Enjoy your java.
Really, if you want to make analogies. Rails is essential loose federation covered under Articles of Confederation while Java is to be appreciated as a strong Federal system that allows for states to innovate.
Building your own authorization/authentication and integrating with OAuth is pretty trivial, maybe a few hours if all you need is simply logging people in. Same with a CRUD CMS that'd replace refinery -- you're collecting complexity for a more rich feature set out of the box.
Rack Rewrite isn't really that complex, though Carrierwave+Fog is a complexity layer, if Fog is anything like S3 you could just be posting directly to a REST api(adding complexity in client-side JS -- my favorite kind of complexity.)
Unicorn is slightly more complicated to manage than Passenger, but, apparently you needed to serve fast clients and work on disk a lot? Well, can't be mad about what it buys you.
Honeybadger, Foreman, and New Relic are pretty much DevOps burdens, you'd probably have some form or fashion of this complexity in any web-based app, ever. AMQP is a standard, most people would need a library to interact with it -- this is sort've akin to complaining that you need a library/gem for JSON.
I wasn't even sure you needed heroku as a project dependency -- I though you just needed it locally because it acted like a CLI to their service.
Also, Sinatra is it's own framework, having nothing to do with Rails. And it certainly wouldn't trade out a lot of the dependency complexity you're dealing with.
Really, you traded simplicity for rich features out of the box. Hopefully you took the time to figure out if you actually need those features before integrating them with your app. Also, Refinery's Engine architecture is kind've hair brained.
(P.S. on chrome 24.0.1312.57 and Mountain Lion the dynamic length comment box on this blog is totally fucked.)
No, it hasn't. That's why we're using Rails.
And to be honest, it ain't that bad.
"... Java, have you learned to easy yet?"
And you know what it isn't easy. Having to deal with Ruby's dependency nightmares.
But if you have large apps with multiple Ruby versions then dealing with rvmrc, bundler and gem incompatibilities is a nightmare.
Java's forward compatibility is a lot more robust.
Every time a new developer comes on board they just love to add new technology X and then in the years to come other developers add Y and so on. Of course there are developers who have to manage this.
Why on earth would you do that?
There's really no comparison between using Bundler and mucking around with JAR files or Ant scripts in Java. I've even seen Python codebases with a Java-esque rats nest of dependencies that are just as painful to get setup correctly.
Bundler is way easier. I've never been on a Rails project where it took more than 30 minutes to get the env setup and it's in large part, thanks to Bundler. Admittedly, I haven't touched Java in a few years, but last I checked, Java had nothing like Bundler (which is a shame, because it could really use it).
But there's a very close comparison between Bundler and managing dependencies with Maven or Gradle. And there's a huge difference. Maven Central has never been compromised because they have a secure method for deploying artifacts, RubyGems? You've had a fun month with RubyGems, right?
If not then Ivy is what is used mostly albeit far less elegantly.
That said, you can start with Scala as "better Java" and ramp up to its advanced features. That's how I began. At first you're just replacing for-loops with map/reduce, eventually you'll start passing around implicit variables and using for-comprehensions all over the place.
The world has caught up. That's one of the points I didn't quite make very well. Ugh.
I think Rails still has some advantages, and a head start in both development concepts and supporting libraries and frameworks. My point wasn't that Java and its kin are necessarily incapable of these things, just that Rails has had that mindset from the start, and as such deserves the mindshare that it receives.
Inbound developers will not be able to use either of these things because their skills and expectations have been set by that easy 80%.
1.) Fork a project on Github, say the push notification gem https://github.com/jpoz/APNS
2.) Alter behavior in your branch https://github.com/jamesdaniels/APNS
3.) Optional bit, send a pull-request with your changes
4.) Vendor it or require your fork in the Gemfile: gem 'apns', :git => 'git@github.com:jamesdaniels/APNS.git'
Tada!
gem 'apns', :github => 'jamesdaniels/APNS'
First of all, it's a classic appeal to emotion; it uses hyperbole that is propped up with emotions ("You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation", etc) and not by concrete facts. It cleverly it uses two fictitious quotes to imply it represents real people's complaints, when it's in fact the author himself making up the supposed complaints.
It also works up a strawman argument: That you can criticize Rails on the basis of a collection of frameworks that the OP apparently thinks are required to good apps. The fallacy here is that those frameworks are not needed, and their problems are not Rails' fault. Perhaps there is subculture of engine-loving Rails people out there that promote such frameworks, but I would not listen to them any more than I would listen to PHP devs.
Rails is like any other tool: What you get out of it depends on how you use it. Judicious use of gems, libs, frameworks, databases etc. is just as important as managing your own application complexity. Sorry, but complexity is bad whatever language or framework or whatever you use. If Rails is an easy target it's probably because the apparent ease of implementation makes it tempting to grow your app.
Here's a suggestion, a constructive suggestion: Try not to stuff you app with everything you can possibly think of. Login and user accounts? Belongs in a separate app. Document storage? Separate app. Image upload and scaling? Separate app. Email and SMS notifications? Separate app. Integration with external systems such that you feed data to, or from? Separate app. Computing scores or ranks or other statistics based on data? Separate app. And so on.
Use a service-oriented architecture for everything, and you will reduce the complexity of each component to a bare mimimum. For example, we use Checkpoint [1] to integrate logins (FB, Twitter, Google) through a single system, so that our apps don't need to deal with API keys or OAuth or anything; performing login in an app using Checkpoint is literally a single line of code (a redirect). Instead of using a database, most data fits into Grove [2], a structured, hierarchical, indexed data store on top of a relational database. Instead of reinventing rating and voting systems for every app, we use Kudu [3], and instead of reinventing flagging of spam or illegal content for every app, we use Snitch [4] -- just to mention a few trivial examples. Our stable of mini-apps has much more, a small ecosystem of reusable, composable tools.
By using HTTP as interface glue, we put an artificial limit on the ways that components can entangle themselves; for example, since the API deals entirely with basic JSON objects like arrays, strings and hashes, there are no surprises when you try to access the result of a call, since it will never re-enter its source (unlike, say, ActiveRecord associatons).
[1] https://github.com/bengler/checkpoint
[2] https://github.com/bengler/grove
I think you may be trying to defend something.
Rails has become lighter with 3.x and will become lighter still with 4.x - they're dropping a lot of unnecessary stuff and trying to pare it down to the minimum - an admirable direction and quite the opposite to Java, which makes this article all the more baffling. Of course it's not the perfect framework and there are plenty of options, but the complaints of the article are histrionics.
The laundry list of possible technologies in the article is absurd - RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, Heroku.
You can get started with rails on a cheap VPS and serve your first few hundred thousand users with the following very simple stack: Apache, Ruby, Passenger, Rails. Setup is a few lines in your package manager of choice, writing the app is straightforward and requires none of the software above, maintenance is running aptitude update and bundle update now and then.
Out of the stack above, Devise is quite a nice authentication solution and is the only one I'd recommend, but it's easy to roll your own, as to the rest of his list, if you don't need it, don't bother using it, none of it is required.
Why is the laundry list of technologies absurd, these are the technologies that I run a business on. I think what's absurd is the level of reaction in your comment. Rails people now have this defensive reaction, and I've noticed it in person as well.
It reminds me of the reaction of Java zealots in 2007. It really does. "Oh, really, you couldn't be serious, I mean it's absurd to think that Ruby...." It wasn't absurd to challenge, and neither is this challenge.
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails?
I admit this was sloppy wording, however your article is called 'Rails, You Have Turned into Java.' :) I was comparing Rails 4 (removes lots of features/bloat), with Java Frameworks which do not have a reputation for slimming down... Of course I'm sure there are some minimal Java web frameworks out there too (sorry not familiar with many). Your article is somewhat provocative and not representative of the experience of many with Rails so I wouldn't be surprised if you encounter a defensive reaction to this sort of sentiment. That's to be expected, as was the reaction of those using Java frameworks to DHH's blowhard rhetoric when he started out with Rails.
Why is the laundry list of technologies absurd, these are the technologies that I run a business on.
They're absurd as a criticism of Rails because many of them are completely external to Rails, not required to run a website/app, and some of them are not the right choices IMHO. Rails does not require any of these components to run websites even at scale. Sure some of them might be useful, but none are essential or intrinsic to Rails.
Forgive me but I think the choice of RefineryCMS was a mistake, and if you back out of that mistake, you'd find Rails a lot more forgiving, a lot lighter, and a lot more suited to what you want to do if you're writing a large webapp with lots of components (or several interacting webapps). Problems with engines, subapps, conflicting routes etc are all based on this, and simply don't occur in most Rails apps. I've used it as a CMS for some clients and regret having done so in retrospect - it's not terrible standalone (also not great) but I can see how integrating it with an app would be a nightmare. You don't need to use meta-frameworks built on Rails to build an app, in fact I'd say it's a mistake, use a few discrete gems like devise, and just build what you want.
Here is an example applicaion, let's call it Foo. It's a blogging tool:
* FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI.
* FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest.
* FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users.
We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness.
(Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.)
(And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.)
Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens:
1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is.
2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.)
3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings.
The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff.
This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately.
Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app.
No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications.
I'm not defending anything. If anything I'm attacking? :-)
Every app that I need a user to access requires three requests to IT. Each application must go through a pre-approval process and a separate set of meetings to determine requirements.
That's not to mention that many applications have a view/edit distinction, requiring nearly the same page based on permissions. If you make the choice to split this page into two applications, your UI will have to be written twice rather than an if statement in the view logic. (Oh, and wait until the change request comes in..)
Maybe your system will work in small businesses and direct to customer apps. It's a non-starter in many other places.
Then you have (voluntarily or as a result of placing yourself in such an organization) hobbled yourself and your ability to be an efficient developer.
If your escape route through a beaurocracy — in order to accomplishing your goals — is to compromise in your technical design, then you have my sympathy. That is a situation I could never tolerate personally. (Do you really use Ruby? Sounds like Java would be something an organization of this type would use.)
> That's not to mention that many applications have a view/edit distinction
That requirement is certainly not incompatible with the model.
Maybe it is just laziness but in the last few years I have used almost exclusively much simpler libraries/frameworks like Compojure/Noir and Sinara - and I have lost interest in seriously reading the source to these libraries.
It seems better to have to write a little more code, but layer on top of much small libraries/frameworks.
Lua.
With the LuaVM, you really can fulfill the absolute promise of 'write codebase once, run anywhere', where "anywhere = wherever you've got your LIBS+LuaVM host code running", of course.
You can do it in a compact, highly performant manner. One host binary for each supported platform, much work at the vendor layer to adopt to a common Lua dictionary/table, and the rest is .. as they say .. fat city. All nice app case logic in a comfortable, friendly language.
Java long ago become an unweildy beast replete with inane dependencies and insensitive amounts of hassle to get things in and out, whereas with the Lua stack, it seems, one need only know how to do things at least with a C stack, first, to gain immense benefit.
I daily dream, in my idle moments, of a complete OS based on a selected set of normal/plain-ol' /usr/lib C-libraries, but booting directly to Lua, for GUI and all higher-layer goodness. Such fancies are already tickled in places like LOAD81 and MOAI, and so on, and I think sort of prove the point, a little, that the VM is no longer something a vendor controls, but rather .. the developer.
Ignore this idiot and continue on.
Also, I wrote the original piece.
If you prefer a bit of an easier, less-stressful life, there is hope with many of the Perl, Python and PHP frameworks.
The fact that the Rails team quickly responds to vulnerabilities should be reassuring not a disincentive to use the framework. All software is subject to vulnerabilities - the recent issues with YAML are a class of exploit common across many frameworks in different ecosystems (Django's TastyPie had a similar issue in the past).
Remember - Python for Pros, Ruby to pose.
I'd love to see anyone write something custom based out of Wordpress and not have it automatically break in the next few updates. I believe this is the same case for Rails too. One day you would update your gems only to find out that something on your site (devise? Carrierwave??) would be broken. I guess, the best approach would be to make it modular - You know, write some custom classes and inherit them when you need them, instead of depending what the framework provides you 'out-of-the-box', of course not to the point of making the framework itself redundant.
I was impressed, for real.
http://docs.oracle.com/javase/7/docs/webnotes/install/index....
Mysteries from Oracle.
I was unimpressed. Generics are better than nothing, but still dramatically worse than having a reasonable syntax for anonymous closures. The newer iterator syntax is better than nothing, but still maddeningly lacking in the most basic type inference -- any compiler that can't infer the type of "thing" here is stupid:
ArrayList<MyClass> list = this.buildList();
for (MyClass thing: list){
...
}
I could go on, but my point is that people like me who dislike Java dislike it for fundamental reasons. We're not going to be converted, because the changes we would demand would probably horrify Java's core audience.
Because the 5% of the time matters when you have a language that needs to run on everything from mobile phones to supercomputers.
I personally much prefer being explicit about what I want to happen.
I disagree. It's just as easy to set up a simple web app in Rails now as it was then. Rails may have grown in complexity, but it didn't add complexity to the easy thing.
"Sure, Rails itself is straightforward, but the frameworks you slap on top of it can quickly become burdensome abstractions"
I agree. However, I think it's so much easier to avoid these burdensome abstractions if you choose than it was in Spring when it first hit the scene. If you wanted to do something simple, I think it was far easier to write lower level servlet and jdbc code than to get spring mvc, hibernate, and some sort of build too (probably maven) all working together properly.
There were some good efforts. There seemed to be some enthusiasm about Roo, though I didn't find the code generated by Roo anywhere near as easy to work with as Rails code. I thought Play looked promising, though it wasn't enough to get me back to Java once I'd built some momentum with Rails.
A few people have commented that Spring 3 is excellent. It may very well be, and maybe I'll take a look some time, but to say I'm once bitten twice shy is to greatly undercount the number of times I was bitten.
And, I don't hate Rails at all. Really. I don't.
And I think it's funny that some of the Java-ey concepts that spring made so popular like IoC are beginning to appear in frameworks such as angular.js - this is not a critique, I think IoC is really clever.
As for JSF, I actually like JSF2. It's really not everyone's cup of tea, but it's quite good for those boring LOB apps. Oh and it's view-first! I don't know why there aren't more view-first frameworks. The other ones I know of are Lift, WPF (kinda, never really used intensively), angular.js (has a view-first feel to it).
Anyway, I still like rails, I just think they were a bit premature in judging the java camp...
Once an application, no matter the language, has a significant number of external dependencies deploying it becomes a challenge.
Seems like a good portion of these comments are comparing simple code written in (other-framework/language) with a big messy CMS written as an add-on for Rails. Hardly apples-to-apples comparisons, and only tangentially about Rails to begin with.
In reality most companies are polyglot using different languages, tools and frameworks for different features in their stack.
I am personally tied of unnecessary rants. There is no perfect programming language or framework.
Abandon the notion that there's a "right framework," and just choose one and get hacking.
Rails is for building web apps. 99% of the world's web apps will work fine with Rails, an RDMBS, a web server. That's about all you need. Anything else is probably just developers wanting to play with the latest toys.
So yes, if you try to avoid Rails' conventions, you will have trouble. But it's not Rails' fault.
Longer-term view: Rails mocked the Java web eco-system in the early days because it was 'Enterprise', and Rails was the scrappy upstart with magic commands to scaffold a blog in 5 mins and show screencasts to the world. This sold a lot of books (without it would Pragmatic Programmer have even had a book store?). Slowly, the rot set it, and the once light and nimble Rails become bloated as everyone added their pet features, their design pattersn (even though they would never call them that - that is so Java!), and the too-many-cooks-in-the-code-kitchen sprinkling so much magic and syntactic sugar around the codebase it practically causes diabetes.
Rails solved a problem for the company that wrote it. Since then people have been trying to shoe-horn it work with their business problem, and then found once they now have two problems.
The rest of us moved on.
Just going through all those names makes me tired. Its like framework names are to software as band names are to bands.