5 ms·
Currently working for a company that has all of it's websites in Drupal, so my team is versed in PHP. I've been working with Drupal for 7 straight years. I ha
by Jgrubb 11y ago
Currently working for a company that has all of it's websites in Drupal, so my team is versed in PHP. I've been working with Drupal for 7 straight years.
I have this dream of not having to work with Drupal ever again, so I often daydream about what I'd build if I were given the chance. In a sense I'm in the same position as you, except that it's probably never going to happen and that I've been thinking about this for years.
I'd go Rails, and here's why.
Rails is easy to learn - even if your team has never written Ruby it's an easy language to pick up with way fewer gotchas than either PHP or JS. I've evaluated Laravel, and it's probably the best PHP option out there right now, but knowing Rails, I often find myself hating how much code you have to write to accomplish the same thing in Laravel just by virtue of it being PHP. The resulting code feels clunky (though, that's surely just because I also suck at programming).
Rails is extremely mature - it's been around for over a decade. The upgrade from 2 to 3 was painful, the upgrade from 3 to 4 was much less so. I imagine the upgrade from 4 to 5 will be as well, and so on. The ecosystem is very filled out, the package mgmt story is there, the testing story is there. These are new developments on the wider PHP scene that will probably takes several more years to reach the level of adoption and familiarity that Ruby enjoys. I love writing JS, but the whole ecosystem over there is in this constant state of tectonic upheaval right down to the language (ES6), and unlearning the old gotchas so I can learn the new ones doesn't appeal to me right now.
Rails is exceptionally well documented in terms of blog posts, the Rails Guides, and the API docs. None of these other technologies even come close. This is especially true of Laravel, and I've only ever read 1 blog post about Phoenix, so good luck with that.
This was supposed to be short, sorry.
- berkes 11y ago> so I often daydream about what I'd build if I were given the chance. In a sense I'm in the same position as you, except that it's probably never going to happen and that I've been thinking about this for years. This was me, until three years ago. I am freelancer, all my gigs, clients and my whole network was about Drupal. Hell, I still receive requests for Drupal work on a weekly basis: my name was established, so almost impossible to move out of Drupal. So I wrote some op-eds on why Drupal was not always a good choice for projects (most notably: government projects) citing from my experience as rescue-consultant-for-failing-drupal-projects. And then I wrote http://berk.es/2012/10/01/farewell-drupal/ http://berk.es/2012/10/01/farewell-drupal/ and declined all work Drupal related. It does not have to be Rails. It could be Opal, Django, Spring, Symphony, Yii, anything. But if you are really unhappy with Drupal, as you seem to be, cut the ties. There's more then enough work out there. And working in an environment that is built for developers (instead of building a webapp by clicking checkboxes and clumsy html interfaces in the Drupal backend). Move to a community that encourages clean code, "craftmanship", designs, patterns and so on, you will become a better programmer. If that is what you want. I'm now a happy Rails developer. Who learns new things every day. I like my job a lot; so much, that I can't imagine not coding for work (And already I am almost always that Old Guy on the job). In ten years it'll probably not be Rails anymore, but WhateverFancyFramework is the default then. And because within Rails I really learned coding, picking up new languages, frameworks and whatnots is not that hard at all, anymore.
- Jgrubb 11y agoDude, you and me bump into each other all over the place. I just tweeted you a couple days ago about the Drupal Assoc job board. Used to run into you on r/drupal agreeing on how there will be no Drupal 9, etc. I mostly just do everything else in the org - infrastructure, architecture, mgmt, etc - and let the other guys actually do the Drupaling. Drupal is a minimal part of what I do day to day now, so it's not as if I hate my job. Quite the contrary. And I'm constantly learning new things and getting better as a dev, not just a Drupal dev. And the only one of my "really big ideas" that has yet to be implemented is the one where we build a custom (Rails) CMS and get out of Drupal/Features hell for good. And my boss doesn't even hate on the idea, it's just not the front burner item yet. The time will come, oh yes. It will... Good bumping into you again.
- badri 11y ago> Move to a community that encourages clean code, "craftmanship", designs, patterns and so on, you will become a better programmer. If that is what you want. Hopefully, Drupal 8 is going to bring all those fun parts again.
- KurtMueller 11y agoI hear a lot of grumblings from my fellow coworkers that the drupal 8 release is taking a long, long time.
- Jgrubb 11y agoHopefully so, but it seems like a very large gamble to take to basically invalidate the entire community's knowledge base on how to write code for Drupal. On the one hand, if there's not a large market uptake of Drupal 8, there won't be any reason for community devs to learn all the new ins and outs when they could just learn the ins and outs of something smaller and simpler. On the other hand, if there's not a decent D8 developer pool for companies to hire from then I don't know how there could be a large market uptake...
- berkes 11y ago> Hopefully, Drupal 8 is going to bring all those fun parts again. I'm not all that deep in Drupal anymore, but from what I hear: I doubt it. Drupal has to choose a target audience and focus on that. If they choose "developers", then it will become a great tool that is fun to develop in, no doubt. But as long as it remains in a limbo between "end-users" (the one's browsing the site you are building), "webmasters/editors" (those managing the content and configuring tidbits) and "developers" this won't happen. There are just too many conflicting interests there. Real use case: can a webmaster change some settings in the image-cache? certainly not! Changing the width of an image will break all your carefully crafted CSS grids: it is tightly coupled to the Theme (which lives in Git and goes through a release-cycle). If Drupal chose "developers", a thing like "imagecache" won't even exist in its current set-up. It won't have a database to store its settings, nor a web-interface. Instead it would be an Image class that you can inherit and then define some settings and methods in order to get an image-derivative. From what I've seen, Drupal 8 does not change this conceptual basis. So I highly doubt it is possible to develop sites when your basis is conflicting with what you want to do on such a crucial level.