Earlier quoted context omitted.
There isn't much black magic. Most of it is pretty sane naming conventions which could be OK in any sw project, plus database schema autodiscovery. The bonus is increased maintainability.
> The bonus is increased maintainability. It will never have strong-typed discipline though... (sad)
DHH answers: What makes Rails a framework worth learning in 2017?
121–130 of 135 posts
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#122Earlier quoted context omitted.
This. Often, you can't find where this variable or function comes from. You read the sources only to discover that there is no trace of this variable and it is probably defined dynamically in some callback. You can only find this kind of stuff with the help of debugger. The dynamism, which allows one to create beautiful interfaces, and is often advertised as a programmer's friend, is actually the enemy of the program…
I've actually run into methods defined from names concatenated from multiple strings, i.e. methods you can't even use grep over the whole codebase to find. This has left me with a lingering vague fear ever since.
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#123Earlier quoted context omitted.
> Translation: "If you don't like it, fuck off." If you like, but that's not what I'm saying. What I'm saying is instead that you're not going to find value in Node the same way you do in Rails, and complaining that Node is not Rails will not change that in the slightest. Neither will approaching Node as though the first thing to do is make sure your project tree contains every piece of functionality your app might e…
I'm not complaining that Node isn't Ruby, or that Express isn't Rails. What I'm saying is that there's an opportunity in the Node space to create something as fast, friendly, and forgiving as Rails is. The "translation" there is how comments like that are perceived. "Put up or shut up" is not a good way to build community. Yes, obviously we have options, but the amount of commitment it takes to go with some of them i…
But, in general, "friendly, fast, and forgiving" is exactly how I've always found the Node/Express tooling and ecosystem to be, while Rails has been among the least welcoming stacks I've ever had the displeasure to use - and, to your point about having to commit, in deciding "Rails: never again" I essentially threw away most of a year's worth of professional experience, which was so Rails-specific as to offer nothing useful in any alternate context. That's a choice I'm glad I made, rather than chasing the sunk cost, but if we're going to talk about things that require a lot of commitment, I think we have to talk about that kind of thing, too.
Based on the apparently almost mirror-opposite nature of our experiences with these platforms, I'm inclined to wonder whether the characteristics of either are strongly to blame, or whether instead it's a question of preference, or congruence between personal style and that of the platform, or just good vs. bad first impressions.
Not least to that last point, I do agree that a more reliably findable onboarding experience might be warranted. But it does sort of come down to "put up or shut up", harsh as that may sound; again, without a BDFL or a One Right Way, there is no one to mandate such a thing must be done, and thus, until someone comes along with the knowledge and the passion to do it, that thing does not get done. There's some degree of cost in that, to be sure. But the difference in engagement makes it reasonable to ask whether it's as much of a problem as it might seem.
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#124Earlier quoted context omitted.
> I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again. I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support. > Every week the developers want to switch out some module for another module…
Until a new point release comes out and everyone forgets about the one you're running. Then you get to find out how much of your code you'll need to rewrite so it'll run with the Rails chefs' wild new menu. And there's no point even trying with an app written for an earlier major version. Just give up now, because the whole ocean's been boiled and recondensed since then, and now occupies but few of the basins it once…
This is definitely a pain you'll feel with rails, and any other combination of software pieces which you bring together.
For what it's worth, within the last month, I've touched rails 3.2, 4.0, 4.1, 5.0, and 5.0.1 apps which are running in production. It's possible to maintain these apps on old releases, but the idea of never upgrading will be painful in the end.
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#125Maybe a more relevant question is whether Rails is worth learning if you're looking for a job. Searching Indeed.com's API by title, which removes duplicates, there are currently 133 Rails jobs in the USA compared with 763 PHP (excl. WP, Drupal etc.) and 467 Node.js. In the UK there are 104 Rails jobs compared with 1013 PHP (excl. WP, Drupal etc.) and 230 Node.js. However, if you deleve deeper it turns out that half o…
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#126Earlier quoted context omitted.
Ok, I see your point. I, too, hate writing boilerplate code. But I did three things to resolve this: I built a `config.js` file, which contains the paths to resource files in a more compact format, and is sourced into the gulpfile. I then replaced long path strings with easier to read code. I also threw my standard gulpfile into a git repo, so if I need it, it's there. Lastly, I built a yeoman generator. Now, not onl…
Tools like Yeoman can help here, but they're also relatively obscure and there's a lot of yak shaving involved in getting them working correctly. In a sense complaining about this the Node world is like asking fish how they can stand being wet all the time. It's just part of the terrain. I'm not saying what Node is doing is fundamentally wrong, but that this almost absurd aversion to making decisions for users is som…
In the end it boils down to: Start with a monolith and chisel away the stuff you don't want - RoR, or start with a skeleton and add what you need as you need it.
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#127Earlier quoted context omitted.
What's wrong with conventions? It seems to me that code conventions would make code more maintainable.
newsat13 wasn't complaining about using conventions. newsat13 was complaining about how Rails uses black magic with conventions. I can't speak to Rails, but I've worked in other codebases that used reflection to dynamically attach different pieces of code together. It was hard to trace code because I couldn't do a search for the value being generated nor could I use the static analysis to find the value. I had to man…
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#128Earlier quoted context omitted.
I've actually run into methods defined from names concatenated from multiple strings, i.e. methods you can't even use grep over the whole codebase to find. This has left me with a lingering vague fear ever since.
I've seen worse. A system that would load chunks of code out of MySQL and eval them in place. Magic variables with magic meanings... shudder
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#129The only thing I'd really take much issue with is the "provides great defaults" statement made in passing. There are several things that are defaulted more to what I'd call "lowest common denominator" than "great." For example, sessions.
This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"
I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better".
The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is deliberate and the benefits of what I'm missing out on are truly, honestly irrelevant. There's really very few times where I said to myself, "Oh of only my templating language had better support for these idioms". I just write a decent workaround because I've been using the same tool for years and it's maintainable and the total number of workarounds is so small that there are no good reasons to switch to an alternative even in the long term.
This is much better than the alternative of looking for 5 alternatives for the same component, discarding the first 3, using one for a month until I find it has fatal flaws, and finally settling for the last one.
Re: DHH answers: What makes Rails a framework worth learning in 2017?
#130Earlier quoted context omitted.
This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"
But a collection of consistently good enough components is better than tying together two dozen different things of wildly different quality and conventions. I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better". The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is de…
Frameworks aggregate many dependencies. Managing the dependencies that deliver value while ignoring those that are irrelevant can net out as more productive.