Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

web.archive.org

Post reply on HN
Print view View original

81–90 of 132 posts

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#81

Post by whatever1 »

VWWHFSfQ wrote: post #58
stevebmark wrote: post #46

> Later in the year, Rails retired Webpacker Is Rails anti Typescript? It’s weird to see most other JS environments move to Typescript by default, while Rails now now ignores the ability to use it without jumping through hoops.

Depending on what your app is, I've found server-side rendering to be superior in nearly every way. I don't use Rails but Django is the same way. Django templates, bootstrap, jQuery and sprinkle in a little bit of HTMX here and there and my productivity has never been higher.

If you are building for a single target (aka web browser) I agree, it’s very easy to access your ORM with SSR.

But if you plan to support multiple targets (web, mobile, headless) then you have to develop an api anyway so why not use the best front end framework for each of your targets?

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#82

Post by jai_ »

fishtoaster wrote: post #40
texxtxxet wrote: post #17

1. Rails retired Webpacker [that] compiled and bundled JS. Import maps, Turbo and Stimulus [are now the] default options, replacing Webpacker, Turbolinks and UJS . How do these new tools compare with the old? Versus Webpack, Vite etc?

My impression is that there are two ways to use rails: 1. Your frontend js needs are pretty minimal and you don't want something approaching a single-page app. In this case, you lean into Turbo and Stimulus to have rails do most things for you that would previously have been done with some a heavy-weight react-based frontend. 2. Your frontend js needs are significant and you do want a single-page app. In this case, i…

I think your point (1) doesn't really match with what the rails devs expect.

37Signals have both their Basecamp and Hey.com products which act very much like a single page app but only using Turbo and Stimulus.

I think the rails devs believe that single page apps are overused and the majority of functionality can be done using just the provided tools.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#83

Post by jamie_ca »

bboylen wrote: post #50
chrisbaker98 wrote: post #36

Earlier quoted context omitted.

Switched to Elixir/Phoenix a few years ago and have never looked back. Absolutely a 100% improvement on Rails in every way (except the availability of work!)

What is so nice about Elixir/Phoenix? I understand that it is functional, which seems neat, but how does that translate into better app development?

I don't have a lot of direct experience, but one of the big draws is that by running on top of OTP you get a lot of stuff for free that you'd otherwise need to hit external dependencies for. Caching and background job management that usually see you pull in Redis are the common call-outs.

Also, Phoenix LiveView is absolute voodoo magic the first time you experience it.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#84

Post by jack_riminton »

DoctorDabadedoo wrote: post #34
aliqot wrote: post #5

Quoted post unavailable.

I'm not on the RoR stack, but I think it doesn't generate a lof of buzz today because it's no longer the flashy new toy (IMO rust, go, kubernetes, a gazillion of react components in the UI, elixir, etc. took its place of "guess what, now we are running this!"). It's a battle tested and stable framework and I would use it anyday, but you no longer read much about it on the news, junior devs are not trying to pitch it…

Now we're entering a downturn I think those who went down the path of 'flashy new toy' tech stack will start seeing their chickens come home to roost

Rails people will just shrug their shoulders and keep being 10x as productive :)

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#85

Post by alexcosan »

ithrow wrote: post #65
redox99 wrote: post #56

Earlier quoted context omitted.

What technologies exactly do you use in your full stack typescript?

nodejs, postgres and react?

I would be curious to understand what frameworks people tend to use on top of nodejs (or even react). I have not found a standard devise-like way of implementing authentication in nodejs. The usual recommendation I come across is to develop all from scratch (encryption, emails, session management), using something like Passport, outsource it and pay to some third-party or use a framework like nextauth which is very opinionated and hard to change basic options. It's not uncommon to see people changing between ORM or SQL builders all the time because it's hard to find one that works greatly - it seems like a common discussion online in node communities.

I love TypeScript and would love to use it more extensively, but whenever I start a project, I quickly feel like I'm wasting so much time to do something that I'd hope a) it'd be very quick, and b) there would be some general agreement in the community on the right approach. It'd be great to compile what libraries to use, so you can very quickly put something together like you'd be able to do with Rails (e.g. devise, sidekiq, actionmailer, ...).

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#86

Post by gosukiwi »

Alifatisk wrote: post #62
brink wrote: post #10

Earlier quoted context omitted.

> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

I have to agree on this one, it feels like some people are in denial of type issues within the Ruby / Rails community. I've been experimenting with Rbs, Sorbet & Contracts though, they have their potential.

To be fair most of typing problems in Rails can be solved by having contracts and an operation pattern, kind of like Trailblazer, although they went a little bit too far lol

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#87

Post by maxpro »

mike1o1 wrote: post #67

I love Rails and how simple and boring[0] it is, and appreciate how it keeps evolving and growing. I've dabbled with some Javascript frameworks and Elixir/Phoenix, but always come back to Rails and forget just how fast and productive I can be. A lot of people complain about it, but I feel like Active Record just can't be beat, and helps me feel so productive. Add Stimulus and Turbo and the level of UI fidelity possib…

I was struggling with rails 6 and whole JS / webpack thing. But with rails 7 it feels like home again

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#88

Post by weatherlite »

jack_riminton wrote: post #84
DoctorDabadedoo wrote: post #34

Earlier quoted context omitted.

I'm not on the RoR stack, but I think it doesn't generate a lof of buzz today because it's no longer the flashy new toy (IMO rust, go, kubernetes, a gazillion of react components in the UI, elixir, etc. took its place of "guess what, now we are running this!"). It's a battle tested and stable framework and I would use it anyday, but you no longer read much about it on the news, junior devs are not trying to pitch it…

Now we're entering a downturn I think those who went down the path of 'flashy new toy' tech stack will start seeing their chickens come home to roost Rails people will just shrug their shoulders and keep being 10x as productive :)

Yeah I agree. It's not really about Rails the framework but the whole philosophy accompanying it (monolith first among others). Startups with complex micros services + kubernetes setups that will have to fire devs won't be fun to work for. These micro service architectures thrive on huge teams, not 10 guys...

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#89

Post by weatherlite »

pmontra wrote: post #37
cguess wrote: post #8

Earlier quoted context omitted.

Shopify and Github being run on Rails sorta put it to bed a long time ago.

Yes but we should not look at unicorns to settle this argument. After all not every company has the size of a unicorn, the world is not big enough for that. Very few companies get to the point that any random technology won't do. I've seen dozens of Rails projects going in production and many are still there. Same thing for any other programming language I guess. For normal sized companies Rails is OK. What matters i…

I don't know if anyone needs to think about 20 years from now anymore with the new A.I advancements we see on a monthly basis. I'd be surprised if humans still wrote code 20 years from now but we'll see...
Post reply on HN