Live data from Hacker News

Rails 5.1.0 Beta 1

weblog.rubyonrails.org

61–70 of 78 posts

Re: Rails 5.1.0 Beta 1

#61

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…

They switched lately from no-js-needed-ignore-those-fancy-kids to we-now-use-js

Imo worth rationalizing and explaining to their community

Re: Rails 5.1.0 Beta 1

#62

This is pretty great. Since hopping back onto Rails about six months ago, I've made a habit out of removing the asset pipeline from every new project in favor of webpack and Yarn. It always feels a little cobbled together, but worth the trouble to take full advantage of the JS ecosystem. Having these tools as a native part of Rails will hopefully make my own workflow a bit more streamlined. Looking forward to it.

How do you handle versioning of the compiled assets and linking to them from the view? ` ` is the main benefit of the asset pipeline to me, so they can be long-expiring and busted with any change. I, too, agree that the asset pipeline is clunky. But at my startup we went the other way: use npm/webpack but compile the resulting file _into_ the assets directory, so we can still use the asset pipeline. It sort of double…

abritinthebay's answer is the same thing I'm doing. Webpack can give you a hash on each use, which allows you to:

* add that hash to the filename(s) of your generated assets;

* print out that hash to a file;

* fetch the hash from that file for use in your helpers/views, to call the correct assets.

The following blog post is a good place to get started.

http://pixelatedworks.com/articles/replacing-the-rails-asset...

Whether or not this is better or worse than your current setup, I'm not sure. It's probably equal levels of duct tape either way. Printing out the hash and rolling your own solution gives you a bit more power and flexibility though.

Re: Rails 5.1.0 Beta 1

#63

Earlier quoted context omitted.

You know I used to think it's craziness, but it really makes for a much experience writing ES6 as opposed to random-ass jquery and javascript sprinkled all over the place. I've grown to love it.

Could you go into more detail on the concrete benefits?

I mean, I don't know your tech background, but think of, like, the different between Web Forms and MVC or something.

Re: Rails 5.1.0 Beta 1

#64

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.

Re: Rails 5.1.0 Beta 1

#65
post #28

Earlier quoted context omitted.

This needs to be higher up. It's using Blowfish (a 64-bit block cipher), unauthenticated, in CBC mode. These should not be the defaults for a system designed and built in the past five years.

What should be the default?

It only addresses half the problem, but Ruby's own man page has a bolded warning:

http://ruby-doc.org/stdlib-2.4.0/libdoc/openssl/rdoc/OpenSSL...

    Always create a secure random IV for every encryption of your Cipher

Re: Rails 5.1.0 Beta 1

#66

Actually pretty major release. Hopping on javascript's crazy train. It was expected anyway, there are no way to ignore js-crazyness anymore (most of the frontend toolset exists only as js implementation). Also, Phoenix (ideological successor of rails) took this approach from the start

I imagine many rails developers were doing something like this anyway and just working around "the rails way" of handling frontend assets.

Re: Rails 5.1.0 Beta 1

#67

Actually pretty major release. Hopping on javascript's crazy train. It was expected anyway, there are no way to ignore js-crazyness anymore (most of the frontend toolset exists only as js implementation). Also, Phoenix (ideological successor of rails) took this approach from the start

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.

Re: Rails 5.1.0 Beta 1

#68

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…

I wonder how Shopify due with it too.

Re: Rails 5.1.0 Beta 1

#69
I am the only one who sees this JS integration as bloated overkill?

Nowadays developers prefer to do SPA based approach where you have API (RoR - JS Stuff) and Front-End (Whatever front-end people decide to choose that will be outdated in 1 year).

Why can't RoR just focus on the back-end stuff instead of adding bloat that will be obsolete in 1 year?

Re: Rails 5.1.0 Beta 1

#70

I am the only one who sees this JS integration as bloated overkill? Nowadays developers prefer to do SPA based approach where you have API (RoR - JS Stuff) and Front-End (Whatever front-end people decide to choose that will be outdated in 1 year). Why can't RoR just focus on the back-end stuff instead of adding bloat that will be obsolete in 1 year?

Because it's a fullstack framework.
Post reply on HN