I'm not going to be able to comment on everything on this article and it is indeed a wonderfully put together resource, but I must say that I tend to disagree with the over-all premise. Yes, if you are a first time or beginner developer Rails can be overwhelming and you will learn a lot more by using a smaller framework such as Sinatra.
On the other-hand if you are undertaking a medium to large scale project (and not a micro-service), you probably want Rails. With Rails you have the benefit of a complete package of libraries that work out of the box and are quite extensively tested. I can almost guarantee everything else will cause you more pains, subjectively, if you really dislike the Rails style, it may be worth it.
I also have a minor quibble with the suggestion that multi-level delegation is a good coding pattern - it is a terrible pattern!
Have you ever tried to find the function you need through 3-4-levels of delegation when everything extends 5-10 different concerns? I'd much rather read - `self.parent_objects.children.function_name` in my code than `function_name` and then spend time searching where the later came from.
Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery.
Also, Rails 5 is not Rails 4 is sure as hell not Rails 2--as the framework has matured, it's gotten less and less accessible to beginning devs, and has developed a jargon and mindset that sheds very little light on how the Web works under the covers and magic.
Starting with Sinatra or similar and building out and up is a much better way to end up with a real understanding of what's going on.
> Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery.
I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.
Totally anecdotal, but the past two startups I worked at used Rails on greenfield projects.
The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result.
The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess.
The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project.
What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.
If you have "self.parent_objects.children.function_nam" in your code base is a demeter violation (which I like to see as yet another code smell rather than a law or rule) that is telling you that you are probably missing a domain model. Mixins don't solve that either but hide the smell from you.
GP is not saying mixins solve that problem, they are saying that it further obfuscates where the method is being delegated to. You have to search all the mixins to see who defines the method you are looking for.
I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
This is largely true for someone who already knows the framework(s), probably less so when you're learning. There's less to do to make "a thing" that works in Flask than in Django. That said, many of the times I've reached for Flask I've realized, eh, it's going to be just as quick and "light" to do this in Django. At the working, production level, I wholly agree with you.
The argument boils down to "more code, more bugs" so large frameworks are less trustworthy than small libraries.
Of course on the other end these popular large frameworks often have a lot more maintainers (sometimes even more maintainers per line of code) than the smaller libraries frequently only maintained by one or two people. And there are of course synergies (yes I'm using that word unironically) when all the code lives in a single ecosystem rather than being based on a unique combination of purpose-built libraries.
Having used both Django and Flask, and various front-end frameworks and libraries, I can see the appeal of both sides of the argument. In the end I haven't found either argument to be bullet-proof though. Everything is always a trade-off.
Occam's razor is misused in the manifesto. The author indicates that it means "Prefer simple solutions", which it doesn't.
Occam's razor requires a hypothesis, and generally means "Among competing hypotheses, the one with the fewest assumptions should be selected".
For example, Special Relativity is exceedingly complex, especially if I try to explain it to you. Ontologically though (in actual fact), it's the "simplest" solution to explain the real world data that the speed of light is fixed regardless of reference frame. I could come up with other theories to explain the data that might be "simpler" in explanation, but they require more and more assumptions to be made about the real world. For example, I could say that the speed of light is fixed because aliens cause all of our testing apparatus to show the same reading. For sure, that's a much simpler explanation than explaining Special Relativity. But it rests on a whole huge number of assumptions (like aliens existing, that the aliens want to mess with us, that they have the capability of doing so, etc, etc). So here Occam's razor favors the more complex theory because it makes fewer assumptions.
So saying that something is better because it's simpler and then justifying it with Occam's razor is really an abuse of the concept.
The author invited comment directly by using a scientific/philosophical principle in his story. If you mention Occam's razor as a reason your argument is correct, and you completely get that wrong, you stand to be corrected.
So if you want to sound smart by using scientific terminology you don't understand, the scientists are going to call you on it, and that's not being pedantic.
This is a pretty poor example since Special Relativity is not 'exceedingly complex' and as a theory that explains things observed in the real world it's drastically simpler than a theory postulating unobserved aliens.
Sorry... I should have been clearer. You're correct, and it is indeed why Occam's razor correctly applied would rule out the alien theory. What I meant specifically, was that its syntax is more complex, but its ontology is simpler as you describe. In other words it's the explaining part that's more complex, so it seems more complex on the surface. So if you asked the average person on the street which theory was easier to understand, I'm guessing most would say the alien theory. So when you use a description like "simpler" as the author did, you can be confused as to what is "simpler".
This confirms my overall feeling when considering Ruby and Rails.
Instead, I choose Python and Flask. The whole Zen of Python really spoke to me and my team members: https://www.python.org/dev/peps/pep-0020/
No magic, just developer clarity. Neither of these items seemed like a primary concern for many different Ruby libraries and Rails itself.
I also suggest trying out data mapper pattern instead of active record. Flask and SQLalchemy are extremely powerful and easy to use. Virtual data fields and all kinds of neat things that really makes working with data easy and customize for complex business requirements.
I didn't like the magic of Rails either, but didn't grok Python :(
I'm much happier using Ruby + Sinatra + Sequel/ROM + dry-rb
I do admit that Rails devs develop considerably faster than me. But I get a feeling the majority of them can't make much more than a single machine monolith. Rails has a way of narrowing many people's technical curiosities. But it probably behooves both sides to learn more about each other.
Excited to see this piece - an ambitious guide to developing with Plain Old Ruby and associated tools!
I ended up disappointed. The piece reads in a very partisan manner, makes questionable declamations of common Ruby tools & patterns, and throws in a lot of obnoxious asides about how bad other programmers are.
Examples: "RoR is a good starting point for a young developer." Its usage encompasses just a tad more than that. "MVC is not an architecture." Just factually untrue.
That said, the lower portions of the guide have some good content and the list items describing popular gems are helpful.
There are a lot of "emotions" and personal opinion that is not wrapped with tolerant euphemisms. I don't have time to explain all POVs in details, also even after reading those books I mention - every person would have his own opinion and conclusions.
I agree with the Manifesto. I've been using Rails professionally for 6+ years and the magic still causes some confusion. The Rails ecosystem provides so much out of the box and so many answered questions on Stack Overflow and Google it would be a constant uphill challenge to go against that flow.
I'm looking forward to moving to Elixir and Phoenix which seems to embrace the less magical, more explicit manifesto while also being the accepted solution in that domain.
If you've been using Rails for 6+ years and aren't at least passingly familiar with the majority of the source code and design decisions, then you aren't a very curious developer
On some work projects I've gotten a lot of mileage out of breaking with the traditional Rails patterns in favor of stuff like `Operation` objects. Too bad I didn't know about Trailblazer!
I also agree about Rails making excessive use of Ruby magic. Just because it's possible, doesn't mean you should do it.
Regarding non-ActiveRecord models, I use Sequel[1] exclusively at work - in addition to being decidedly less magical, it has wonderful support for most Postgresql specific features.
I'll be consulting this in the future before embarking on new Ruby adventures.
I don't have experience with Sequel and rails 5 specifically. The thing is, models are really not very coupled to rails. We don't have to do anything special to use Sequel models - it has good support for Rails migrations and everything.
Regarding authentication, my company makes authorization and access control software, so authentication isn't something we just toss a plugin at.
Yes, you shouldn't do Ruby development on Windows if at all possible. But is there any reason why OS X is not mentioned in the Linux section? It is after all what many Ruby developers use.
Poor phrasing on my part. What I meant is to have an OS section and then discuss Linux and OS X as the two main options or mention OS X as an alternative, if Linux is the OS he intends to promote in the section. He could also mention non-Darwin BSD.
Linux is mentioned because it is a common server OS and Linux knowledge is the most helpful for web dev. OSX do not add any extra value to this aspect of knowledge (despite I do use OSX as desktop OS).
The first few sentences of this article sold me. Because it describes to me exactly why I hate Rails, and Ember, and any other framework with a similar model. I hate Rails because Rails is Magic. And not the good (well, as good as magic can be), 0x5f3759df kind of magic either.
The kind of magic where you're given some functions to call, and some places to put your code, and if you ask why, you are told that you don't want to know, so shut up. In a non-CoC system, a lot of this magic would be exposed to the developer, so even of we didn't exactly know what was going on behind the scenes, we could at least kind of reason about it.
I hate rails because I like to be able to reason about the code that I write, the libraries I use, and what's going on behind the scenes, even if I don't know ALL the details.
Why? Because I assume that at some point, my code will break. And if I can't reason about what my app's doing, I can't fix it. And after running Ubuntu for a few years, I have long run out of patience for problems I can't fix.
> The kind of magic where you're given some functions to call, and some places to put your code, and if you ask why, you are told that you don't want to know, so shut up.
Rails is open-source and extensively documented. I honestly cannot understand this take at all.
Okay, YES, Rails had docs, but that's the attitude I see: use this, do this, put your code here, we know best. The docs do not ENCOURAGE understanding of how Rails works, or why it is the way it is.
The documentation for getting a blog built in 15 minutes doesn't explain why you put your code in each place or how it's put together, because that's not the point. Rails is about making default decisions for commonly bikeshedded questions like "how do we name our database tables" so you don't waste mental bandwidth on them when you're trying to build an application. But explanations for how and why all that happens is very readily available.
Read the code, then. The docs are for people who want to get stuff up and running. The code itself is what you should read when you want to understand how anything really works.
I shouldn't have to read the code to be able to basically reason about what my app is doing. I don't necessarily want to know EVERYTHING, but I want to know the basics of what's going on.
There is no magic in Rails if you at least give some effort to understand how things work.
But everyone is free to invent their own incomplete and flawed versions which has benefit that you know the magic behind your framework. Alas, no one else does.
Yes, they do. And the difference is that it takes FAR more work to understand what Rails is doing than, say, Flask. Part of it is that Rails hides things from you. Part of it is that Rails is simply more complex. all of it makes it harder to reason about Rails.
I'm currently researching JS frameworks/libraries to front a Ruby web app. Interesting to see vue.js in the author's ideal stack. I'm very intrigued by re-frame (React based, in ClojureScript, inspired by Elm architecture). The Readme is fantastic: https://github.com/Day8/re-frame.
Great effort. There's still a lot to go but you've got some great content already. I just wanted to mention gitbook.com as a resource to you. Keep it up.
Thank you. I think about writing a script to convert Jekyll MD files info https://leanpub.com/ book format to have it compiled in ebook format (+ distribution platform).
Independently from people preference in working with this or the Rails approach, what is nice noticing is how the Ruby community is putting a lot of effort in creating alternatives to Rails.
One of the keys to cheerfulness is valuing your own experience and in seeing the world as it is, faults and all.
My experience has been that a lot of stuff in the Ruby/Rails (and the Node ecosystem, a thousand times worse) ecosystem is due to well-meaning novices cranking out ever-so-slightly different iterations on the same ideas, cluttering up the package managers with not-quite-right solutions.
That, and a pervasive attitude of convention-over-configuration and self-aggrandizing that tends to place an emphasis on popularity over talent, and on talent over restraint.
I remain cheerful because that culture hasn't yet infected the Elixir community.
Try to use Trailblazer. Even if you would not adopt it entirely - it is really a great way to broaden your perspective.
An Editor is solely personal taste.
I have only a fleeting familiarity with Hanami and Trailblazer. It struck me that they are both achieving very similar ends. I preferred Hanami in that it retained very discoverable mechanics for people comfortable with recent low-level trends in webdev (e.g., Interactors are simply Service Objects) while Trailblazer seems to have its own heavily engineered high-level paradigms (e.g., Cells) that seemed more suited to the Rails way of thinking (geminize all the things!). Any paradigms/approaches that Trailblazer advocates that you prefer over Hanami?
Yes, they really have similar parts (mostly Operation and Action). But Hanami is a framework and Trbr is a architectural layer, that could be used inside any framework. In Trbr I really like the idea of Representable to convert objects. Trbr is more tailored for Raiks, to allow step by step improvement of existing Rails apps. Maybe it is not so important for Hanami, but with Sinatra it will still help a lot.
On the other-hand if you are undertaking a medium to large scale project (and not a micro-service), you probably want Rails. With Rails you have the benefit of a complete package of libraries that work out of the box and are quite extensively tested. I can almost guarantee everything else will cause you more pains, subjectively, if you really dislike the Rails style, it may be worth it.
I also have a minor quibble with the suggestion that multi-level delegation is a good coding pattern - it is a terrible pattern! Have you ever tried to find the function you need through 3-4-levels of delegation when everything extends 5-10 different concerns? I'd much rather read - `self.parent_objects.children.function_name` in my code than `function_name` and then spend time searching where the later came from.