Every time I hear someone complain about Rails, I ask myself if this person is really just complaining about how complex web dev is. I've never seen a complaint that passed this smell test.
Yes, Rails abstracts over a veritable shit-ton of complicated domains. The problem is, that complexity isn't going to go away if you decide not to use those abstractions. Every single one of that laundry-list of things that ActiveRecord::Base.create does will have to be implemented again, by you, badly, if you choose to roll your own.
It boggles my mind why developers don't take the web seriously as a domain, like it's not real coding or something. It's the worst instance of bike-shedding I've ever seen.
Rails isn't perfect, by any means. But Rails is not a black box, it's all free software. You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in. It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.
I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application.
Why? Because we owned all the complexity and couldn't support it.
Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.
Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.
At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.
> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.
If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.
Isn't that part of the problem? Webdev is complex. But it feels to me like it's been overcomplicated by a factor of 100. It doesn't have to be.
Asking web dev to be less complex is like asking financial markets to be simpler. Websites are market tools, tools have to retain a competitive edge. You can't afford to ignore market trends. You can't afford to wait until everything is well-defined. You can't let craftsmanship get in the way of shipping.
You can buck the rules yourself and operate on whichever side of the tradeoff you want to operate in, but you can't expect everybody else to follow the same rules you do.
I mean, if you don't like the web, then by all means find a different domain. I personally love it, and find it absolutely fascinating. With the right tools, (Rails) the complexity is manageable.
Which isn't to say that the crap mountain wasn't the best choice. It may very well be the pragmatic choice. The highest net benefit choice. But I don't believe it's intrinsic. I don't believe it has to be this way. Which means it's at least worth considering alternate paths. Even if in the end we picked the same way.
I work in video games. Currently working in VR. Where you absolutely must hit 90fps and never drop a frame. A certain degree of craftsmanship is required to ship. Layers and layers of abstraction on abstraction need not apply.
If you want to produce compelling VR experiences then I'd recommend you download Unity. You should be able to start making real, valid prototypes for different types of VR interactions in under a week.
If you want to graphics then I might recommend you poke at http://humus.name/index.php?page=3D or https://github.com/bkaradzic/bgfx. But graphics isn't my specialty so my thoughts aren't the strongest.
If you want to learn C++ then... that's an interesting question I've not thought of before. Maybe I'd start with "Learn C the Hard Way"? http://c.learncodethehardway.org/book/ I'm not as much of a C fanboy/C++ hater as other game devs. I quite like C++11 lambdas and move semantics. But I hate boost and it's ilk. So starting with C and later adding a dash of C++ seems like a good way to start.
I built my first website in 1994. I know the right tools. Rails is not one of them.
It's been a while since I did GUI programming on the desktop, but I remember it being so complex to build cross-platform applications that rolling your own cross-platform abstraction would be downright ludicrous.
I think the parent commenters point is correct. People treat the web like it should be easy, like it should just be HTML, but its not. It's full of legacy stuff, it requires working on multiple "platforms" (browsers), it runs on all kinds of device sizes and shapes, and the applications being written for it are no longer trivial.
1) Broken platforms. How much "innovation" has occurred in javascript to compensate for a broken execution model? How much caching does your average rails app do because of the poor concurrency the the Ruby platform, requiring external services for persistence across requests?
2) Looking for challenging problems. Design patterns are often a solution to a meta problem. Building a CRUD app, there aren't too many hard domain. However, code maintenance is a hard problem. It involves many people using subjective judgement. So as a somewhat bored developer, I'm going to try to solve the meta problem.
It sort of pains me to see how much engineering effort has gone into essentially making broken systems more performant and maintainable.
To contrast, Elixir runs on Windows. However, it may be hard to get all your projects up and running due to various baked in concerns where they were written to support Unix-like systems only.
If it's important to deploy as a Windows process, then the Windows Linux subsystem is not much better than a VM. Point is, its no substitute for a (better) MSYS2/Cygwin.
Now if you're saying that the webapp itself would be required to be a Windows process, there's really no way around that. But as I implied elsewhere, the biggest stumbler for Rails on Windows has always been the lack of a compiler. Whether you compensate for that by installing a subsystem with that capability or by using a VM with the capability is largely a local problem to the company.
And I have WINE to thank for that layer of compatibility.
http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...
But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.
With a framework, "works for me" is a perfectly valid reason to keep using it and to dismiss criticisms with. That's the whole point, to get you up and running with as little fuss as possible.
I personally hate CSS frameworks, I'd rather retain more control over the markup and selector semantics. That's a choice I make, and I'm aware of the tradeoffs. I would not make the same choice with web dev, because choosing the other side of that tradeoff involves way too much work.
But I'm a working coder, I'm not trying to make my mark on the world. I just want to get shit done and move on. Solnic obviously wants to make something bigger than just a website. He's looking for a bluer ocean to tame. Which is cool, we need all kinds of coders.
What this is really about is that Rails isn't for him. I can accept that. But his rationale is all wrong, it expects Rails to be something it isn't and never could be. Rails is absolutely the best at what it does for the kinds of coders it's intended to do it for. It tracks the state of the art of web development and boils down most of the complexity with user-friendly abstractions.
It's not terribly flexible, but Rails doesn't want to be flexible. It wants to be productive. He wants to go help build the next Rails. Godspeed. I hope he succeeds so that I can go use his framework when it's finally ready in 10 years or so.
Who said that? Who carved that in stone? There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries.
This is just repeating "this is how it always used to be" as an argument.
>It's not terribly flexible, but Rails doesn't want to be flexible.
That's his whole point.
You certainly can use each individual part of Rails without having to bring in the rest of Rails. I bring in ActiveSupport all the time on non-Rails projects. For ORM I prefer Sequel, curious why solnik didn't mention Sequel, the creator of DataMapper even said that Sequel was everything he wanted DataMapper to be and I can't help but think that played a big role in the decision to not continue developing it.
You can use Sequel in Rails, I personally prefer ActiveRecord as I'm not aware of a Form Helper gem that works with Sequel, though to be honest I never really looked. Way more people use AR than Sequel, so Stack Overflow debugging goes much smoother.
I'm not saying he's wrong for leaving the Ruby / Rails ecosystem. I'm saying his stated reasons are inconsistent with his course of action. I'm fine with his real reasons, I just wish he wouldn't frame it as a slight to Rails.
From the article:
> It would be unfair not to mention that Sequel showed up already around the same time and till this day it’s being used way less than ActiveRecord despite being a superior solution.
Just because something was called "Session" (ala Hibernate) instead of "Unit of Work", people would claim it wasn't "pure".
The only real compromises for purity were for performance. You saw the same thing play out with ActiveRelation. Ruby is (or was at least) just too slow for complex patterns unless you wanted to pay a huge performance penalty. The kind of slow that materializing 10,000 models in an O/R Mapper would bring your app to it's knees and use hundreds if not gigabytes of RAM.
And since a large reason for writing DM in the first place was AR's miserable performance at the time, it needed to be fast.
Most of the community wasn't that interested in closing open issues. Not that I blame them. It's not fun. But I was burnt out.
During the end, ActiveRelation started development, making many of the same mistakes early DM did in the quest for purity. By that point I just wasn't feeling it anymore. I'd spent orders of magnitude more effort on writing an O/R Mapper than I'd ever hope to recover, and I felt like some of the ideas were fundamentally flawed. So I moved on.
If I were still doing Ruby, I'd be using Sequel though.
You didn't yet you did? You've said the same thing twice here
The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class.
Turned out this was a bad idea if your primary motivation is performance.
The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick.
The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)).
The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem.
The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.
You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in.
And right here, you also mentioned:
I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.
So which one is correct here?
Oh please stop treating your favorite tech like a religion.
I might even go so far as to say that a lot of where JVM has strength is that contexts are pretty measurable... Spring containers, Akka systems. You instantiate them and hold them basically in the palm of your hand, you understand your scopes. Any technology that allows application scope to slip out of your fingers and intermingle with everything else under the sun is something I'd be wary of.
And as for leaving for what, the author identified both the other Ruby-based stacks and the noon-Ruby languages and frameworks that he sees as valuable. And, no, Java is not on the list.
Your rant looks like a reflexive defense of Rails from someone who hasn't read the source article more than superficially; the article doesn't dismiss the web as a serious domain, it just sees Rails as locked into a dated approach to the domain.
I get it, tight coupling and forced architecture aren't ideal. I accept those limitations so I can get Rails' productivity superpowers. I don't just accept them, I embrace them, I've learned the wonderful joy of having everything you coded 6 months ago just slide right back into your mind because it didn't try to buck the convention. I spent extra time understanding that convention and why it exists when I wrote that code, I think most Rails devs don't do that, and so overcomplicate their applications.
I've been on the other side of that tradeoff, so I can see where you're coming from. There's a lot of appeal in making and using your own abstractions that fit the domain better. But the web is a complicated domain in its own right. The right approach is to use one DSL for the web, and make your own for your domain. DHH was right, Rails is your application. To do otherwise is to over-complicate your architecture.
> locked into a dated approach to the domain.
Ugh, seriously? Is this fashion or engineering?
The writing has been on the wall for Rails for a while now, we're just seeing an increasingly large number of people publicly moving on from it.
> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.
Back when Java was introduced, it was partly taken up because the features it introduced made developers more productive - hardware agnostic code, network programming out of the box...
Nowadays a lot of developers have moved on from Java. Maybe the same thing will happen to Rails...
The abstractions Rails uses are fine for a relatively small app (up to 10 models). Beyond that is where the complexity mushrooms and the framework starts dragging down the project.
Solnik's points about create() are very subtle. Think about coercion, validation, and all the potentially invalid or confusing states an app can end up in.
The approach Rails takes with ActiveRecord is fine for a small project, and often benefits consultants who leverage the boilerplate to show superb progress after one month of development, but it fails in the real world.
To be fair to Rails, most approaches to input validation and the creation of multiple levels of nested objects are implemented poorly. Solnik's point is just that Rails serves up a lot of these flawed approaches into one toolkit, and so the resulting ecosystem is plagued by the sum of all the flaws, and the core team is not really seeing the big picture about how to improve the overall state of the ecosystem (why would they, they are getting paid a lot from the Rails status quo).
DataMapper was superior to ActiveRecord. When Merb got merged into Rails, I was certian DM would be the ORM of choice for new projects, but when it wasn't I personally stopped using Rails on new projects. Sinatra + DataMapper is such a superior approach to full-boat Rails too, fwiw. How many thousands of developer hours are spent upgrading to the latest Rails every couple of years for no benefit. How many useful gems are nearly obsoleted, etc.
Rails has had the worst kind of cargo cult success. Most of the gems are weekend projects that lead to a blog post and a bunch of speaking engagements for the writer, and then get left to wither after the community has naively embraced them. This is not the case for all, but it happens way too often.
There are also many, many subtle bugs that are introduced by ActiveSupport. I've personally wasted at least two weeks of time dealing with them over the past 5 years.
Ruby is a great language, but I'm glad someone as talented as Solnik is branching out.
I've worked on several rails applications with a lot more models than that. Some with over 100 models. ActiveRecord has flaws, but I never felt it was a great impediment to getting things done.
A bigger issue (as you mentioned) is the large number of gems that are abandoned or sporadically maintained. I don't see that as a rails specific issue, but it seems to rear its head most often with gems that interact with rails.
Very experienced developers can create a usable codebase in Rails with over 100 models, but it is highly unlikely to happen if someone in Rails' target audience uses it.
Once you grok pattern matching you'll never want to see another Ruby case statement again. Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions. There's really no such thing as functional Ruby.
You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.
Un uncached Play Framework app will probably outperform a highly tuned Rails app out of the box, even with hundreds of person-hours spent in tuning the Ruby app.
Which leaves you more time to work on actual features.
And then you have Akka. Which is a whole other paradigm to master (but with it's own rewards).
And then you have deployment. Which is a huge breath of fresh air.
Sure, you'll miss some few things in Rails. Like Inflection. Add a dependency for one of the ported versions (like: https://github.com/backchatio/scala-inflector. It's just a single file).
The learning curve isn't the smoothest (though API docs for Java/Scala libs in general and the Play Framework guide is far more complete than anything I ever experienced in Ruby-land). But the rewards.
Come to the dark side. :-)
Then I'd have to learn Scala. I do not want to have to learn an entirely new stack. It took years for me to learn Ruby's eccentricities. Sure it would take me less time to learn Scala, but I already know Ruby. You seem like quite the masochist, spending years in one ecosystem trying to build something, then burning it all to the ground and starting all over. Just looks like so. much. effort.
> you'll never want to see another Ruby case statement again
I never write case statements in Ruby. What I do when I find myself needing a case statement is to go looking for the missing class. I'm missing a domain element and OO programming to me is all about clarifying a domain.
> Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions.
I pipeline all the time in Ruby. A lot of times I'll wrap a data pipeline in a class so I can encapsulate the logic and manage it better. When you wrap a pipeline in a class, you can do things like add immutability to the instance variables. Sure, it's not true functional, but I don't want true functional.
> You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.
Let's take these in turn.
> more maintainable code
I love maintaining my code. I fail to see how learning a new stack could actually improve on this for me.
> lower LoC count
Mostly aids in maintainability. Again not at the top of the list of things to improve.
> easier testing
I've changed my approach to testing over the years. Again, this is not anywhere close to the top of the priority list.
> More mature libraries
Again, this is something I've fixed by changing my approach to the problem. Whenever I introduce a gem, I put an interfacing class between the rest of the app and the gem. That way it's easy to swap out if it becomes a problem.
> And then you have deployment.
Deployment sucks in Ruby, not gonna lie. But again, problems are indicators of overcomplication and I've tuned my workflow to drive more simplicity over time. I know Capistrano very well, seeing it evolve over time has given me a keen eye for how to keep it manageable.
On the whole, I like the idea of functional programming and am not opposed to coding in a functional style once in awhile. HtDP changed the way I thought about programming, though I eventually switched back over to OOP. I strongly disagree that there's any kind of magic to functional. Everything in programming involves tradeoffs, and OOP better fits my mind than functional does. I look at pure functional as math-heavy and harder to grok. I want stateful objects, because humans think in terms of objects and not data pipelines.
> The learning curve isn't the smoothest
That one issue outweighs all the purported benefits of all the others. I would much rather spend my time thinking about domains than learning new tricks.
If you like what you're doing, more power to you. I picked up Ruby because I thought it showed promise as a good scripting language and web development tool (this was pre-Rails) at a time c# didn't really excel at either.
> You seem like quite the masochist
Maybe. DM was created to solve a problem. I didn't burn anything down. I just walked away. The best time to do the right thing is yesterday. The next best time is now.
After 8+ years, I realized I'd spent much of it trying to work around limitations in Ruby. It was just time to open myself up to the idea that there is more to programming than what I knew.
You just answered your own question. You sanitize the string and then you call connection.execute. Not sure I understand your other issue but it doesn't seem too compelling.
> Not sure I understand your other issue but it doesn't seem too compelling.
If you don't understand the other issue, how do you feel qualified to comment on whether it seems compelling?
Use case: I want to pull up a table of aggregated data for my user. The table is built by joining multiple tables together. The user can dynamically select which columns in the table he wants to see.
Model.find_by_sql(query, binds=[])
http://devdocs.io/rails~4.2/activerecord/querying#method-i-f...
Model.connection.select_all(query, name = nil, binds=[])
http://devdocs.io/rails~4.2/activerecord/connectionadapters/...
Oh, and if you're writing an INSERT statement you have to use connection.execute after all. Have fun!
> you'll also end up writing Ruby code to accomplish what the database is already capable of.
This is for the best. Usually, you have only a few database servers, while you have lots and lots of web servers. If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally.
In our environment, the problem is usually the opposite -- it's way too easy in ActiveRecord to ask the database to do computation like sorting for you. Also, it can be hard to predict what impact an additional clause will have on the server's use of indexes. We try to get engineers new to Rails to write the simplest, most performant queries and then use ruby to do any soft of complicated transformation or computation.
Actually the right tool for this is plain old SQL. Even with nice formatting this is probably a 10-liner at most.
If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally
It's only computationally intensive if you're doing it wrong.
When I post job adverts, a large portion of applicants balk at the SQL questions: "just use PDO, or ActiveRecord, or ADO, or SQLAlchemy". Which is fine, if they can explain the difference between inner, outer, left/right joins - and they can't. SQL will be the next COBOL at this rate, or at least I hope so for selfish and monetary reasons.
To make it a bit more clear, it's exactly the same separation of concerns that you want when you write a view for the UI. The controller takes one or more model objects and uses the view to generate an abstraction for the UI. When we save and fetch information from the DB (or send data out on the wire as JSON, for example) we want the exact same thing.
BTW, be very careful about doing all your computation on the ruby/rails side. It's a good idea from a certain perspective, but you are building a very nice bottleneck there if you have anything of real complexity. For example if you have a report that needs to sort through millions of records, you are going to be hanging your server for a loooong time. As you say, in those kinds of situations, you really want to query a service that has the ability to scale the requests more reasonably. Rails is incredibly poor at this kind of thing.
My own personal opinion is that there is very little that rails gives me that is worth the pain that Rails imposes. I'm much better off building something with Sinatra. What Rails does do very well (which the author also acknowledges) is reducing the number of things you need to know to get up and running quickly. But if you are going to pay the kind of salary I demand, then you will expect me to beyond that level ;-)
"Rails" is an appropriate term for the framework; step too far off of it, and you find you're on rocky terrain.
This solves the problem if you know ahead of time the format of the query, e.g. The example you gave would probably fit well. But if you're offering some kind of query building interface, well god help you.
No one has told me I'm wrong yet with this approach and it's been working great for years.
A major problem with rails is it tries to "simplify" the inherent complexity of web development by using abstractions & mappings that ultimately increase incidental complexity in the entire stack.
I call this "magic" and I dislike it very much. I'm a very explicit person. I like the ability to jump into any project, regardless of language, and be able to figure out how it works. This is typically possible with Python, Node and PHP with most web frameworks. Ruby with Rails? Not at all and for precisely this reason.
I'm fine with abstracting things but only to a degree. If you're doing a laundry list of complex things with a single statement, and I'm referring to web server specific stuff not ASM instructions, then your framework is going to require more ramp-up time than any other explicit one.
I think the mention in the article of the User.Create(params[:name]) one liner is really instructive. Creating a user is one of the most important things you're going to do in an application! The business logic rules are incredibly important, the security implications are huge, everything. Trying to make it "easy" is ridiculous, because as a developer, you should be thinking about these things. That's the kind of thing that should contain absolutely zero magic, the logic should be upfront and visible.
I've worked as a web dev, and I've also worked outside of web development, and the number one thing that drove me insane doing web development was never knowing if any one line of code was doing some severe amount of impossible-to-debug magic. I'd rather just write javascript against the browser APIs with a lightweight http server.
As far as I can tell, the vast majority of frameworks aren't really about providing functionality, they're thought experiments in how to write software. That's fine, but they should bill it as such. I'm not going to say web development is easy, there are parts that are legitimately difficult on their own accord, but I think the web development community has made things massively harder on themselves by pretending all these abstractions are actually simplifying the task they've set out to do.
>things. That's the kind of thing that should contain
>absolutely zero magic, the logic should be upfront and visible
No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?
Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?
Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.
"Magic" is good for beginners, because there's just too much they don't know.
Not thinking about all these things because the community of thousands should have done it better I did, is just lazy.
This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.
Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems?
As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.
It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy".
https://www.infoq.com/presentations/Simple-Made-Easy
If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software.
Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.
I was referring to absolute beginners with little prior background. To them, technical documentation is a bunch of gobbly gook. For these people it's usually better to be somewhat opinionated and just tell them "there are other ways, but this is the tried and tested way and it works". A nice side effect is that they don't suffer analysis paralysis and panic attacks.
They don't know what they don't know, so it's sometimes useful to just tell them "this is the syntax to do X" (aka "magic") and gloss over the finer details. I've found that the time to unveil the magic is when they poke around under the hood, read up, and start asking questions about how things work.
This attitude is really pervasive in web development, and I think it's kind of bizarre. If you're building something as a developer, you need to understand what it's doing, because at some point something will break and you will have to debug it.
When you get to the point you have to debug it, are you going to want to figure out some sort of insane meta-object protocol where you can't figure out where or why a method is dispatched, at what point inputs get santized, etc., or do you want to walk down a simple function chain?
Keep in mind I'm not advocating rolling everything yourself, I'm saying if you use a library it shouldn't be treated as a black box. I'm advocating avoiding abstractions that obscure your ability to understand what's happening (what I call magic). Use a library for user authentication, for sure, but if you can't explain how it works well enough that you could replace it, you shouldn't use it.
Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you.
Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries.
The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database.
Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.
Having been bitten by web applications written in scripting languages (Apache + TCL like AOLServer) with an architecture very similar to Rails, but done in 1999, Rails was never that interesting to me.
I'm glad to hear people say this. I want to be a webdev (second career), but rather than code school I went back for an MSCS, because I really wanted to dive into the nuts and bolts down at the database implementation level.
I've done a fair amount of machine learning, ai, large-scale parallel programming, and algorithm design, and while I'm super-green, it's good to see the top comment is that the web is a serious domain.
I don't understand why web dev is so "scary" or "complex" that it needs 8 abstraction layers on top of it for my own protection. The only time I thought I needed hand-holding was when I didn't understand SQL injection and cross-site forgery/scripting (and once you do understand them, it's not difficult to protect yourself against those either).
If I found HTTP methods and headers, Javascript, CSS, Cookies and the rest of the web stack "scary" and needed hand-holding from Rails in order to get shit done, I'd be really, really worried about my skill set...
The web world is changing quickly and you have to ask yourself if you're a "web developer" or a "rails developer". I think you'd want to be the former.
I've recently had the pleasure of working on a new, medium-sized node/react project. Now I was new to a lot of the technology, but I've learned a few and would think I have some experience.
It probably took me a week to get webpack running the way I wanted. The documentation is an atrocious mix of stuff that is outdated (older than 6 months) and stuff that's too new (webpack 2.0) without any indication as to the validity. There're six different ways to get hot reloading/replacement to work, with similar problems. The configuration's syntax is heavily influenced by brainfuck with a /\w/[{\[]/s thrown in for good measure. As a soothing measure, webpack doesn't complain about anything but parse errors with the configuration. The version I was using came with 12 different options to render source maps, none of which worked in chrome (since fixed).
And that's just the linker. I actually had presets to search for, i. e. ["express.js" from:<date-of-last-stable-release> to:<date-of-following-alpha/beta-release>]. node_modules once managed to consume 4TB of hd space (someone managed to create a circular dependency) and even in regular use gets to the point where I'm looking for the elasticsearch plugin for ls *<x>. If you have checkouts of several versions or projects, each one will have it's own version of left_pad & friends at around 230MB (just checked with a clean install of mxstbr/react-boilerplate) with no way of deduplication.
I enjoy playing with new technology (currently elm & swift) but I know that it's time "joyfully wasted" right now and don't try to justify it. There's no amount of type-safety bugs that could cost as much time as a new framework's kinks.
It's an easy mistake to think that means they're the worst.
Of course we see people complain about these tools, but my impression is that people who end up leaving those communities are rarely because of community issues (more like "I'm going to do some Go instead"-style things)
Surely something is different. It's not like Django is unused...
Also, with regards to Webpack, even though it's complex, it's extremely powerful, more so than anything else I've found. It includes many ways to optimize asset bundles considerably, by splitting them up into different files, removing unused code, and of course all the usual stuff like minimizing and gzipping the assets. In comparison to Rails it also compiles way faster, by only recompiling the code that you changed. It also includes many development tools, like an auto-reloading server and even updates your webpage without a refresh (HMR). All these are things that just aren't possible in Rails without much, much more effort.
Edit: I guess there's a first for everything, but I'm really confused as to why this was downvoted. If something I said is wrong or debatable, I'd be happy to hear it and discuss it.
> I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails.
Those two sentences don't follow logically the way they appear. A project's structure has nothing to do with its functionality, which SPA is. I admit that rails is late to the SPA game, but if the new websockets (ActionCable) and API mode do what the docs say (haven't tried), there's no reason why it wouln't work nicely. For a given rails project, less than 5% of non-template code should change: create an API (one line for most projects) and... well, I can't think of anything else.
The rails view architecture is also almost identical to React: a bunch of nested templates. React best-practice is a bit more insistent on modularity (small & more generic components), but a 1:1 mapping of React and rails templates is possible.
I also know about a couple of projects using React successfully within Rails apps, but I would personally not do that if I were to start a new project today, even though I love Ruby.
Took me a few days to me to get it working and "kind of" understand what it was doing. That really should not be that way.
Webpack is usually the biggest source of bugs and questions on any given React boilerplate. Something won't compile, circular dependencies causing the build to fail the first time, some strange bug in CSS inlining, hot reloading not reloading, etc.
It's very powerful yet very hard.
Webpack, React etc... are not frameworks in the sense that Rails and AngularJs are frameworks, if you started with them and something in them is not like you like, you can use other libraries alongside them easily enough or replace them without huge sunk cost.
This isn't true for Rails (Or Django, or AngularJs) which are huge frameworks that touch every part of your development process.
I wasn't neccessarily defending Rails as being "better than neutral" (although I think it is). I just felt the attitude at HN is negative to a degree that isn't objective any more, and that, to me, seems like it is less informational and more hurtful for a few people I have deep respect for.
You're starting a new project, with new technologies and you tried to use the most complex stack from day 1. It's a classic mistake people make with React projects. You don't need webpack, you don't need hot reloading etc (at least not to start with), you don't need a boilerplate.
Go with browserify at first. It's simple and can be migrated to webpack later. To setup browserify?
browserify in.js -o out.js -t babelify
When you need bundle splitting, async module loading, and all the other stuff you can do with webpack, then you can easily migrate from browserify.
Don't jump in the deep end without knowing how to swim.
Do projects get complicated? Yes, some of then. Mainly because most customers pay for features and not for refactoring or design, which they don't understand (remember, no in house technical staff). Try to sell them a new page with attached the price of a major refactoring... good luck with that. So sometimes features get kludged together because of budget constraints. I have projects with suboptimal UX (understatement) because they rationally decide to make tradeoffs between usability and costs. It's their privilege. I bet this would happen with any language or framework. Your customers could be more long sighted than mines, I hope they are.
So, would I move away from Ruby and from Rails? Yes, when customers won't like starting a project with Rails anymore. This means that other tools don't have to cost them more. Do I care about Rails architectural shortcomings? A little, but I appreciate its shortcuts more. They work well in my projects.
Choosing Rails will definitely lead to problems in the long run, but at least they are well understood problems. You're going to do an in-flight replacement of your 1.0 eventually anyway. You just need one grayhair on the team to steer the younglings away from the worst abuses and you'll have a stable, if clunky, platform to build on. It's the definition of mitigating risk.
Java and C# are of course equally boring, but I think the fact that Rails is culturally open source provides a huge benefit over them.
JavaScript, Go, Haskell, etc are arguably better if you really understand them, but they're research projects. Lots of great pieces of code, but the story of how to use them together is still being written. I would use one of them if my intention was to hire slow and keep my dev team fewer than ~30 people in the long term.
Can't speak about the Haskell community though. To the extent I know the language I probably wouldn't want to use it to create HTML forms, either.
The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand.
Compare to Rails, where you start of with OK infrastructure by default. That's not better, it just means you can hire a random person off the street and they're on the same page as you. If you want to keep a team of 50 JavaScript developers on the same page you need a really strong culture. Or just say "Use Ember and Express, end of story". But at that point you no longer have the "developer freedom" you correctly cite as the core selling point of Node.
And by "on the same page" I mean "we both have a similar understanding of a sensible default way to transport persist text fields from an HTML form". Put 10 JavaScript programmers in a room and you'll get 8 different approaches.
Or any correct way of doing one thing, starting with the language (JavaScript) and moving on from there …
And if you just want something to work quickly, Rails wins. JS encourages developers to spend days and weeks on picking each part of a framework for an MVP that may go nowhere. Rails is no longer the new shiny and it has moved into the 'get shit done' category of developer tools.
And they're the ones who don't write medium posts daily whining about how their frameworks are the worst in the world.
It's boring, it works, it scales.
There's plenty of "drama" in many programming communities, but a lot of it is hidden, because your median Java developer is less likely to be on Twitter, Medium, or even HN.
Dropbox has stated that pretty much their entire backend is written in Go. Go is also (obviously) used in production at Google. Neither Dropbox or Google is screwing around. Once a project is run at Google or Dropbox scale, it is no longer a research project.
Go is very simple (many people say too simple) and writing a web app in it doesn't really require a very good understanding of the language. This is because very few of its more advanced features are really required for writing a normal web app. Because it isn't really a framework, it does require a good understanding of web development.
I think Haskell can be fairly described as a research project and definitely requires a good understanding.
But you do have to know to how to use the standard libraries well to write anything beyond a Hello World web app in Go.
Just because the Go language itself is simple, it does not mean web development is easy in Go. Quite the opposite, you have to write a lot of boilerplate code in Go (even with Go frameworks) to do things that would seem trivial in other frameworks.
Java is culturally open source at this point; nearly every widely-used Java library is open source and there is a huge open source ecosystem around Java (namely everything maintained by the ASF, but there are plenty of other open source projects like Gson, etc.). Bonus points for tying in to any of the bazillion proprietary software systems also built in Java.
The problem with Java is that it's so damn verbose -- it can take forever to build a moderately complex system because you just have to worry about so many things (maven, spring, jetty, etc.) just for a simple web service. This means you're spending time up front solving a lot of technical problems just to get a simple web service up and running.
Rails is great because it implements a set of sensible defaults and lets you worry about product design rather than implementing yet another database backend for a user store. Its event-routing model also makes a lot more sense for the web; in Java everything is kind of a hack to link the web stuff back to the JVM. But yeah, once your project gets complex, it might as well be Java -- complex software is just complex to write. Rails kind of sucks when the "sensible defaults" don't make sense anymore because you need heavy customization. It's a great prototyping platform, and that means a lot -- but it still won't let you escape the problems caused complexity.
Could it work to include a "technical debt" figure in your quotes (where each feature without refactoring increase the debt and the "interests" on each future invoices)? Might be useful to explain them that quick-and-dirty is not always the best solution.
If I may also ask, have you run in to an older rails app when someone wanted some fairly minimal additions? Have you been the "next guy?" or do you avoid those projects? Did you migrate it to a newer rails? rewrite it? Or write old rails code? I've run in to a couple of ancient apps that were running untouched for like 4 years, they want to freshen the application, maybe add some features, you have to sell them a major refactor, or you can't touch it, like they depended on some gems that were orphaned. It's not exclusive to Rails, I've seen this with node too, once the application needs to be living and breathing to stay healthy, once you put it on the shelf, it's dying. An express.js 2 to 4 migration is effectively a rewrite, it's not super terrible but it's a chunk of work that isn't adding their new features.
I've simply never heard a long term success story with rails or node when it comes to maintenance. It's maybe not a technical thing but it seems like it's the culture of both communities. Blue sky and green field code? It's a blast, fixing up or adding to someone else' existing code? I probably wouldn't touch it. Oddly, I don't feel the same way about a lot of Java stacks though.
Basecamp, Shopify, GitHub aren't long term successes? smh...
I don't know whether Rails maintenance issues played a part in either of those things. However I do know that YAGNI and tight coupling are traditionally things than come back to haunt you 5+ years later. Front ends may change in that time but the fundamental logic of applications, especially their data structures tends to evolve much slower. Isolating the two can only be a good thing if you're not building a throwaway project.
No, those customers only know that Rails is mainstream and so it's a safe choice. If I propose Phoenix to them I bet they will look puzzled and ask me about PHP, Python, Node, Rails, maybe even Java. I'll make a test.
I've been the next guy many times. Rails makes that easy because I know where to look. The worst are custom PHP projects because I need to understand the original programmer's way of thinking. It can be a smart architecture (usually it's not) but it's time consuming and inefficient cost-wise.
I migrated every single version of Rails.
Never total rewrites, no need to do that.
I'm maintaining Rails 3, 4 and 5 beta apps right now. The customer with the 3.2 one has very little budget (we atarted and paused the upgrade to 4.2) and it's going to be EOL very soon. We'll see what happens. I was the next guy, that app started in 2011, I got it in 2012.
Orphan and incompatible gems happen. They make upgrades more difficult but I always handled them. With node it's an order of magnitude worse because of the much more rapid pace of change. It's the main reason for I would not recommend using Node.
Java just costs more to the customer. I use it only when I'm the next guy in a Java project. It's always a pain to work with it. It's like those ten lines would be one if this was Rails and I would have delivered two days ago (small new features). I just don't understand why developers want to inflict that environment to themselves.
Because Java is a huge chunk of the job market (at least in the Sacramento area), not because it's a "language of choice" . Actually, the JVM is a nice thing, even if the Java language is primitive and verbose.
Too bad the jFoo alternate language implementations haven't got more traction yet. (jRuby, Jython, Nashorn, et al)
Because it takes so long to start and you feel it whenever you run the tests. It gets a little better if you disable the JIT compiler and so... in dev mode, where developers spend all their life, it's not faster than RMI. Because it used to support only the syntax of older versions of Ruby. Basically devs get all the pain of the JVM and none of the gains. Guess what they want to use? A customer of mine asked me how to migrate from jRuby to MRI because devs where having problems. I explained and suggested they could try using MRI in dev and keep jRuby in production. They're a JVM shop. I'll ask them what they decided to do.
Java 8 is not bad but still trailing Ruby by a long shot in terms of readability. Thinking in Ruby I wanted to implement the Java equivalent of
input.select {|i| validations.include?(i) }.map {|i| "'#{i}'" }.join(",")
I ended up with a small nightmare with streams and collectors. That boilerplate shouldn't belong to this world, probably it's there because of the Java way to static typing.
They use Spring, don't know which versions, but it's got @RequestParam annotations to extract parameters from the request body. I think this is Spring Boot. It looks like Sinatra because of the @RequestMapping. Having @RequestParam in the action arguments looks a little like Phoenix pattern matching but I didn't have time to dig into the web and understand if it can really route requests to different actions according to the RequestParam. Overall is more or less where Ruby frameworks where ten years ago unless it's got pattern matching.
The webapp I had to work on still use ctags, which are a major PIA which slows down work and raises costs.
Queries are written in SQL, which is perfectly OK, and executed on a connection returning a java.sql.ResultSet. Not shiny but everybody can understand that. I googled jOOQ and it looks like ActiveRecord/AREL for Java. Nice but it would have cost me more time for this kind of quick hack.
input.stream().filter(i -> validations.contains(i)).map(i -> "'" + i + "'").collect(Collectors.joining(","))
I don't agree on the sentiment in the article that it's hard to follow what happens in rails/activerecord. It's pretty well documented and all the quirks are thoroughly discussed on stackoverflow. Ruby has excellent tooling and it's easy to find performance bottlenecks.
On the negative side though, I find that I use other languages when I need performance or better concurrency, but that always comes at the price of lengthier development.
That's the only justification anybody ever uses for choosing Rails, so I'd hardly say it's overlooked.
1) Too much complexity is hidden by simple interfaces
Those simple interfaces make programming enjoyable and don't break, so...
2) Your app logic is going to be too tightly coupled to core Rails features like AR, helpers, controllers ("your app is Rails")
Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem?
3) ActiveSupport. "No actual solutions, no solid abstractions, just nasty workarounds"
ActiveSupport has saved me bajillions of hours and never broke anything for clients. I wasn't aware it was such a flawed library, if it is?
Rails is maximized for developer happiness by, among other things, making things simple (yes, which to a large extent means hiding complexity), giving you a bunch of Omikase core features that you can in fact use, and gives you a lot of sugary methods for handling things that are tedious. I understand people wanting to try other things and leave Rails, no problem with that, but his stated reasons reveal a lot more about him than about Rails.
They reveal that he has tried to build sotware that didn't fit the Rails approach. They reveal that he has been frustrated trying to build tools that allow him to stray from the standard Rails approach without abandoning Rails completely. They reveal he's tired of the lack of success on that front and is going to just move on.
Rails has its place. If it's all you know, everything looks like a rails app...
If they don't break for you, then use Rails. I find that they break all the time.
Hint: What does "validates: :unique" actually do?
Of course, you always have to know how the tools you're using actually work, but Rails does have a tendency to make it seem like you don't, and to defaults that make it perhaps too easy to create bugs caused by mistaken intuition.
http://guides.rubyonrails.org/active_record_validations.html...
The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say:
> ...it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on both columns in your database.
But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that.
That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait timeouts, etc. into generic, application-intelligible exception classes. The entire point of ActiveRecord is that your application code should be portable between SQL variants--hell, it shouldn't even have to know what SQL variant it runs on!--but between having to write your own SQL for any use case other than "let's deal with a result set as an array of ActiveRecord objects" and this nonsense, no real-world Rails application achieves this.
In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?".
Honestly, I don't want to come across as too harsh. The sad truth is that nothing is perfect, and if you focus on the imperfections, all software pretty much just sucks. But Rails actually tries to convince you that it doesn't suck, that it abstracts away the complexity for you, and that you don't have to worry about it yourself, leaving you ill-prepared for the reality that it's still there and you do have to worry about it.
Does any web framework manage these? Given two almost identical requests that cause a race condition most frameworks fall down in my experience.
What I would do, given Rails' existing framework of "programmatically discover the table schema and magically generate logic from it", is set it up so that it observes uniqueness constraints and programmatically adds the validation when found. Also, the adapters should interpret server error messages, throw a custom exception class for "uniqueness constraint failed", and ActiveRecord should catch this exception class and turn it into a failed validation when you attempt to save a record.
If that's too much work, just be fucking honest, remove the uniqueness validation (because it's completely useless), and be upfront with us that we have to roll our own solution for it.
It's enjoyable until you want to do something else rather than the default behaviour.
Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem?
Yes, it's terrible architecture. Your business logic should know nothing about what framework it's sitting in or which database it's connected to.
Speak for yourself. The last time I worked on a rails project this was the part I most disliked. It made debugging annoying, I never knew what each line of code was doing in totality and and I had to practically live in the documentation to figure out the side affects of everything I did.
This is versus most other frameworks I've used for web services where most things are explicit enough that, even if you don't know the language well / at all, you can still figure out what most of everything does. Jumping into a rails project without knowing ruby and how rails works? Good luck figuring that out without studying the documentation.
The issue is with culture. There is no problem if rails wants to go one way, and the author wants to go another. The issue at hand is that Rails is stymieing growth, not just in its own ecosystem but in the ruby ecosystem as a whole.
I think this is a very good point, and in contract I can imagine that if Django had total and utter dominance in the python world, python would be in a similar position.
A lot of people would argue that you should structure your application in such a way that as little of the behavior as possible is entangled with the Web framework you choose, making it easier to understand and easier to (for example) develop a different application reusing that code. DHH thinks that's "wankery," apparently, which I have to say strikes me as an odd opinion.
User.create(params[:user])
Now, this line of code is not simple, it’s easy to write it, but the code is extremely complicated under the hood because:
- params must often go through db-specific coercions
- params must be validated
- params might be changed through callbacks, including external systems causing side-effects
- invalid state results in setting error messages, which depends on external system (i.e. I18n)
- valid params must be set as object’s state, potentially setting up associated objects too
- a single object or an entire object graph must be stored in the database
This lacks basic separation of concerns, which is always damaging for any complex project. It increases coupling and makes it harder to change and extend code.
This feels like the core of the argument of the whole post. It does not seem correct. In isolation, the call to User#create seems magical. But there's not enough context here to criticize it. We don't know enough to say whether there's inadequate separation of concerns.
No matter how we handle "users", we are going to need to do all 6 things in the list the author presented. No matter how we structure those 6 things, there is going to be a single entrypoint function that kicks them off --- end users won't be pushing 6 different buttons to drive them. So: what's the better design here?
This is very much not Merb's design. But that doesn't make it an invalid design; it just means that understanding a Rails app might best start with the models, not the controllers.
(There's a lot not to like about Rails! It's been years since I worked in it full time and I don't miss it.)
In 2016, with systems regularly decomposing into services for both perf and code management purposes, I'm trying really hard to find a reason to say this isn't an invalid approach except for what amount to toy problems (the kind where "if you don't know where you're trying to go, any road will get you there"). ActiveRecord being a mudball of "what X is" and "how to get X" is a really, really big problem, and my view of it as an observer--heavy in Ruby, heavy in avoiding Rails at all costs--is that it seems to be sourced from an unwillingness of the Rails community to consider that not everything is Rails. Services become intractable, as I note in my reply to your first post--and I don't even mean "microservice all the things", just the profoundly unsexy and unbloggable "SOA".
Source: "The Rails Doctrine" http://rubyonrails.org/doctrine/
There's enough context for me to start putting up the horns and cheering, because AR is one of the more persistent boils on my ass when I'm building things in Ruby (because I use Ruby for Ruby, rather than Rails, my frontends are all JavaScript and my services are all Grape). His last point is sufficient to me to demonstrate inadequate separation of concerns--the better design is the one that doesn't require an active database connection to know what fields the object has in it. Answering "how do I build an SOA without every service having a line to every database?" inevitably becomes "don't use ActiveRecord, ever".
What solnic has done with Virtus (which I use in all my projects, it's awesome, he's one of my favorite current Ruby people because of it and I'm sad that he may be leaving) is to return to the novel notion that an object knows what's in it. Dumb data objects are in almost every case a better long-term strategy, and solnic's frustration, if not expressed perfectly, is one that inevitably burns even Rails projects that grow to scale. And while this is a single example of Rails's monolithic nature choking out a lot of the Ruby ecosystem, it's not the only one (see his comments on ActiveSupport).
They are both critcisms of ActiveRecord, for sure, but quite a bit different in content. One (AR objects not knowing their own properties) feels, at least to me, like an unfortunate early design decision, while the other (encapsulating everything involved with saving a model in a single statement, "magic avoidance" be damned) is very much in line with the core philosophy of ActiveRecord and Rails.
Hence "the last point" (though you might have caught me mid-edit). I view these as functionally the same problem: not only are you instantiating the object, but it must immediately go to live in the database or it's useless.
But you're right in that it is a philosophical problem. Rails is wrong. =)
Also, in Django models are explicitly defined. There's no ActiveRecord magic of reading the database to define the model. Which is not to say that AR's approach is bad or wrong, but it is pretty significantly different from Django.
I feel like people really forget what it's like to be a beginner when they say "read the source".
Further smaller changes have been made since then for the same purpose: explicit over implicit, code or configuration over convention is part of Django's philosophy.
IMO that also makes it easier to graduate from a beginning to an intermediate level use of the framework because while there are sane defaults in many places, in others you're required to define your specific implementation explicitly from the start. It's a tiny bit more code up front, but all the details are exposed and it's obvious how to override default behavior. And at the same time the framework supports keeping your code reasonably DRY and takes care of much of the tedious, repetitive stuff.
There's still tight coupling in some places (ModelForms, for instance, are arguably part of the controller layer and are tightly coupled to the ORM). But they're reasonably optional (you can use plain Django Forms instead of ModelForms in your views or not use the Forms library at all.)
My experience with Django (for instance: class-based views and admin parts) is actually that you have dozens of magical classes or methods and if you don't know them all, you're screwed. Often when I try to do something, many aswers on StackOverflow boil down to "just override a_method_that_is_hidden_somewhere()" or "just use ListButWithSpecificBehaviorView(), easy you see?".
Are there any specific example you have in mind where Rails do something magical that requires more code in Django but where Django is more explicit?
PS: not trying to start a flamewar, both are OK-frameworks, bla bla bla ;-)
http://www.monkeyandcrow.com/series/reading_rails/
Sure, Rails is complex, but it takes on that complexity to let us be productive. When you run into that complexity, read the source.
However, just because something is heavily abstracted doesn't mean it's a bad approach, at least from a productivity standpoint. Without certain things being heavily abstracted, we'd go insane.
Just as
User.create(params[:user])
CoolClass.new('foo', 3)
printf("It's %d degrees today in %s.\n", temperature, city);
Are they all heavy abstractions? Yes. Is it oftentimes very nice to be able to use heavy abstractions? Also yes.
Also I would like to point that "translates" is a little misleading word. There are two ways of implementing an abstraction from a higher level system to a lower level one.
You can generate code or you can write a runtime framework that does the work dynamically. Although from the higher place both may seem the same, there's a huge difference between them that has consequences.
I wouldn't doubt it; compilers have become amazing at optimizing. But printf is hundreds of lines of C, at very least: http://opensource.apple.com//source/Libc/Libc-1082.20.4/stdi...
And most important, a call is not the same as the implementation of the called function, my point to begin with, please see my comment in the context of yours.
In any case, the complexity of the called function is exactly what we're discussing — it's why the author objects to "User.create(params[:user])"
printf has a well design side effect (printing to stdout). Coolclass.new has an expectation of an instantiation of object in memory. If Coolclass.new also called an external service, then that would be a violation in my opinion. Thankfully, we generally don't do that.
User.create is not only capable of tons of side effects (just like Coolclass.new) but it is encouraged to do so (via callbacks and such).
I think maybe your broader thesis is we almost always need all 6 things. And if that's true for you then Rails is a good tool for you.
If we only ever need one out of the 6 things at a time then ActiveRecord is only adding extra complexity for us.
I think OP is basically saying I usually only need one or two and that they'd rather not have the extra layer of indirection... "save(andValidate)" is fine for them. They don't need the orchestration abilities that the declarative "afterSave(validate)" step affords.
DHH's suppress really is a good example. If you are calling save(andValidate) everywhere, you can't really do something like suppress(), because your validation logic is disbursed.
My opinion, and I think maybe OP would agree, is that there's usually a nice, composeable way to get the same problem solved, without resorting to a giant engine that understands all the different parts. But that's just an empirical assertion on our part. Obviously your mileage will vary.
I think you want "dispersed" here.
Because before rails 1.0, I worked in php.
Many people may actually be too young to remember, but the jump from php and anything else that was state-of-the-art at the time to rails was without doubt the biggest leap web development ever took.
The most meaningful advances actually weren't just technical but social. It would've been possible to write an excellent webapp before rails, but just about nobody ever did. The opinionated nature of Rails many are complaining about today was a revolution because it taught everyone using it good architecture. You can nitpick about any one of those opinions, sure. But back then it was common to join a project with >100kloc with directories containing password.php, passwprds.php, pass.v3-old.inc, large_image.head.2002-v1.jpg & employees.xls. The quality of almost any rails project I have seen is, in comparison, excellent. It'd say a new team member on a rails project was productive in less than a third of the time it took in non-rails projects at the time.
So, to anyone complaining: I'm pretty sure that looking into any of your strongest held believes on web dev, you'll discover that rails had significant influence in creating them in the first place. To do something like that, pretty much as just one guy on the beginning, should afford someone a certain amount of respect.
This behaviour is counter to the model2 MVC implementation that rails is using as controllers should really be in charge of coordinating (helped by specialized classes if need be).
The author correctly points out that the way rails deals with views is painful however rails views are not tied to the model at all, they are tied to controllers and this can be modified if need be.
I personally maintain an approach of tying dedicated ruby classes to view files (e.g. SidebarComponent) and compose the view in the controller using a chain of these classes. This approach is much more object-oriented and avoids the weird pass-along view-hierarchies that many rails projects have.
There are much things to improve about rails but the project doesn't seem to absorb more object-oriented approaches over time and is tilted heavily towards DSL's for everything and doesn't value creating a more specialized class hierarchy to encapsulate more complexity.
I don't see a need to move away from Rails yet though as you can easily work inside the framework in a more Object-oriented approach. I guess you can characterize my approach as skinny models, skinny controllers, fat business logic objects and every partial is powered by a view object.
Simple as in simple, fast, productive, beautiful Ruby-like syntax. Favors a functional and immutable workflow over object-oriented and mutable spaghetti code.
It sounds great in principle. I'd love to move from Rails toward something more functionally-inspired, but I worry that lack of libraries and google results is going to be a net productivity killer over the Rails + evolving into micro-services approach.
Can't comment extensively on the library ecosystem but you have access to everything from Erlang via trivial interop.
(Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)
Phoenix apps aren't actually monolithic, but I'll let the creator of Phoenix explain this himself (https://news.ycombinator.com/item?id=11749741):
> A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular Elixir application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators.
I think it's really quite a testament to Phoenix that so many people think it too is monolithic. A client can request a Phoenix application and I can get productive immediately without worrying about creating an unmaintainable, unperformant mess. No wasting 2 days on configuration hell. I can even jump into an existing project and be productive.
Another point is that the libraries around Elixir aren't (in my experience) Phoenix-focused or obsessed with magical Phoenix integration. In most cases, things work well together. Just call functions.
Monkey-patching, thread-unsafe operations, and uncontrolled shared global state are all non-problems in Phoenix. Decent code architecture and testability aren't usually a problem either because proper separation is enforced. Functional/immutable programming makes a huge difference here too.
Ecto 2.0 is really what ActiveRecord should've been. It's incredibly well thought-out. I suspect the author would be really pleased with Ecto.
Finally, Phoenix favors simplicity over ease in most cases. Complexity is not hidden in 100 layers of abstraction and callbacks.
The author also mentioned DHH's... colorful personality. So I'll take this opportunity to mention how much more welcoming and humble Jose Valim and Chris McCord are.
class User < ActiveRecord::Base
So, when DataMapper came along and favored composition over inheritance I was sold.
However, my experience with DataMapper was that it didn't have the stability of ActiveRecord, nor did it reach feature parity.
And, then Rails killed Merb. At the time I thought it was a tragedy. The competition Merb provided did improve Rails, it would have been nice if that competition had been longer term, though. On the flipside, I wonder if there would have been enough community to support two large Ruby web frameworks.
In the end I made peace with Rails and ActiveRecord (and, believe it or not, even ActiveSupport!). I don't have great love for Rails, but it is a powerful tool, so I accept it for what it is.
That said, I think the author's criticisms are well stated and hopefully there will be some influence on the future direction of Rails, etc, and the way devs approach Rails.
If you don't want to use ActiveRecord::Base methods, why don't you just declare a class without it? You can just do "class User" you know.
class User < JSON::Base
Instead we have JSON.dump(user). And, if I need to customize the way the User json is written, I can opt in by defining a method. Thanks to Ruby's open classes, I can make the definition of such methods optional, suppose a separate file includes something like:
class User
def as_json
end
end
Now imagine if persisting a model to the database were similarly flexible? What if we could do this?
ActiveRecord.save(user)
As it is, I've come to accept the ActiveRecord approach, but when I create a model that extends ActiveRecord::Base, I think of it, not as a User, but an ActiveRecordPersistedUser. Where it makes sense, I separate my BusinessModel's from my ActiveRecordPersistedBusinessModel's for clarity.
ROM also uses it as its SQL backend: http://rom-rb.org/
I guess if anything it speaks to the level of centralization in Merb development at that time?
Databases aren't object-oriented. Thinking of them with an is-a, LSP etc. mindset is a recipe for pain down the road. Databases are containers for facts: a means of storing, finding, synthesizing and manipulating facts. Your User class isn't a user of your application; IMO it's wrong to think of it as an object, because it could just be a slice of the User's facts (e.g. a subset of the columns).
I'm not a big fan of object orientation any more, and I like my databases to be stores of facts. The data in the database is primary; code in the application is secondary. Persistence isn't something I add to my benighted objects to let them be reanimated by query; persistence is what lets me briefly get a handy representation of a tuple locally.
To my mind, ActiveRecord models are little more than hashes with a nicer syntax. I don't need them to be much more; I don't want them to be much more. You can try and add methods and make them smaller, but coordinating the manipulation of facts is problematic in a transactional world, and the responsibilities aren't clear either. Object orientation is predicated on the idea of message sends and hidden state; tables have explicit state and no behaviour. Not a good match.
As a framework for building comventional HTML templated database backed websites I still think it's near unbeatable, especially with the addition of a few common gems. However it so often gets shoehorned into other places - API backends, rich client apps, and massive systems. Places where the Rails conventions rapidly go from everything falling into place to getting in the way and needing to be worked around, or heavily tuned.
I completely agree that ActiveRecord is the core of why big Rails applications are complex to work with and often exhibit disproportionally poor performance. It doesn't lend itself well to composition, and results in data persistence being intertwined with business logic. That's fine for early prototypes, and in all honesty will get you to market quickly, but it makes extracting the concepts you discover during development into a coherant API much more complex than I'd like.
These days I still use Rails for the aforementioned HTML generating web applications, but it's often acting as an API client to systems built on top of a Grape based backend, with an API built around service objects and a simple data access later.
The project is very lightweight right now (benefits of being a young project with a sole full-time contributor), but I'd be interested to hear your feedback as to what you think is or isn't necessary for continued development. :)
We serialize models to JSON automatically in the response layer, and all models have a `.toObject()` method that takes an optional interface (which keys to actually serialize).
There is full API documentation but I still have a lot of work to do creating more fleshed-out tutorials. :)
I agree with pretty much every brickbat hurled at Rails in this article, except for one thing:
> Both projects were ultimately killed by Rails as Merb was “merged” into Rails, what turned out to be a major Rails refactor for its 3.0 version. DataMapper lost its community attention and without much support, it never evolved as it could if Merb was not “merged” into Rails.
DataMapper wasn't killed by Rails absorbing Merb. DataMapper was killed by "Things You Should Never Do, Part I":
> "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."
(http://www.joelonsoftware.com/articles/fog0000000069.html)
DataMapper 2 was insanely ambitious, and true enough, it was never finished. A core subset was salvaged as ROM (Ruby Object Mapper), which has a certain artisan purity but is a long way from hitting the readable/understandable sweet spot that DataMapper originally had. But DataMapper 1 was abandoned by its developers. Pull requests languished and there weren't even any maintenance releases. I idled in the DataMapper IRC channel for a while and pretty much every query was answered with "don't bother, wait for DM 2". Unsurprisingly, people switched to ActiveRecord instead.
I still use DataMapper. I use it in my own framework, which is plaintively simple compared to Rails and no doubt makes a load of mistakes, but they're the mistakes I've chosen to make (which, as per DHH, is "opinionated" software). I would love DataMapper to be, if not revived, at least slightly maintained. There is life outside Rails, but you have to want it.
Not that rewriting from scratch is always a good move. Evidently, DataMapper proves that!
As far as our DM2 efforts go, this really didn't end so bad. rom-rb is growing very fast and we're already in the process of making it easy to use for typical CRUD stuff. Hanami integration will help here a lot too.
I didn't know how to put the genie back in the bottle. I didn't have the same problems that prompted me to create DM in the first place anymore (and by that point, I wasn't sure that porting a large Java Pattern to Ruby was even a good idea considering what I'd learned in the process about method dispatch performance in Ruby) and I was burned out on maintenance. So I handed over the keys and the rest is history.
I messed up. :-)
Today I'm happily writing apps with akka-http and think O/R Mappers are a fundamentally flawed idea. It's like trying to build a truck to move a few yards of dirt 100 feet. It'll never pay off. And I think even "users" would probably find that the hours they put into learning and using the tool will never get ahead of the performance, simplicity and linear scaling of effort they'd have had with a simpler solution.
So these days I'm much more likely to write this in Scala:
val limit = 10.0
sql"SELECT name FROM coffees WHERE price < $limit".as[String]
Plus Contextual Validations in the O/RM is just a bad idea. Even if they do appear in the PoEAA. First-class-Form objects and deserialization/validation at the app boundaries may not be a new idea, but it's the right one. (IMO)
Anyhow, you made really good points here. I've worked on ORMs for a couple of years before I concluded the same - NOT WORTH THE EFFORT.
My approach with rom-rb is functional, as in this project works more like persistence libs in functional languages, rather than an O/R mapper. I removed the whole idea of mutable objects and managing their state using UoW etc. This simplified the stack a lot, and despite a complete lack of any performance-related tweaks rom-rb is already faster than ActiveRecord.
I also agree with your opinion re validations. I removed this concept from rom-rb as well and built a standalone validation library instead. This works very well.
Cheers!
We were a pretty enthusiastic bunch back in the day. Glad to hear you're still pushing things forward.
> So these days I'm much more likely to write this in Scala:
I do this sort of thing a lot in ActiveRecord. I'll write a class method with ".where('price is null or price < ?', argument)". I use ActiveRecord a lot like I use Sequel, drilling into the underlying database layer. It occasionally bites me, but when it does, it's a good reminder to simplify my database architecture while nothing else is relying on it.
This way I can get the benefits of an object that behaves the way I want it to behave, but also respects the data layer. I don't want to give up either.
I do feel like Rails, in an effort to make things easy, encourages devs to overcomplicate their apps.
Check "Phoenix is not Your Application" at http://www.elixirconf.eu/
It starts with the right claim but it ends with workers inside Phoenix. Instead the router and the http server should be at the same level of the other workers. Actually, they shoul be much less important, an implementation detail.
And yes, phoenix will end up bogged down like Rails, and hex will end up chock full of crap, it is the Rails developer mentality I'm afraid, they just can't help themselves.
I like to think of Phoenix as an interface to my app. It's less intrusive than Rails.
You don't have to use Ecto (the "ORM" thingy that is actually not an ORM) to get get the full power of Phoenix, it's also decoupled.
Regarding Hex, it's like every package managers out there. Sure you can publish anything. Rubygem is full of crap, npm is full of crap etc.. But I can also find some very small and focused libraries that wouldn't have been published, had a quality filter been setup to publish anything.
I have no idea how big the community behind each library/framework is and honestly I don't have the time to properly test-drive multiple and research the health of their respective ecosystems. With Rails I can rely on 10-15 gems that can help me with 80% of my projects. Perhaps I overestimate my reliance on 3rd party code, but that leaves me with my second issue.
Ruby jobs are de facto Rails jobs. I have weekly email newsletters set up for Ruby jobs and in the last 3+ years only a handful were Sinatra/Rack based. It would be interesting to see a reliable source of non-Rails Ruby jobs out there.
Even if you grant that good programmers can pick up new languages or frameworks easily (which I'm not entirely convinced of - there is a wide gulf between "can follow the tutorial" and "successfully used in anger"), you'll incur a penalty in velocity while all your new hires learn Framework X.
Anecdotal example of the perils of going off the beaten path: I often see a job advert on StackO for a company looking for Python/Django guys. When you click through to the job description, they are actually using Perl/Dancer. Not that there's anything wrong with that, but for me personally that's a deal breaker. I have no interest in investing the time to become proficient on that particular stack.
I think the question is more "Does what we're doing require good programmers, or can we get by with shitty ones?" More often than not, you're not doing anything special, and you want to pick a platform that the cheapest, most common programmers out there can add features in a non-disastrous amount of time (different depending on industry + your competition), and not generate enough technical debt to collapse everything before the next rewrite/upgrade cycle.
When it really boils down to it, ActiveRecord is a perfect pattern to deal with the "submit a form, validate it, run some logic, return the results" round-trip that's the core experience of web applications. Do you have validated data you need to do really complex logic on? Sweet. Send it on over to some PORO's. Have a complex query that isn't easy to cache? Nice! ActiveRecord will get out of your way. What's really hard is figuring out how to frame the problem in a way that makes Rails a great solution for it. This part is really really hard, I think in a lot of ways akin to art (and by 'art' I don't mean some deeper honor or aesthetic - just that there's no guidance), since the principles and patterns actually come from your domain and not somewhere else. And the developers I know who really hate the way Rails does something, especially ActiveRecord, are huge on applying patterns.
When I've taken the time to think through how to structure, really deeply, the applications are a pleasure to change and modify even when I come back much later. And for me, the proof is in the pudding: those aforementioned other developers who hate ActiveRecord don't complain! They'll see it, give a small 'huh,' then go do what they need to do just fine. But when I don't, they turn into the twisted spaghetti nightmares. I see a massive sub-current of dissatisfaction with Rails, and I think the reason for this is just a subtle but markedly different priority of thought. I can't articulate it yet, I just know what it looks like when I see it.
Anyway, I love Rails as it is now. Soon I hope I can deploy a single application across web and mobile platforms natively, along with supporting them all, as one guy. That's insane. Really like this blog post because I've got some things I'd like to be able to do with the ActiveRecord API, but I'm not really sure how. I don't know why the thought never occurred to me to just ask!
This doesn't change the fact my code is OO - I use objects, composition, decoration, delegation and many other OO techniques, and in general try to avoid heavy inheritance-based patterns.
I can understand how people may think I'm trying to use ruby in an awkward way, but this is really not the case.
True. And yet, it reminded me of that article Zed wrote, which I summarized as a vulgar critique of the internal politics of the rails community.
There's too much purism in those kinds of arguments, arguments that really are more about spectrums. It sounds like Rails is really great for learning the shallowest 40% of a wide variety of programming concerns, and a lot of web solutions for small clients aren't ever going to dip below that 40%. And as soon as you get beyond that 40%, asking questions like "but what if it doesn't make sense to do it that way?" and "what is that weird runtime bug that doesn't happen in my development environment?" and "why can't I refactor without being scared I'll introduce a weird regression bug?" then it's totally fine to be attracted to the idea of static typing, compilation, and libraries/frameworks that are more explicit.
[1] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome...
While at Google I became aware of Go and what that looked like at scale. I would highly recommend trying out Go. I think the simplicity will be a refreshing change but there will also be some familiarity coming from the Ruby/C world, can't quite pinpoint why but just feels that way.
And if you're looking for frameworks, shameless plug, I'm working on this https://github.com/micro/micro.
Secondly, avoiding mutable state is a general, good advice,
which you can apply in your Ruby code. Ditching global state
and isolating it when you can’t avoid is also a really good
general advice.
When every new operation on a data-structure starts by producing a copy of the previous version it seems like you'd really want a runtime which is efficient and intelligent about how it manages memory?
Unless that idiosyncrasy of Ruby has changed since I last used it several years ago. In which case. Nevermind. :-)
As far as my not-so-big experience with them goes, the immutability programming techniques in Ruby actually help a lot with its sticky RAM problem. Complex object hierarchies of mutable objects and references to them are a nightmare for the GC. Having structures/objects that are used and [quickly] thrown away without (or rarely) being attached to complex object graphs is making the GC work more reliably, and faster.
But dare you. You just go down one simple level. (first level is what you get with rails and for example extending active record.) it becomes a horrible mess of dependencies and magic / structures.
I never found a framework so hard to modify. ( for example writing your own multi category / multi tag gem)
That's when i stopped web dev. It was just mind boggling. This is several years ago. I think around version 3 or even 2? And every version broke the active record stuff...
I really thought rails would catch on in germany. But if you look on indeed there are literally like five jobs in Germany... Maybe I'm not alone with that problem...
So I definitely see where he is coming from with all this, but truth be told it was never Rails' indent to be a precision instrument. It has been a reliable framework that makes a lot of Developers very happy. A great reliable car for the masses so to speak. But not a Ferrari.
I think everyone has different needs, and you have your personal needs which Rails no longer satisfies, so you are moving on.
Rails still solves a lot of problems for a lot of people I believe. I work as a consultant for a few companies and in some cases I see people losing time and money on what would be resolved immediately if they had just made the right call by using Rails.
Good luck on your journey, and remember the rails community will always have its door open for you :). Your projects on github look exciting, I will take a look at them. Very cool stuff!
I remember a few years ago I teased with ditching ruby for node.js. I'm glad I dipped my toes in the water and waited for Elixir.
Solnic has contributed a lot to the Ruby community and I'm not surprised to see him leave.
Within the the web domain of Ruby there has very much been a Highlander attitude of "there can be only one". That one has always been Rails. For someone that wants to create better pieces or have more choices other languages are more accepting.
On much of what he said in the article he is on point. Personally I've never been a big DataMapper fan (sorry dude, I just prefer Sequel), but I do agree ActiveRecord isn't great.
I've considered leaving the Ruby eco-system, but I look around and don't like the alternatives I see either. One of the great things about learning Ruby on Rails is job skill relevance. If you want to make a move and you know Rails then pretty much all job search matches are a green light. If you know Java and you are working with Play then nobody wants you because they want experience with Stripes, Spark, or god forbid Struts; now you have to relearn the whole framework and rinse repeat each time.
Personally I stick mostly to Ruby on Rails (and JavaScript) for my professional work, and then on personal projects I work in various obscure technologies that I just enjoy because I enjoy and I don't need to worry about if it will help bring in the bacon.
The concept of the zeitgeist is interesting. A lot of general dislike of Rails is in the air and the only question seems to be what the replacement will be, not if there will be a replacement. Naturally the ruby guy thinks it'll be a new OO ruby framework which has always done the impossible before and the Clojure people think it'll be the usual immutable functional magic which has always done the impossible before. Best plan for the future is wish them all luck and wait and see. I don't see any other useful strategy at this instant?
My money is quite literally on the Clojure guys, I was one of the backers of the Arachne kickstarter, but best of luck to Hanami and rom.rb and all the new wave ruby stuff. One of you revolutionaries had better succeed, or else...
Some of it may be the natural result of success and age. A near decade of continually having to revamp my rails code "because the guys at hulu really need it" or "this is very helpful for github" is inevitably going to eventually make me say (if you'll excuse the profanity) F them I'm sick of rails and authoritarian monoculture in general and hulu is very nice but it can just go help itself, I have work to do that isn't "I have to chase latest fad that someone else needs". It may be a natural state for the lifespan of a framework to enter a stage where staying on the bus is more expensive than hopping off, maybe even hopping off anywhere. I tried some Play framework projects and I felt the sirens pull of static typing, but, after a few years, unless you keep up with changes, the technical debt just accumulates each framework revision until I'm sick of seeing releases instead of pumped.
I'm talking about projects that last many years not a semester or so. I'm not sure the chronological nut has been cracked of heres a magic solution for long lived projects. Assuming there is a magic solution. Perl CGI I suppose (only slightly tongue in cheek kidding)
I prefer to not use Helpers and AR callbacks (generally Concerns too) as I don’t think they encourage good OO even though they are officially part of rails.
Ultimately it comes down to what your goal is. Is it to deliver some business value fast to end users? Build a new product with a small team? Then I think rails is a great tool to achieve that.
Disable the box-shadow on .widewrapper.main and it works fine.
We fixed in in Firefox 47, but the fix was deemed too risky to be uplifted to Firefox 46. That was probably a mistake. Anyway, Firefox 47 is going to be released in two weeks on June 7th. In the meantime you can remove the box-shadow from .widewrapper.main using the devtools, or you can use Firefox Beta (47) or Firefox Developer Edition (48), which you can get here: https://www.mozilla.org/en-US/firefox/channel/#developer
"That David is such an asshole. I never want to see him again..."
(with apologies to DHH, whom I find amusing, even if he is a bit "coarse")
Often, such proclamations are not noteworthy. However, if the speaker has been a long time user of xyz and a contributor to it, then the proclamation is noteworthy.
- ORM is bad at any sort of scale/complexity.
- Net IO that looks like property access makes it too easy for devs to do bad things, N+1 queries etc.
- ORM abstraction is not helpful when you know the exact efficient query you want.
- ActiveRecord Models + the Ruby module system encourage OO bloat.
- ActiveRecord database drivers are too numerous and not well implemented. Default schema generation includes many SQL anti-patterns.
- ActiveRecord has too many public interfaces, too much meta-programming. Hard to understand scope, Hard to analyze and improve performance.
- ActiveSupport monkey patches too much of Ruby. Need an very deep understanding of language to understand what's going on at a non-superficial level.
- Rails/Ruby community places too much emphasis on "clever" DSLs / APIs
- If your stack/framework choices limited to dynamic languages, Rails is a lot less efficient than Node and for web apps you need JS developers anyway.
ORM is good, as long as you use only SQL in your backend.
However if you've run into the same problem where you feel like you need to either make fat model or fat controller in Rails, here's a simple solution:
For write operations (aka user interaction) I use a combination of solnic gem (Virtus) with ActiveModel that way I remove a s*t load of responsibilities from AR and the controller : - params management (and strong params) - validations - nested associations - callbacks - And all the context management (like user vs admin...)
That way I only mildly part from the rails way and yet have a good separation of concern. Actually ActiveModel is used by ActiveRecord so having a form object relying on it is still very much rails compliant. The refactoring is minor (no hexagonal stuff) and the level of indirection very low.
I've never written a line of Ruby, but trying to read Rails code evokes me all this: it seems like a framework created with the sole purpose of hiding everything possible from the programmer.
Obviously if you follow a framework from day 0 you don't even notice it. For newcomers, it's a source of frustration.
For example, ActiveRecord class names map to table names through a simple pluralizer (UserProfile -> user_profiles). That's a convention, no configuration needed. Just write a class and off you go. You can override this behaviour, but you can also write huge apps that just follow the convention. Other frameworks would typically make this mapping explicit.
You do need to read the documentation to see what the conventional behaviour is, but it's not very deep knowledge. It's not much worse than other frameworks, where you need to find how things are configured.
42.times { puts "foo" }
1.upto(9) { |n| puts n }
puts 1.year + 7.months - 1.dayIt takes a little getting used to, but once you are, then the tooling is there to help you make sense of these things:
1.method(:year).source_location
The bigger issues with Rails I see are the monoculture issue raised in the article, plus the intractable issues with ruby around performance, memory bloat, concurrency, and last but not least, the multi-paradigm nature giving you functional features, but without any of the usual immutability guarantees (unless you follow a constrained and unconventional coding style which no one does in the ruby community).
You can explain those two things you mention in a few seconds ("Ruby allows adding new methods to anything; the 'hours' method is defined by ActiveSupport"), and then the confusion has been eliminated. That leads to an increased understanding of Ruby.
FWIW, I've had a whole bunch of junior colleages learn Ruby, and those things were never a point of confusion. If anything, I have the opposite experience; Ruby and Rails are superb for newbies because of all the sane (convention over config) defaults.
Unfortunately, one segment of the Rails developer culture has perpetrated a lot of ugly overdesign (mini-frameworks such as Devise, ActiveMerchant, etc. that inject themselves into Rails in brittle ways) that certainly will confuse newbies. But that's not Rails' fault.
Explicit configuration may teach a new developer about a codebase, but it also means that there's more upfront work when developing. If the conventions are already there, in the form of good developer habits and good workflow, it's more pragmatic to encode them as explicit conventions, rather than introduce lots of un-DRY boilerplate.
Some of my favorite Rails devs are former Python devs. They appreciate conventions and the freedom they give you.
The most common criticisms are: it's slow and it has too much "magic."
At the end of the day, it comes down to this: every framework has its pros and cons. When you use a framework, you gain certain benefits but sacrifice certain things and have to conform to the framework's opinions. In the case of Rails, the primary benefit is extremely fast prototyping. But that's only possible because the framework hides a lot of complexity from you, which can bite you in the ass if you try to go outside its conventions.
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sor...
> if your use-cases don't fit into "Rails way" your screwed
Of course.
If a startup service doesn't fit Rails, they should have picked something else. I'm not using Rails for everything.
The only really common startup use case it's decidedly bad at is realtime/sockets/streaming data, where Node takes its place as the hack-it-together tool of choice--at a significant productivity penalty compared to Rails.
It's also, of course, pretty bad at all kinds of tasks unrelated to web development or REST apis. You wouldn't want to write machine learning algorithms or do statistical analysis in Rails, just like you wouldn't want to do 3d game development in Rails. And while you do occasionally see startups who have bolted some heavy data processing or pseudo-ML monstrosity onto their Rails apps, I've never seen anyone in the Rails community claim that was a good idea. The vanilla recommendation there is to keep your main server stack in Rails and then write services in something more appropriate for those needs.
I agree with the author wholeheartedly, but there is certainly value in getting something that works quickly.
I've always heard people blast Rails b/c of Twitter's experience but Twitter did survive it and scale. Maybe Twitter would have never gotten to the level of success they did without using Rails? Also, I'm not convinced that the original developers at Twitter did a great job implementing the first Twitter infrastructure. It is possible to write bad code using Rails that would be bad no matter what language or framework was used. It's a huge unknown in that story that entirely changes how to judge the outcome.
I think your statement is patently false.
So yeah, survival bias. If startups failed and used Rails, it's because they were bad startups for reasons outside using Rails.
If you are programming in ruby you are ONLY doing a front facing webapp. There are lots of servers out there that run headless. The ruby ecosystem is completely dominated and controlled by rails. As a result, ORM mappings and gems are completely focused on a web-response centric world.
As monolithic ruby apps are broken into microservices, ruby as a language will also be abandoned for those microservice back-ends - simply because the ruby ecosystem has only one way of viewing the world.
I too eventually came to a similar conclusion albeit on different platforms. Frameworks get you started quickly but you will eventually hate them. And I do mean framework and not library (there is a subtle but massive difference... yes the oxymoron was intentional).
Its even worse in Javascript land. You could rewrite this post and just insert one of the many Javascript frameworks like Angular.
I have used Padrino (http://www.padrinorb.com) a lot recently, which is really a framework on top of Sinatra that make things like testing, ORMs and renderers easier to integrate into a raw Sinatra base.
I especially love that I can use 95% of gems written for Rails in it - about the only ones I can't use are the ActiveRecord specific ones. (Note: I use DataMapper in most of my projects, but looking at Sequel as the ORM for my current app).
Recently, I've been doing a lot of Go (Golang) development. For me, it's sort of the anti-Ruby-Rails. I really like the fact that it requires me to "roll my own" in so many situations. I need to understand what's happening under the hood to make things work.
But, the abstraction/magic of Rails is useful. Speed to market with trustable, battle tested magic is a profitable proposition.
I want to introduce Golang into my current project, but I haven't quite found the right place for it yet. Rails makes it so much easier and faster to add functionality at our scale.
I've tinkered a bit with Golang and I love it but IMO it's too much extra work in the Web development part. It's exciting and very educational to pop the hood and understand how many things fit together, especially if you're coming from Rails, but you should be aware that after a while the novelty wears off and sooner or later you'll start looking for the quicker paths to introduce trivial Web cruft.
I am yet to experiment with Elixir + Phoenix but the community feedback so far has been fantastic.
Laughably, no.
Code is written by people; it's essentially a set of ideas that execute and do things in accordance with the vision of the creators. The creators poured themselves into the tool. Code is an extension of the self.
(If it isn't, it should be; people take the best responsibility for code when it's like that, and it's probably the main essence that separates OSS from most proprietary work. People don't fully invest themselves into creations that can completely disappear out of their lives forever upon the next organization restructuring.)
A framework dictates you the structure of what you are doing. Libraries can be combined, replaced, and used in various ways, fitting more the task at hand than the mist common case.
I can't imagine what it must feel like to receive a mid-to-large sized Rails project to maintain.
It is extremely challenging and very educational for me, and I appreciate the experience. I've always been a fan of repairing and improving things -- but truth be told, it gets tiresome and annoying VERY quickly.
I am currently working hard to stabilize the entire process of small refactorings for the sake of the new features/bugfixes, streamlining deployment, making full separate QA/Staging environment (yes, even that wasn't addressed by the previous team) so we can test with confidence and without fearing we'll break Prod, and to reduce the 3rd party API dependencies -- right now they are 20+.
I am hopeful that after I stabilize the project and make the process of introducing new code easier and quicker, I could then make the case for gradual exodus to Elixir/Phoenix. Realistically, I am not seeing that Rails abomination I inherited to be a sustainable job for even one year. Inevitably I'll burn out, the customers will lose patience, and my employer will be unhappy both with me and the customers. Not cool for anyone involved.
So I'll try to gradually run away from Rails. As pointed by numerous smart people here, it's suited for medium-sized projects at best. Even Sinatra/Padrino and 50+ attached libraries would have been much easier to maintain.
On top of that changing the database becomes a royal nightmare because the database is what defines this AR model that all of your buisness logic and application layer spaghetti dependency relies on. The databases usually end up full of garbage because without complex validations and lots and lots of tests which by the way were never written ruby and rails will dump any trash into your db whenever. So you end up with columns with like 10 variations of the definition of NULL or FALSE.
Usually around this point your app just slips into a state of quantum uncertainty. It essentially ceases to behave deterministically at least when viewed from within the bounds of human perception.
Its hard for experienced developers to bend rails in away so that things don't become overly dependent on each other and neigh impossible for average or beginner rails developers to manage.
Im just really not impressed with rails at all especially coming off of 6 years of development time on huge enterprise apps written with the c# .net libraries. I mean really they are light years ahead using IOC dependency injection for injecting service apis into controllers while using mapping patterns for keeping buisness and database logic separate. Its the only way to break up large apps and keep them sane and maintainable. Additionally static typing is the only thing that keeps things sane in really large applications doing complex business logic through many layers of interfaces.
Truth be told, I am not sure how well will I cope. I am good, I have experience, I have been doing lots of quality repairs in my life before. But you know what? At certain point you don't think it's worth your time and energy. That's the real enemy here -- demotivation.
I spent humongous amounts of time in the object-oriented land. I think I'll just hop to the functional programming world -- isolated functions, functions as first-class citizens, immutability (hell yes!), no shared shate (oh God please, I want that!), and goodbye side effects. At least I hope so. It might just be another shiny thing I'll be pursuing and won't be much better. We'll see.
But you know what? I prefer working hard to build things from the ground up in a new and much better language and ecosystem than to spend my life trying to demystify somebody's strongly opinionated framework which doesn't cover even 40% of what I need in my project.
I simply hate the "magic". I don't touch anything with too much magic going on and even avoid some features of Eloquent because of that.
And since it is heavily inspired by rails...
It's got a strong, friendly ecosystem that encourages small, composable libraries. For every level of your application, there's competition - http servers, sql abstractions, front end libraries. And there's great resources to help you choose what works best for your use case - the Luminus docs, books, blogs, and several active forums for discussion with library owners and just regular developers.
Couple that with a community that really took Rich Hickey's "Simple made easy" talk to heart and the default immutability and functional paradigm and the abstractions that Clojure itself has to offer, not to mention the performance the JVM brings to the table, and I think it's a great language to hang your hat on in the long haul.
Also after programming for 4 years a bit I've felt the core of programming beyond CRUD/consuming APIs is about manipulating data structures. Having powerful utilities for this and not having to shove everything into classes and objects makes it really easy to get stuff done. Going back to Ruby feels like I'm working with a kludge in comparison. Everything that doesn't need to be a class is one, then you get caught up in naming things. Then you try to debug things to end up with an object that has 500 methods on it and you don't know where half of them came from because they were metaprogrammed in through 10 layers of indirection. Yesterday I tried upgrading to Rails 5 and gave up because I couldn't debug an outdated library in 6 hours without realizing I have to figure out what this library and ActiveSupport/Model is doing in order to make headway. Ain't nobody got time for that.
* I am not aware of any CS program that do thesis at a bachelor level.
* It is hard for me to imagine getting approval for doing a thesis on "Rails", it is mostly a CRUD web framework.
http://www.math.ucsc.edu/undergraduate/compreq.html
I could see how someone might find material in the emergence of Rails in web programming for a thesis at the undergraduate level.
https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934
I did maintain DM for a few years, but burnt out as there wasn't enough time to keep up with the community demands and work a full time job. There were a couple of years I effectively worked 40-60 hours a week on DM and only 5-10 on work; this wasn't tenable long term and burned me out.
The small dev team, of which solnic was a core member, are an amazing group and there's no way I could've maintained DM for even a fraction of the time I did without their support.
The author is right, competition is important, the Rails/Merb scenario is the open-source version of Microsoft E.E.E
When I started with Rails it felt like magic, you didn't know why things worked.
From what I've read here, it really doesn't sound like his time with rails is quite "up". It sounds like he has read the writing on the wall about rails, after a very long time with the framework (certainly longer and more involved than I've been, though I have used Rails quite a bit). This is different from realizing that a technology won't last "forever", it's a more distinct understanding that you see where things are going and how your current tools don't quite match up anymore.
But when my time with Rails is "up", that will mean that I have largely stopped using it. I'm mot counting maintenance, or perhaps the occasional one-off, I mean that if my time with a technology is "up", that means I don't use it anymore for day to day work.
I'd be interested in reading more from Piotr Solnica on this topic, because I'm in a similar spot. I don't see Rails as the ideal match for much of what I'm doing on the web, but I'm not anywhere near ready to give it up. I increasingly need much more interaction between the client and server than I get from the MVC approach, but I'm not sold on javascript front ends with a web service backend, at least not the way it's been presented now. For starters, I personally (yes, this is very much a personal trait) don't relish the idea of giving up Ruby to write most of my app in Javascript.
It's not just that I like ruby, I don't really like the idea of giving up the very rich set of languages I can choose from on the server side, or minimizing their role, in order to allow javascript to take over most of my programming work. I also feel that javascript front end frameworks are still a moving target, and I have a suspicion (like I said, I'm trying to sort this out) that when the dust settles, elaborate javascript front ends communicating with a web service written in something else won't be where I go next. I've read about some exciting new possible directions in this blog post, and I've read interesting things elsewhere (Volt, specifically, non-js languages transpiled to isomorphic javascript, more generally). It is all very exciting and promising, but is this the moment to give up on Rails, which works though I find myself increasingly shoehorning things into it? For me (again, just for me, everyone has a different set of interests and tasks), no, not yet.
Drawing on my past experience - the last time I felt this way was when web programming in java moved from the jdbc/servlets/html with libraries to struts, struts2, spring mvc, pico, spring di, jpa, hibernate, ibatis, wicket, tapestry and so forth. Looking back, I wish I'd had the conviction to stick with the old way of doing things even though I knew its days were numbered. Keep an eye on things, keep learning.
It sounds to me, from the end of this article, that this is what Piotr is doing. There are some good suggestions of where to go next, but I guess my question for the author is this: where are you going now? Is your time with rails "up" in the sense that you no longer have a substantial day to day use for it, that there is a new technology that you'll be working with now the way you worked with rails for 9+ years? Or is this more a situation where you see that your time with rails is ending - if not today, then certainly before long?
It means that I'm no longer interested in supporting Rails in my gems and I accept the fact it may hurt adoption of these gems. It also means that I will be actively working on an alternative stack that can be used instead of Rails. That's why I support Hanami project and experiment with dry-web project too (which is more like a toolkit for building your own stacks, already supports Roda, and we'll add support for Hanami too).
Apart from that I'll be spending less time on OSS and instead I'll be learning new languages. That's pretty much it.
Framework development is pretty far from what I do (I rely on the efforts of people like you, honestly), but like I said, I can see the need. I'll probably be using something like what you're working on in the not too distant future. Best of luck with your efforts, I hope good things come of it.
To make them have to go back to coding academy school in two years?
So that they maintain legacy codebases and don't touch the new shiny features the experienced engineers are working on until they get their training wheels off?
Because there is actual demand for ruby on rails despite all the hate and sunsetting of rails I see on HN?
Also, and I'd love to see actual demographics on this but I know it's impossible, while lots of posters on HN/proggit/whatever are professionals, a lot of them are also high school or college students that are still coming at it from a hobbyist perspective (i.e., focused on what's new and exciting rather than engaged in the relatively boring world of getting paid to solve other people's problems). For that matter, a lot of the professionals approach their work from a hobbyist perspective (not necessarily a good thing for their customers).
I don't mean to sound like I'm down on hobbyists or students at all, just that different people care about different things, and just because most HN posters know a lot about the technologies they post about doesn't mean they know or care about the actual state of the industry (just their corner of it)(that applies to me too of course, we're all like the blind men and the elephant).
Big companies use enterprise Java unless they're stuck with a legacy VB/ASP/Coldfusion stack, with C# less commonly.
Fintech companies use a mix of C# and C++.
Small companies started before ~2010 use PHP, with Rails less commonly.
Small companies started after ~2010 use Rails, with hipster Java (Scala/Groovy/et al) less commonly.
I can only remember offhand seeing one job ad for a company using Sinatra instead of Rails for their Ruby stack.
Chicago, the land the MEAN stack skipped.
1. it's easy to get something up and working, which for a lot of students helps keep them motivated 2. Hartl's Ruby On Rails Tutorial. So far, it's the best book/course on how to get from knowing pretty much nothing to being able to work in a 'modern' dev setting (good editor, git, bitbucket, testing, backend, front-end, etc.). 3. if they want to actually get a job as a junior dev somewhere else, I've found that joining a startup or company that uses Rails is pretty easy. Much easier than jumping into a front-end React/Redux shop, for example.
I do not necessarily intend to use Rails actively with them in their first projects, and for those who can and want to I'll probably have to introduce them to the complexity and horrors of front-end javascript development, but at least with the Rails Tutorial they can get started by themselves and learn some degree of 'best practices'.
If you didn't fully embrace tableless design with CSS, despite the latter's glaring defeciencies for that task, it was the same treatment.
I also recall great pressure to adopt EJB with its deeply flawed architecture, etc.
I could go on, but the point is that there seems to come a time when all of these things face a moment of truth, wherein sober minds feel a little freer to speak aloud on their shortcomings. This frequently snowballs into all out backlash against the tech in favor of The Latest Shiny Thing.
The enforcers of what's hip and smart for everyone now move on to browbeating Developer Land with the new tech, and we all allow it to happen again. Why do we keep repeating this process when we've all seen the movie so many times?
[1]https://quoderat.megginson.com/2006/03/06/programming-langua...
QED. My hypothesis was confirmed, up to this point I was pretty sure he's been living under a rock possibly for decades complaining about how hard programming can sometimes be until I realized he is an IE user.
Show us a better solution without sacrificing everything that rails has given us and maybe we will listen.