This is also my only complaint with Rails.
I'm a programmer, not a wizard, and I'm not good at magic.
After using Rails every day for 12 years I know pretty much all the ins and outs, and what is "magic" to others is just the robust tooling I love. Just like any tools, they are overwhelming and daunting when you don't know how to use them, but once you become proficient with them, they make your life so much easier. While it might be difficult when the "magic" doesn't do exactly what you want for your edge case, when you have a sufficient level of mastery, it's easy to find a way to adapt/modify/override the tooling and make it do what you want. Further, many times the tooling is there to keep you from doing things you probably should not be doing, and this kind of strict, opinionated, best practice enforcing philosophy has gotten me out of trouble at times, and I think it makes it much easier for engineers to move between Rails codebases and start being productive even faster.
I've done plenty of Node/JS/React and I honestly do not understand how people can prefer to use these stacks over Rails. For full stack web dev, Rails is such a pleasant place to work every day.
Rails is 17 years old.
We are surrounded by magic (which only means things we can not realistically be bothered to take the time to really understand, in contrast to things which are incomprehensible). I have no real clue why the terminal works. I have no real clue why my OS works. I have no real idea how TCP/IP does its thing. Sure, I can use them – but I couldn't really explain and much less recreate them.
What I need in all the above is replicability. I do x, and I know y is going to happen. Get x, do y. This is true in Rails.
If I really wanna know more Rails is open and easily explorable. No one is preventing me from finding out how any piece of the "magic" works.
"Magic" class inheritance is a thing in JS as much as it is in Rails.
What is so special about Rails and "magic"?
I'll state my case as clearly as possible: The magic in Rails REQUIRES memorization... freaking everywhere. And it provides virtually no hints to jog your memory.
There's just too much tooling, hidden away out of sight, and applied through shenanigans with Ruby that other languages/frameworks make MUCH more obvious.
Simple trivial example? Rails fucks with imports left and right. Rails allows you to not even write a require statement half the time - it's just going to load things from places. Hope you have that list memorized.
Does it save you some time? Yes.
Does it make the code look "Cleaner"? Sure.
Does it make my life a fucking chore every time I have to run a damn console to find the source location of an object at runtime because it's entirely unintuitive about where it freaking came from? Damn right it does.
---
If you started early in your career with Rails - you probably don't notice this. But if you have experience with a solid selection of languages (ex professionally I've used: GoLang, C, C++, JS/Typescript, C#, Java, Netlogo, Rust & Ruby) I find the discoverability in Ruby/Rails about the lowest on the list.
Very fast to work with if you happen to have it all memorized. But that's about the only compliment I can give it.
What's interesting to me about this comment is that among the languages I'm familiar with that you list, the difference between the best discoverability and the worst feels way larger than the difference between the worst one and Ruby. To me, C is barely any better than Ruby; sure, Ruby lets you define methods/types at runtime, but C doesn't even _have_ methods, making finding all the things you can do with a given type way worse in my opinion. Plus, you can still have some wonky generated stuff with macros, although I'll concede that's usually less common than Ruby metaprogramming. Java, C++, and Go are a bit better, since you get a namespace instead of just a random identifier without context, but these namespaces are generally split across multiple files, so in practice I would need to rely on tooling to do this for me, and at least with RubyMine this wasn't in practice _that_ much worse.
Ex: C doesn't have methods, but if you store most of your data in structs then you can easily do two things:
1) find all the places where the header defining that struct is included
2) Do a global search for the struct name
Both will present you with a nice list of places that data is used, and show the functions that accept it as an argument.
Where as with Ruby - I basically have to use RubyMine to get anything even sort of working, and even then it chugs along very slowly trying to do it. Solargraph in VSCode doesn't really work at all (at least 50% of the time it finds no definition for me) and just using a basic editor is a nightmare. Sometimes you can do a global find for "def [classname]" but that only gives you the definition, not any of the places that use/modify it.
Basically - Ruby is one of the few languages where I feel like global search just doesn't work well, and it also eschews import/require/include statements when used in Rails. It's just a tangled mess, and there's NO way to unwind it without tooling, and even the tooling struggles (RubyMine is a guaranteed way to get my fans running at full speed for large projects, and it's the best I've used).
In my book it's a write-only coding environment like everyone used to complain about with Perl and PHP. People crank that stuff out really fast and move on and leave future generations to suffer. But they love it, of course.
Because to me - RoR is in the death spiral period that the original ASP.Net was in before Microsoft threw the whole thing out and started over with the Core version.
Namely: Rails trys to give you opinionated best defaults, but the "best defaults" have changed dramatically since the framework came into existence. So you end up with 6 very different set of opinions as the framework has evolved, and the documentation is poor (honestly, at least ASP.net had okish docs - I find Rails docs pretty damn bad) and you get a complete wash on 3rd party sites trying to find relevant info for the version you happen to be using.
Also - Unlike MS and ASP, Rails doesn't even fucking try to keep naming consistent. They seem to favor making the syntax as close to natural language as possible, often deprecating the old syntax in favor of new method names solely "because it reads better". Which drives me freaking nuts.
Inertia will keep it running for a long time, but it's not the thing I would pick for greenfield projects anymore.
1.
These are fair criticisms. These kinds of problems can also be difficult to demonstrate to others who may help.
For example "some function `f(x)` gives 5 when it should give 7" will get an answer in 5 minutes on stack overflow, whereas "my thing's not working and I don't know why" will receive 4 downvotes and no answer in the same time.
2.
I tend to be the kind of learner who doesn't sit down for 30 days and read the docs cover to cover, but rather I start using the new tool on day 1 and figure out what I need to know as a I go. But rails rewards the former approach (i.e. reading through the rails guides - or even just skimming them). This may take a few weeks, but it gives the ability to at least know where to start to look if something has gone wrong.
3.
> And it provides virtually no hints to jog your memory.
I kinda agree. I feel like this should be easily addressed (although I'm not totally sure how).
In Typescript, entities have types and when you misuse something the typescript checker tells you while you're coding why, that's not what you're supposed to do. You can super easily track down the type and navigate the code base to the source and adapt either your code or edit the source. Easily. With rails, you're often required to do mental gymnastics to debug simple things, after the fact
It really isn't that common just like it isn't that common to do it in JS or in Python. Some people used to do that shit a decade ago, it became frowned upon and I don't really see it anymore.
I 110% agree with you.
This is Rails striking again!
"Don't look at the magic, just memorize it." might as well be Rails' slogan.
Convention over configuration really just means "Memorize all my conventions, and don't ask why I picked them".
Great for the case where your use-case is in line with the chosen conventions and you don't want to think all that hard (or you just need to pump out content - like a contract agency). Pretty terrible for just about everything else.
0. https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...
You can go from nothing to mostly full-fledged promises in about 200 lines of code: ex - https://www.promisejs.org/implementing/
async/await is pure sugar on top of promises (it's literally just wrapping the rest of the function in a .then() for you, and coercing the return value of your function to always be a promise)
Not to mention that part of the issue with Promises is the various polyfills invented before broad acceptance, which is a separate can of worms, and a different type of complexity than the (relatively) heavy use of metaprogramming in Ruby (relative to JS).
You just see these functions and there is no require in the file to tell you where they come from. Rails just loads that shit from somewhere. It could be from a mixin, it could be from one of the 50 classes in your hierarchy, who the hell knows. You press jump to definition and rubymine just fucking chokes and gives you like 30 different method definitions with the same name in different places.
I don't know how much blame to put on Rails, Ruby, or the teams I worked on, but in the end it was very frustrating.
Aside from that I like Ruby a lot, and Rails only a bit less. But it's a big aside :)
class Foo; puts "foo.rb was parsed"; end
is a simple example of nothing is really special.
In express there are packages for those things, ie https://www.npmjs.com/package/express-session. Agree it would have been nice as part of the express library.
That is a great question. Is it the job of the tooling to prevent a novice developer from shooting themselves in their foot? Do we need higher-level abstractions in our frameworks that are analogous to memory safety in programming languages? Perhaps.
Alternatively, I don't think that security practices are particularly hidden. Anyone who's used the web knows has used a login form. I would give most novice developers the benefit of the doubt that they're going to be curious and look into that.
I would argue that it is, in part, their responsibility to learn these things. It's our responsibility perhaps as stewards of the secure web to teach and enforce best practices. I don't think baking in these best practices into frameworks does these developers any favors, except that it allows them to focus on something else.
TypeScript to me is the compromise I'm willing to settle on. It is also lackluster from many aspects but day by day it gets a bit easier.
Im a noob starting a project in Spring and I get lost in the jargon. I find that all the Spring knowledge I’ve gathered is to know what is NOT written in the code that Spring is doing for me.
In other words, feels like knowing Spring is being able to read between the lines and placing annotations more than building with it. Which is fine, but it’s easy to get lost when starting out.
It’s also for me to find help since the community seems much smaller and none of my friends are interested in helping out because they don’t want to learn Spring.
I've found the official documentation to be very detailed, so it's helpful if you really need in-depth knowledge, but if you don't it's a bit hard to parse out the relevant bits. Copying something from the official guides seems often the easiest way...
In regards to the community, I didn't find it to be much smaller? The stack overflow tag is very active. I have the same experience that nobody I know wants to learn Spring out of their own volition though.
Types can be checked with mypy: http://www.mypy-lang.org/
For Django, there are these two typing packages:
- https://pypi.org/project/django-stubs
- https://pypi.org/project/django-types
I can't vouch for them, but it looks like they're being actively developed.
I like the idea of full-stack JavaScript (or TypeScript), but last time I tried to use Node for a back end, I couldn't find anything that compared to libraries/frameworks like Django, Rails, SQLAlchemy, etc.
The lack of good documentation is painful and often treats me like I don't already know the concepts involve.
Sequelize isn't as intuitive as Django's ORM either imo.
Turned out to be painfully slow to iterate. The ORM needs constant attention to join or prefetch queries.
Switched to Prisma and it's an utter joy. If the typescript has no errors then there won't be runtime errors.
Sequelize is a multi generational mess. It's a huge time waster.
Could you elaborate on that ?
I personally like the functional aspect of sequelize.
Working with Prisma: if it compiles (and you don't have a business logic error), then you usually won't get any runtime sql errors.
You don't have type safety with sequelize.
I had to write my own types around the existing ones to get getters and setters to work.
I haven’t checked out Prisma. Thanks for the tip.
Prisma has a great API for this, and it's easy to tune. By default is prefetches and selects related even several levels of joins deep.
Let me assure you, there is 0 magic in Rails. Just because something is available to you via a convention doesn't mean there's magic, it means you haven't read the docs and don't understand the convention.
There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.
Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.
This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.
Other Ruby "features" that I dislike:
1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
3. Out of bounds indexes on Arrays/Maps return nil.
4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.
Well, Ruby has functions, they're just called Procs. Lambdas are a special, more strict breed of Procs, and blocks are just (pretty complex) syntax sugar for passing a Proc to a method. The main function-like concept is always a Proc.
> Out of bounds indexes on Arrays/Maps return nil.
Calling the #[] or #slice method on an Array with an out-of bound index returns nil, calling the #fetch method raises an IndexError or returns an arbitrary default value. You can use whichever suits the situation.
However the reason I don't use Rails as much is that I'm not writing a lot of "full-stack" apps. A lot of the work these days is gluing together various SaaS services. Okta/Firebase for Auth, Contentful for CMS, Stripe + Webhooks for Commerce etc. I just don't do anywhere near as much "CRUD" style programming as I used to do earlier in my career, which is both a comment on my career and the state of programming today.
I'd love to see a project that wraps up a bunch of best-of-breed technologies and creates a full framework and doesn't try to be all things to all people. ie React for Front-End, Bookshelf ORM, Express Server etc (pick your favorites, but have an opinion that evolves but only in one direction.
Rails is nice in terms of getting the project set up, not bikeshedding about the tooling, and working with the db. But the actual coding has been painful for me. I really dislike working with a non typed language. I dislike optional parans in function calls and optional braces for hashes. I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base. I would rather write a bit more code for a bit more clarity. Maybe if python were typed I would like Django? But python has all of that nonsense around virtualenv.
Spring has been ok, but not great. Too much bloated abstract factory creator nonsense. Dependency injection never really clicked for me. All of these annotations. I quite liked plain Java but Spring just felt like this monster.
All in all node(express) has been the nicest for me.