...but yes; thats the main complaint of any substance.
IMO it deserves bad press for favouring development speed over sensible defaults and safety. Frameworks should not be allowing SQL injection in 2014.
It took me a long time to realize that Rails' greatness isn't due to magical omakase magic - it's the community DHH (and the core team) have built over the years, and the strong product focus they've applied. Really impressive. Did Torvalds work like this? Has anyone has studied or written about organizational behavior in the open-source community?
Support for real foreign keys!
addforeignkey/removeforeignkey are now
available in migrations.
Rails is 10 years old and it has definitely changed the web development. But the unnecessary controversy always seem the same of its first year.
While in the last 10 years, many people talking Rails does not scale and ruby is slow, for many companies rails was and is a great "tool" to delivery great web apps.
Thanks Rails
I wish I could write a long post describing each of the WHY's, but I'll be more succinct, this time:
1)If you can throw money at something at something and scale, then you're as good as gold. Rails allows you to do this. Oh, and supportive statements from Pinterest guys on the same topic - [2].
2) The speed of a language has nothing to do with the success of your business. NOTHING. You can go with the world's slowest language and still be successful. Best example of this is Basecamp itself.
As a matter of fact, even many of the popular sites (heck, even popular porn sites) still run on PHP (PHP was one of the slowest from the frameworks speed comparison conducted by Techempower - [3]).
3) The actual thing you want to be able to do is quickly iterate on your product and constantly have it evolve. This is only possible if you have a complete framework that doesn't force you to re-invent the wheel. For example, when I wrote a framework by myself in GoLang, Scala, I found myself focusing too much on basic stuff like authentication, instead of focusing on the features that are needed for the actual product.
4) (P.S this is my personal opinion) I've tried all major frameworks out there and I've come back to Rails again. Why? Because its philosophy resonates with me (yes, now it does). For me, the three most important elements for a successful product are - Speed, Reliability, Consistency. Rails provides me with all these three. (And please try Puma, it's pretty impressive!).
As for me, the ability to seamlessly integrate SASS, Compass and HAML (which help me divide my product development time multiple folds) makes Rails a clear winner for me. And now Active Job, Deliver Later, Adequate Record, Web Console now make Rails much more complete than ever. (Thank you DHH!)
In the last 6 months, I've written 4 complete products for 4 different people (one of them, being mine) that is well tested and works perfectly as intended. Compare this to something like last year where I spent 2-3 months writing just a single software product (for myself) while I was trying to use GoLang (<- or insert another faster language here) (because I also had to take care of all the other things like Authentication, etc). The point is, ultimately you want to run a successful business. And if you're worried if the slowness of your language will hinder it's growth, then nope. That will not happen. I hope this helps someone.
Cheers.
[1] https://news.ycombinator.com/threads?id=neya&next=6993616
[2] http://highscalability.com/blog/2013/4/15/scaling-pinterest-...
[3] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
Rails versions come out quickly, and old versions stop being supported. And it's become a non-trivial part of my time running the treadmill of keeping all my Rails apps up to date, along with compatible dependencies.
I realize this kind of goes with the program. Rails all-volunteer development manages to produce a reasonably powerful and non-buggy product that for the most part is constantly getting better; the cost of this is quick evolution and a maintenance burden for users.
I don't think I'd like the tradeoff better choosing a less mature/powerful/robust framework, but it is increasingly frustrating.
(The fact that some of the things Rails adds seem unfortunate to me (turbolinks, spring), can add to my frustration too).
(The fact that some of the things Rails adds seem
unfortunate to me (turbolinks, spring), can add to my
frustration too).
The way I see it is that Rails is usually the wrong choice for a one-off project that a client expects you to deliver and be able to run indefinitely with no maintenance, but it's a great choice for a prototype or something that will see continual maintenance and enhancement.
My biggest frustration is just the general slowness of Ruby once you get to a non-trivial app size.
1) Except when you don't have the money. Not everyone trying to build a business goes the funded startup route...
2) Except when it does. There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.
3) Yes, you want to quickly iterate. Sometimes this means using readily implemented libraries for the non-core parts of your businesses. Sometimes it means avoiding readily implemented libraries that do not fit your requirements and/or overcomplicate what you are trying to do. Sometimes it means avoiding the cognitive overhead of all that cruft a framework has and you don't need. Sometimes it means using a typed language and letting a compiler do the most basic testing for you...
4) To me, this is a classical exploration/exploitation tradeoff. You will be less productive using anything new. New language, new framework, new ideas drag your productivity right now. But they may increase it in the long term, even if you end up going back to whatever you were using before. Find some budget to explore and make the most out of what you learned, but don't overspend on it.
We fool ourselves into thinking we NEED a faster language, and Hindley-Milner type checking, and everything else under the sun.
It's actually really hard to discover, whether you're fooling yourself or not here.
We're building our startup on Ruby/Rails with a clojure component for the speed sensitive stuff (which is actually a CPU bound number crunching affair). So far we're been very happy with the tradeoff. We tried building stuff in node, but the ecosystem is just so damn immature.
One of the nicest things about the Ruby community, that I haven't seen in any other language, is the cultural emphasis on good documentation. Java libs have very complete docs, that take forever and a day to read when you just want to use one damn feature, node.js projects have very pragmatic, but very incomplete docs, (same with clojure), and really, that's the case with most languages. Ruby on the other hand, seems to have instilled in its community that docs count, and its wonderful.
Rails testing and tooling is just ahead of the pack, and in the specific case of node, dealing with the irritation of async (inscrutable stacktraces, even when 'long' stacktraces are enabled, inconsistent uses of promises across libs, etc.), is a huge drag on productivity. If I needed a small highly concurrent component I'd consider it, but for general business logic Rails just kills it.
True. But even in those cases, there are likely parts of the system where speed of execution is less important than speed of iteration. So you could (if it made sense for you) use a Ruby app for the user-facing app, backed by a service written in something else.
Point being, just because you need a critical processing bit to be written in screaming-fast C doesn't mean you need to write your own HTTP router in C.
That said, one impetus of our TechEmpower framework benchmarks project was to encourage people to diversify their experience and consider performance as one metric in evaluating the broad spectrum of options. I personally feel that doing so is valuable for a variety of reasons, several of which others in this thread have pointed out.
We refer to a second dimension of "developer efficiency" that we can't measure as objectively as performance. We've had scores of conversations about proxies for developer efficiency, but haven't moved forward in earnest on any yet. That said, my strong belief is that developer efficiency is not inversely proportional to performance any more. Perhaps it was at some point in the past, but I don't feel that's the case now. I personally am just as productive, and in some cases moreso, in a modern language and framework, as I am in legacy frameworks and languages.
If it were possible to accurately and impartially measure developer efficiency and then scatter-plot developer efficiency and performance with a slope line, then yes, there may be a declining efficiency slope as performance increases. But I suspect there would be data points representing both high-efficiency + high-performance and low-efficiency + low-performance options.
It's important, but difficult, to isolate learning curve from long-term developer efficiency. But Neya is a useful counter-point to my argument, and if I might put words in his mouth, he is saying: don't trivialize the lost productivity due to the learning curve; it can be significant.
Plus, SASS/Compass/HAML integration isn't strictly part of a framework, it's the build pipeline.
* https://sourcegraph.com/blog/google-io-2014-building-sourceg...
* https://github.com/drone/drone/
* https://github.com/jordan-wright/gophish
All are reasonably sized; Sourcegraph and Drone especially so.
This also helps you "fail fast". If you have a 1-year runway, it's much better to be able to build 3-4 apps for market validation than build one performant one that nobody wants.
If one succeeds and performance is a problem, you now have good reason to optimize, possibly even to switch languages.
The fact that an example of something exists doesn't validate that something. "Shooting people has nothing to do with whether they die or not. I once shot a guy and he lived."
A little related: http://pablocantero.com/blog/2014/04/20/i-coded-a-backbone-a...
It would be nice to have a "API only" flag option when generating a new rails project. Something like: `rails new myapp -api`. This could keep Rails going for another 10 years.
I'm looking into using Napa, a Grape based API framework, for the purpose of Ruby server-side API apps: https://github.com/bellycard/napa
(Napa is to Grape as Padrino is to Sinatra)
Related reading: http://www.divshot.com/blog/opinion/every-web-app-is-two-app...
This was rejected by core and turned into http://github.com/rails-api/ , which has had some maintenance issues, but is getting back on track.
(see https://groups.google.com/d/msg/rails-api-core/8zu1xjIOTAM/1... . This is about AMS, but that's only because updating rails-api itself should be easy, and I'm going to check it out as well)
See the original discussion here: https://github.com/rails/activejob/issues/25
The discussion was then continued here: https://github.com/rails/rails/pull/16485#discussion-diff-16..., which is where the `ActiveJob::DeserializationError` comes from.
It's not full-record-serialization, and it can't bring back deleted records for you.
(See https://github.com/rails/rails/tree/master/activejob#globali... for an example.)
See the example here: https://github.com/rails/rails/tree/master/activejob#globali...
See the example here: https://github.com/rails/rails/tree/master/activejob#globali...
As someone coming from Django, I hate that I have to explicitly define db related validations and catch exceptions thrown by postgres instead of it just being handled by AR with the DB adapter based on the database constraints.
I love how Django handles that and I hope this finds its way into Rails one day.
It seems to me because it is such a mature framework there are a lot of Rails-specific techniques and components to learn, this seems quite daunting to me, am I correct?
http://news.railstutorial.org/
The upcoming third edition, which I hope to start publishing soon in draft form, is by far the most newbie-friendly edition yet. Indeed, it threads a rare needle: it's both easier and it covers more advanced material than previous editions. (This includes a rewritten chapter on login & authentication, an all-new section on image upload, and an all-new chapter on account activation and password resets.)
I'm also not sure about Railscasts for a beginner, the most suitable ones for a beginner may be pretty out of date now although there are probably a lot of useful ones still there.
Edit: I created it, so I'm biased
To me, the possibility to iterate fast has a much higher priority than thinking about scaling if i have a few or not that many customers.
Thinking about performance problems when you start your first project/startup is like thinking about what to buy IF you win the lottery.
WOW
The PostgreSQL adapter now supports the JSONB datatype in PostgreSQL 9.4+.
I've been interested in real ActiveRecord support for Postgres hstore, in a way that can do partial updates -- if only one key/value has changed, on save an update would be sent to postgres for only that key/value. This matters for concurrency issues where multiple clients may be accessing postgres and modifying the same values.
Does anyone know if anyone has been working on that at all?
What is AdequateRecord Pro™?
AdequateRecord Pro™ is a fork of ActiveRecord with some
performance enhancements. In this post, I want to talk about
how we achieved high performance in this branch. I hope you
find these speed improvements to be “adequate”.
Group discounts for AdequateRecord Pro™ are available
depending on the number of seats you wish to purchase.
-- http://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.htmlIt boils down to: 1. It's a joke. 2. Enough with hyperbole.
He could have called it TurboRecord, but everything has to be "X on STEROIDS!!!!" these days, so "AdequateRecord" instead.
I too am curious how noticeable an improvement this will be in most apps. Is it a micro-optimization that won't be noticed much, or is it actually going to make a difference for real apps?