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.

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.

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.

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.

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 didn't yet you did? You've said the same thing twice here

https://en.wikipedia.org/wiki/Data_mapper_pattern

https://en.wikipedia.org/wiki/Active_record_pattern

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.

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.

>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.

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.

"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.

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 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.

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.

If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.

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.

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.

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.

> 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.

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 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.

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.

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.

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.

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.

And I have WINE to thank for that layer of compatibility.

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.

http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 …

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.

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.

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.

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.

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.

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(","))

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.

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.

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.

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.

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...

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.

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.

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?

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. =)

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.

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).

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.

http://zverovich.net/2016/05/13/giving-up-on-julia.html

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])"

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.

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/

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.

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.

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 ;-)

I feel like people really forget what it's like to be a beginner when they say "read the source".

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.

(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.

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.