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

Rails 5.1.0 Beta 1

weblog.rubyonrails.org

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Rails 5.1.0 Beta 1

#71

Post by examancer »

oliwarner wrote: post #45

These release notes really let Rails down. Crowing on about the number of commits and rationalising decisions is a waste of my time, just explain how it's going to make or ruin my day. Links you'd expect to explain features just take you to source files, not documentation. And a HUGE amount of the changes are actually scattered around in sub-project changelogs. They should look at Django for some inspiration. Here's…

You are comparing release notes for a beta to an actual release. Based on previous rails releases, by the time 5.1 rolls out the releases notes will get much more detailed and resources like guides.rubyonrails.org will be updated to reflect the latest features.

Re: Rails 5.1.0 Beta 1

#72

Post by examancer »

swilliams wrote: post #15

Is CoffeeScript still the default then? I see it referenced in the codebase still.

CoffeeScript was never the "default". Since the asset pipeline was added new rails projects contained only a single 'application.js' which included any default JS libs. There has never been coffeescript in a default rails project. That makes the default plain-old JavaScript. CoffeeScript has just been there as a default gem so it was available to you by default, but you have never been forced or even strongly encouraged to use it.

That said, I love CoffeeScript and continue to use it to this day. It gets a lot of hate and I've been pushed to write a lot of ES6 these days, but CoffeeScript is still much more succinct.

Re: Rails 5.1.0 Beta 1

#73

Post by oliwarner »

matt4077 wrote: post #64
oliwarner wrote: post #45

These release notes really let Rails down. Crowing on about the number of commits and rationalising decisions is a waste of my time, just explain how it's going to make or ruin my day. Links you'd expect to explain features just take you to source files, not documentation. And a HUGE amount of the changes are actually scattered around in sub-project changelogs. They should look at Django for some inspiration. Here's…

I think they're excellent – the text is actually interesting to read and it gives me a much better impression of the relativ importance of changes than a simple list would. I also can't find fault with giving some appreciation to the relevant people who contributed by actually naming them.

You'd call the Django release notes a simple list?

My main problem isn't the fluff, it's the lack of real documentation for new features. Or that the link doesn't go to the documentation, it goes to the merged PR on guthub. And that it's very incomplete (see Everything else).

This is not excellent, in that it could keep the things you like and still be much better.

Re: Rails 5.1.0 Beta 1

#74

Post by oliwarner »

examancer wrote: post #71
oliwarner wrote: post #45

These release notes really let Rails down. Crowing on about the number of commits and rationalising decisions is a waste of my time, just explain how it's going to make or ruin my day. Links you'd expect to explain features just take you to source files, not documentation. And a HUGE amount of the changes are actually scattered around in sub-project changelogs. They should look at Django for some inspiration. Here's…

You are comparing release notes for a beta to an actual release. Based on previous rails releases, by the time 5.1 rolls out the releases notes will get much more detailed and resources like guides.rubyonrails.org will be updated to reflect the latest features.

The Django notes I looked too are for a beta release too. I agree that it's less important but consistency never hurt.

Re: Rails 5.1.0 Beta 1

#75

Post by pierrehenrit »

TheAceOfHearts wrote: post #59

This is awesome. Webpack and yarn are incredibly powerful tools. There's a learning curve with webpack, but once you pick it up, it's easy to make it do anything you need. If you actually dig into the internals, you quickly realize that everything is incredibly modular and you can pretty much hook into everything. If you're not already using yarn, go check it out right now. Migrating literally took our team less than…

Good points! It always seems easy to start with a SPA for a small app but I noticed that it can be quite hard to maintain if the app is not super actively developed. Even if the code is simple you usually have a lot of dependencies, not always well maintained themselves, and upgrading is hard.

Re: Rails 5.1.0 Beta 1

#77

Post by oomkiller »

allover wrote: post #39
oomkiller wrote: post #35

Earlier quoted context omitted.

Sure it's possible to ignore, via Turbolinks or similar. I have witnessed the shift back to the backend over the past year or two, including in the Phoenix community. With HTTP2 inbound and microsecond response times via Phoenix, the case for making your new app a SPA is harder to make, if you take an honest look at things. There are some benefits to be had with React Native, or Angular2 Dart + Flutter, but mobile ap…

Hrm, can't really agree with the premise, I feel like the backend not being fast enough should never have been a significant reason to write an SPA.

Why would you build a SPA, if not for a more snappy user experience?

Re: Rails 5.1.0 Beta 1

#78

Post by oomkiller »

maxthegeek1 wrote: post #67
oomkiller wrote: post #35

Earlier quoted context omitted.

Sure it's possible to ignore, via Turbolinks or similar. I have witnessed the shift back to the backend over the past year or two, including in the Phoenix community. With HTTP2 inbound and microsecond response times via Phoenix, the case for making your new app a SPA is harder to make, if you take an honest look at things. There are some benefits to be had with React Native, or Angular2 Dart + Flutter, but mobile ap…

Not sure why http2 and SPA's are in conflict here. If anything they complement one another.

They definitely complement each other, but HTTP2 helps out with the request/response cycle and reduces latency in general, which reduces the threshold between rendering on the client and backend.
Post reply on HN