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.
Ruby Web Dev The Other Way
41–50 of 65 posts
Re: Ruby Web Dev The Other Way
#42Earlier quoted context omitted.
> 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.
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
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.
Re: Ruby Web Dev The Other Way
#43Obligatory phoenix/elixir mention
Re: Ruby Web Dev The Other Way
#44The mention and link to Elixir scares me. Please, don't bring your ghetto over here. Keep your unwashed masses to yourself.
Please don't do the programming language flamewar thing on HN.
Re: Ruby Web Dev The Other Way
#45Earlier quoted context omitted.
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.
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 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 "h…
Fair 'nuff. Sorry.
Re: Ruby Web Dev The Other Way
#46Earlier quoted context omitted.
> 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.
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.
Re: Ruby Web Dev The Other Way
#47Earlier quoted context omitted.
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 th…
> 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 prev…
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.
Re: Ruby Web Dev The Other Way
#48This 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. F…
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.
Re: Ruby Web Dev The Other Way
#49I'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…
Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.
Re: Ruby Web Dev The Other Way
#50I 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.
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?