
Ruby Web Dev The Other Way - guifortaine
http://rwdtow.stdout.in/
======
forgotpwtomain
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.

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

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

------
crazydoggers
begin minor rant...

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.

... end rant

~~~
throwaway5431
Well, actually...

[http://tirania.org/blog/archive/2011/Feb-17.html](http://tirania.org/blog/archive/2011/Feb-17.html)

~~~
crazydoggers
Lol... maybe you're not.

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.

------
cdnsteve
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/](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.

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

~~~
rimantas

      > Rails has a way of narrowing many people's technical
      > curiosities.
    

That's, let's say, very odd statement. Especially keeping in mind how many
frameworks in other languages were inspired by RoR.

~~~
duai
Well, yeah. People move to other languages and then build a RoR-inspired
framework, instead of trying other alternatives.

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

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

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

~~~
wyaeld
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

------
onetwotree
Good work!

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.

[1] [http://sequel.jeremyevans.net/](http://sequel.jeremyevans.net/)

~~~
andrei_says_
Do you have experience of using sequel with rails 5?

Also, what do you use for authentication?

~~~
JonnieCache
There's a plugin for Sequel::Model that provides ActiveModel compatibility,
which should make it work with the usual rails gems.

[http://sequel.jeremyevans.net/rdoc-
plugins/classes/Sequel/Pl...](http://sequel.jeremyevans.net/rdoc-
plugins/classes/Sequel/Plugins/ActiveModel.html)

Sequel is my favourite of the tools I use.

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

~~~
thrkw123456789
Because osx in not linux? (Although it does bundle some out of date gnu
tools.) A separate osx section would seem more appropriate.

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

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

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

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

~~~
jdminhbg
There are plenty of docs (official and unofficial) explaining the internals of
how and why Rails works; here's an example:
[http://guides.rubyonrails.org/initialization.html](http://guides.rubyonrails.org/initialization.html)

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.

~~~
qwertyuiop924
Fair 'nuff. Sorry.

------
andrew_wc_brown
I don't know whats wrong with vanilla rails. The most I have to do to organize
large projects is used concerns.

For better performance I serve up json directly from Postgres.

All these additional abstractions makes it hard to migrate away later to
another platform.

------
jhund
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](https://github.com/Day8/re-frame).

------
whatnotests
"I dislike the complexity of Rails and wish to make my own way of things."

..three years later...

"We are upgrading to Rails."

------
ben_jones
Let's be real RoR is not about learning, or perfect engineering, or being easy
to learn. It is 100% about being productive in industry.

"Put this file in this folder with this name and your app will do x".

"Why?"

"Because 10 years ago this file structure made a lot more sense and some
people liked it so we stuck with it".

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

~~~
iJackUA
Thank you. I think about writing a script to convert Jekyll MD files info
[https://leanpub.com/](https://leanpub.com/) book format to have it compiled
in ebook format (+ distribution platform).

------
breakingcustom
Obligatory phoenix/elixir mention

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

------
sergiotapia
Bird's eye view, what is Hanami's performance like compared to Rails?

------
desireco42
I really love and understand a lot of choices here. I didn't realize that
mindshare behind Hanami/Trailblazer is so big, this is excellent news.

I am a little confused on editor suggestion, but this is geared to starting
devs. I would say SublimeText all the way. Next step, obviously Vim.

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

~~~
soumyaray
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?

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

