Live data from Hacker News

Rails 6.1

weblog.rubyonrails.org

51–60 of 87 posts

Re: Rails 6.1

#51
post #6

It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end. Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to lar…

Man I'm hoping NEW MAGIC is like Phoenix LiveView. As a Rails dev I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages... I just want that new magic that LiveView offers. I know there are gems for Rails but I'd prefer if it was baked-in and officially supported.

DHH mentioned on twitter that it is html over websockets so I fully expect it to be similar to LiveView.

Re: Rails 6.1

#52

Hey, sorry for the aside - I am a Rails developer since Rails 4ish and we are running Rails 5 at work. I'm using Rails 6 for my own projects and in these side projects, I've been having a huge hell of a time trying to grok "right ways" to do things with webpacker/webpack. I seem to encounter issues every single time with deploys to Heroku because of precompilation issues, or imports not running right. But tutorials g…

[deleted]

Re: Rails 6.1

#53

Hey, sorry for the aside - I am a Rails developer since Rails 4ish and we are running Rails 5 at work. I'm using Rails 6 for my own projects and in these side projects, I've been having a huge hell of a time trying to grok "right ways" to do things with webpacker/webpack. I seem to encounter issues every single time with deploys to Heroku because of precompilation issues, or imports not running right. But tutorials g…

Personally, I stay away from that entire bag of brain damage and do the asset pipeline with Sass and plain ES5 Javascript.

What's supposed to be the big win mixing webpack and Rails over, say, creating a separate React/Vue app and a Rails API? Webpack seems to slow-down the whole edit/view cycle which is pretty snappy in vanilla Rails.

Re: Rails 6.1

#54

Earlier quoted context omitted.

Personally, I stay away from that entire bag of brain damage and do the asset pipeline with Sass and plain ES5 Javascript.

Wanna be friends and show me the way? Webpack seems super popular, but like there's so much shit going on. Ok node, great.. JS runtime, got it. NPM, package manager, alls good so far, just like Hex for Elixir or Cargo for Rust, perfect, makes sense. Oh wait, huh? I gotta use yarn for my webpack? Alright... yarn add , then I gotta precompile my assets... why? Why can't I just have that happen at build/deploy time? ...…

It’s always been a challenge in rails but I feel since rails 3 using assets with simple //= require file

Syntax is pretty easy and using a template language like mustache to organize via hogan.js works really well...

I’m sure I’m an outlier but you can even use es6 classes now making this pretty nice IMO...

But I do remember writing deployment scripts with rails 1-2.4 to combine files together and it was tricky... sprockets has its issues but works...

Re: Rails 6.1

#55
post #31

Earlier quoted context omitted.

For what it’s worth, the 2->3 update was by far the most consequential; they merged in Merb, rewrote how routes and controllers worked, and completely flipped expectations on how JS and views should work. Rails 3->6 has had far fewer major user-facing architectural changes, and consisted mostly of new tools and APIs. A lot of stuff they added used to be handled by gems - password hashing, attachments, background jobs…

I genuinely think someone from the 2.x days could read a "how to migrate to Rails 3" guide, skim some release notes for each of the subsequent major releases, and be generally up to speed. I've been working with Rails almost continuously since the 3.x days, and if you ignore some of the more library-like additions like ActiveStorage or Credentials, things are structurally extremely similar between 3.2 and 6.0. The bi…

IMO it really has not changed much even from the 1.x days it’s just a bit more polished with AR having where syntax now instead of only find and better solutions for organizing code that isn’t strictly model/view/controller. But if i opened a rails 6 or rails 1, it’d be pretty easy to find my way around...

Avoid too many after hooks and before filters(er actions) and the code will be easier to follow and maintain

Re: Rails 6.1

#56
post #6

It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end. Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to lar…

We're also hard at work over at the Bridgetown project to make Ruby a first-class citizen on the Jamstack. A static Bridgetown site combined with a Rails API is a killer combo for some pretty interesting use cases. Anyway, you're absolutely right—what a time to be a Rubyist! =)

Re: Rails 6.1

#57
post #6

It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end. Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to lar…

> Ruby 3 is also just a few days away which brings optional type checking Just curious, has anyone here been using type ruby type checking effectively? (since Sorbet is already available and working in ruby 2). My experience across ruby, python, and js codebases is that Typescript for JS is leaps and bounds above anything in the other two languages, both in its capabilities and overall community adoption, and the lea…

Shopify and Stripe have been using it in production.

Re: Rails 6.1

#58
post #21

Earlier quoted context omitted.

I was sold on hey.com's UI design already because it's using for dropdown menus. The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout). Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com…

Based on my casual browsing of the code I assume that it pushes small HTML fragments via WebSockets whenever the backend state changes on a given ActiveRecord model. It covers things like automatically updating the state of a model on a page, adding, removing, reordering elements etc all without any custom code so long as things are wired up correctly. Basically, all the "re-activeness" of an SPA but without ever hav…

That sounds pretty similar to Microsoft's Blazor (server side) model.

Re: Rails 6.1

#59
post #53

Earlier quoted context omitted.

Personally, I stay away from that entire bag of brain damage and do the asset pipeline with Sass and plain ES5 Javascript.

What's supposed to be the big win mixing webpack and Rails over, say, creating a separate React/Vue app and a Rails API? Webpack seems to slow-down the whole edit/view cycle which is pretty snappy in vanilla Rails.

You can sprinkle react components into your regular templates which is quite nice. A full blown SPA feels like way overkill (for my own projects, at least) when Rails handles forms and navigation so much better. You can include packs on a per page basis so it doesn't slow down / bloat the rest.

Re: Rails 6.1

#60

Hey, sorry for the aside - I am a Rails developer since Rails 4ish and we are running Rails 5 at work. I'm using Rails 6 for my own projects and in these side projects, I've been having a huge hell of a time trying to grok "right ways" to do things with webpacker/webpack. I seem to encounter issues every single time with deploys to Heroku because of precompilation issues, or imports not running right. But tutorials g…

I would definitely advise against webpacker. It's very much the case of trying to fit a square peg in a round hole. The two don't work all that well together, despite the pretty heroic work done by the webpacker team.

For an "idiot proof", batteries included, zero config approach, I would try out Parcel: https://parceljs.org/getting_started.html You just pass it an HTML file and it figures out what it needs to build from there. You can drop everything in /public/ and it all just works without any additional installs or fiddling. It works with pretty much anything you might drop in as an asset, whether it's via HTML tag or import statement.

As a close second, you can try esbuild: https://esbuild.github.io/ It's coming along and already does a lot of what you might do with Parcel or Webpack, but is stupendously fast. Fast enough that you'd need to be shipping an obscene amount of code to the browser to have build times exceed 1 second. It's a little more quirky right now, but I like it and appreciate the forward momentum it has right now.

Post reply on HN