Comment on What software stack would you have chosen for Lemmy?

• foo@withachanceof.com ⁨1⁩ ⁨year⁩ ago

  To each their own. I don’t fanboy frameworks, they all have their pros and cons. What you specialize in for a personal professional career is different from what you may choose for a free software project though. Plus, I’d argue there’s definitely downsides to the JS ecosystem as well but also frameworks you know should not dictate your career prospects. I get this all the time in interviews and career development talks. If you consider yourself a web developer getting up to speed with a new stack or framework shouldn’t be an insurmountable task. The nature of web development is that it’s constantly changing. Feeling stuck with Rails vs. Django vs. React or whatever else means your skills are not keeping up with the market; it’s not a fault of the framework. The only constant in this line of work is change.

  That said, Rails isn’t going anywhere. JS frameworks are the hot thing (for whatever reason, I despise them for all sorts of reasons, but that’s not the point) for many new companies/projects, but there are very large companies whose products are built on Rails: Shopify, GitHub, GitLab, Zendesk, etc.

  There’s too much radical changes. First from sprockets to webpacker and then import-maps and propshaft. And then the in-built Hotwire is so hard to grasp.

  Would this not be viewed as adapting and keeping up with the trends? Webpack is terrible, but that’s what the JS world went with so Rails adopted it. Now there’s ESbuild, import-maps, and Hotwire. Rails supports all of them (import-maps, by the way, is a web standard, not a Rails specific thing… and I love using it). You don’t need to use them and can pick which works best for your product/project. That’s a benefit in my opinion.

  I also used my Rails knowledge to contribute to GitLab because I was misinformed that open source contribution would increase my prospective of getting hired. I contributed for around six months, got rejected multiple times, and then stopped all contributions to GitLab.

  GitLab certainly has that reputation. I don’t see how that’s a knock against Rails though. Shitty companies will be shitty companies regardless of what stack they use. Personally, I never contribute any code to projects that have a commercial organization behind them. If it’s not GPL licensed (or similar) you’re probably getting screwed by spending your time working on it.

  source

  • AureumTempus@lemmy.world ⁨1⁩ ⁨year⁩ ago

    [deleted]

    source

    • foo@withachanceof.com ⁨1⁩ ⁨year⁩ ago

      Yeah I’m not sold on Hotwire either. I started a new Rails project last year with Rails 7 and removed all of the Turbo/Hotwire stuff and did it all with import-maps and vanilla JS. Import-maps don’t require a third party CDN though. I absolutely love that I can use them to write ES6 JS and have it served directly to the frontend without any Webpack/ESbuild compilation step in between. After a decade of working with the nightmare that was Webpack & Webpacker in Rails I’m totally with you on how that whole asset management system needed a big overhaul and I think with importmaps or esbuild we might finally have something tolerable.

      source
• railsdev@programming.dev ⁨1⁩ ⁨year⁩ ago

  Rails definitely has its downsides but your experience in the job market is strange to me.

  Ruby on Rails developers these days are in short supply. During the pandemic I secured two jobs (first one sucked) in Ruby on Rails developer positions. Back in 2017 I took a coding bootcamp for Django/Python but when I saw how little those jobs paid I stayed with Rails.

  There are a lot of hectic changes but thank God for those. If it were the same as it was 15 years ago there wouldn’t be a chance anyone would use it. The hype crowd got scared off in the early days but modern Ruby is pure bliss to work with.

  source

  • AureumTempus@lemmy.world ⁨1⁩ ⁨year⁩ ago

    [deleted]

    source

    • railsdev@programming.dev ⁨1⁩ ⁨year⁩ ago

      I feel your pain. Before landing where I am now I was tasked with bringing a Rails 3.22 app up to Rails 7.

      There seems to be a lot of bad design decisions in the earlier versions of Rails — for the most part I’m referring to the users of Rails (developers) rather than developers of Rails itself.

      Ruby’s downfall is that unless you’re an experienced developer it’s pretty easy to get by with poor design decisions. I’m literally explaining myself: I’m self-taught but I didn’t start coding professionally until about 4-5 years ago. I run a small business on the side that’s powered by my very own old code without tests, huge models, and cringeworthy blocks of code.

      What I think you’ll find is that it’s mostly senior positions open. A lot of companies wrote something quick back when Rails was the hot new tech, let it go for a decade and then started screaming “help!” at the job market when things started breaking.

      source