I don't like this "secret storage" system. Unauthenticated CBC mode, and doesn't actually set an IV (I'm assuming a hardcoded default comes into play).
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.
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 apps are very difficult to justify, given the increased friction they cause to new users.
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.
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.
ES6 brings to Javascript needed features that other programming languages already have had; like a cleaner way of writing classes, more basic collection classes, more tools for concurrency, the list goes on...
I'm no modern JS guru, but think of it as you get to advance the JS language, and use all the latest libraries independently of what version of JS is running on the client.
This is because you write in the latest JS syntax, which then gets converted into an older JS version (allowing greater client compatibility).
JQuery is still great if you only want some basic functionality - e.g. a datepicker, but if you're building Photoshop in the browser, then it quickly becomes complicated, and you'll find that you start attempting to build your own framework to support your development.
This release is in my opinion a life saver for Rails.
Instead of forcing people to hop off the Rails train, it empowers them and let them choose their favourite JS library on top of it, while serving them hassle-free, in a very rails fashion.
Shouldn't this have been shipped in 5.1, it might have very well been a bit too late.
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 5 minutes, and we haven't had a single problem so far. Its default behavior is much more sensible than npm.
Writing a SPA that handles every edge-case is really challenging, so it's actually incredibly refreshing to write a fully server-side rendered app. Especially after spending a lot of time working on SPAs. It's pretty mind-bending how easily you can wire up a meaningful prototype, just by sticking to rails' guidelines. Even though my love for ruby has diminished after having tried other languages, I'll still happily reach for rails in many situations.
I think for many apps you'd strike the best balanced in complexity by mixing both server-side rendering and having some pages which are small javascript applications, instead of going for a full-blown SPA. Depending on what the app does, somewhere between 5k and 10k SLOC seems to be a sweet spot for an app to be useful while still being trivially easy to change and keep track of everything. Once you pass ~20k SLOC, I've found it starts to get harder to follow everything, and changes start to require a bit more effort. It's worth noting that those numbers are pretty arbitrary and are probably wrong :). Again, it depends on the application.
In my job we had a period where everything was handled by a SPA, and it was pretty painful. If you have a password-gated app, consider doing all the auth views with server-side rendering, and only load the SPA for logged-in users. This lets you drastically simplify how you handle things like resource caching and routing. Leverage the server more, stop trying to handle everything on the client! That's gotta be one of the most important lessons I've learned.
My really big complaint with rails is that it works so well until it grows enough, and then it gradually starts to fight you. How do you transition beyond rails MVC? I've looked at stuff like Trailblazer [0], but I'm uncertain if that's really the direction a growing rails app should take.
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.
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? `<%= javascript_tag 'foo' %>` 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 processes the assets but it was the only way I could think of to take advantage of modern JS with imports and exports, and still get the cache-busting goodness and easy rails view interoperability.
You can use a plugin like assets-webpack-plugin [0] to get a JSON file that maps to the compiled file names. That's basically the same thing asset pipeline would do.
Here's a blog post [1] explaining how to use webpack with rails.
It's pretty easy to do - have your build tool generate a hash of the bundle and store that (simplest way is a json file with the file:hash as a key:value, obv other ways are possible)
Webpack has built in support for this as it generates chunk hashes and can output filenames with them in it, then you just get that data and do the same as above.
How you put that in your Rails app is up to you - could be a simple helper like javascript_tag, that would be easy to do.
Rails really didn't have any magic to the asset pipeline in that regard.
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.
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 their latest beta release notes [1]. It's concise, everything links to relevant documentation with examples, and the entire project's changes are handled on the one page. There's even a list of things to check if you're upgrading.
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.
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.
It would be awesome if someone could write a migration guide for this switch. I'm sure a lot of Rails teams are using the webpack-rails gem and are planning to switch to the official gem.
There's a new command, `bin/rails secrets:setup`. I haven't worked with any recent versions of rails, but it's kind of surprising that they are just now addressing this. I know I've seen Rails secrets being checked into Github.
Even with this, I think it's personally a bad idea. But sometimes security is improved more by reducing the impact of making poor decisions (e.g, storing secrets in your repo more safely) than it is by chastising users to make better decisions (not storing them in your repo at all).
I'd imagine with ES6 all nicely wired up in this release that moving away from Coffee would be an obvious next step but was way to large to undertake in one release.
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.
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?
biggest change for me is the new webpack gem. Hopefully I can replace my current setup with this so that I can get seamless es6 within my asset pipeline.
Very interested to see how webpack plays with the asset pipeline.
With Capybara, I'm not keen on the default transactional rollbacks. The reason for this is, that it's handy to keep the data in the db after a test to see what the final state of it was. I always drop the data before a test runs - but then again, I prefer the use of factories over fixtures.
Can someone please explain the benefits of this encrypted secrets business?? I'm struggling to see the benefit - I understand that you need access to the code + the env var, but in all practicality, if someone has access to your env vars, then is it really that much more of a reach to figure out what the key in the code is?
In a nutshell, the point is that despite near-constant warnings not to commit secrets to repositories… people do. So this lets developers commit secrets to their repo with reduced risk of leaking the secrets themselves.
That said, there are other good reasons not to commit configuration like this to your repo (configuration and code don't always change in unison; sometimes you need to use older code with more recent configuration, for example) but it's at least better than the current situation where careless developers wind up with thousands of dollars of charges against their AWS accounts after accidentally committing AWS keys.
I had heard that Capyabara-based tests were going to be incorporated in Rails. As the multi-threaded concurrent nature of these always makes things a pain, hard to get right, leading to much pain for devs with non-trivial test suites -- I was curious to see how they'd handle it, if there'd be an 'official' Rails solution, ideally backed by some deep Rails knowledge.
I was surprised that they've chosen to use the 'shared database connection accross two threads' approach. While this was for a while popular approach amongst people trying to figure out the best way to use Capybara-based tests with Rails -- mostly because you get to keep transaction-based database cleanup -- it was largely determined through experience to be too flaky. ActiveRecord's architecture just wasn't designed for a Connection object (representing a single actual network connection) to be shared between two threads, it's not a thread-safe object.
José Valim originally proposed the approach in a gist, and you can see a long discussion among people having hard-to-debug problems with it here: https://gist.github.com/josevalim/470808
There are other such threads in various places from over the years.
I thought I remembered Valim actually posting somewhere himself "Yeah, turns out, that wasn't a great idea", but now I can't find it. (It may be that José deleted most of his tweets when he left twitter?)
So I'm surprised Rails took this approach. I can't tell for sure if the approach now in Rails just basically takes Valim's approach (violating AR's concurrency contracts and expectations), or actually takes a new approach that will truly be concurrency-safe, while somehow still sharing the connection (another lock somewhere? Are AR connections in general now safe for sharing between threads? Cause that'd be huge if it was true in the general case). https://github.com/rails/rails/pull/28083 Can anyone else?
Either way, reliable Capybara has been a real challenge to a lot of devs due to race conditions, it would be shocking if Rails gets it right on the first try, when many devs haven't managed to figure out a right way to do it in years of trying! I expect lots and lots of frustrated devs running into race conditions and filing Issues. It will be interesting to see if this ends up a maintained feature, or another Rails internal abandonware. If dhh and his team use it, and run into the race conditions, then it will certainly be addressed; otherwise, some 'difficult' Rails features seem to sometimes end up basically abandonware.
What kind of race conditions are you talking about? I ran this setup for years, and just about the only thing that has been stable in the whole setup is ActiveRecord.
You ran the shared connection situation with no problems? Great, but I linked to examples of people who have had different experiences, you can follow the links to see. Like all race conditions, sometimes they appear and sometimes not, and it can depend on your particular app.
They are not surprising, because the concurrency guarantees of AR do not include sharing a connection object between threads, it is not meant to be thread-safe.
With postgres, the race conditions on sharing a connection between two concurrent threads sometimes look like "PG::Error: connection is closed" or "PG::UnableToSend: another command is already in progress", with mysql sometimes like "Mysql2::Error: This connection is in use by: #<Thread:...>"
The Rails app runs in one thread, the test in another one. There are no problems as long as you don't use the database from the tests, which would be against the spirit of integration testing anyway. Only browser actions, even to check if the assertions are valid. A little inconvenient but safe and true to what users will do and see. I never got any problems in that way.
While integration tests may ideally not use the database (although I find in practice, I think you often need or want to do some 'manual' setup first. But even if you don't, the _other_ tests do db setup and teardown, and the problems start happening when the Rails app is still busy doing something triggered by a test that the test thread considers 'over'. Easy to say "Well, don't do that", but in practice it is very difficult to diagnose, debug, and stop. Using fancy new front-end frameworks like React or Angular tends to make it orders of magnitude worse.
If you haven't run into problems, consider yourself lucky and I don't hold it against you, but many have.
Looks like fanatastic release! Yarn and Webpack support, inspired from Phoenix probably. Capubara!... I mean Capybara and DB cleanup. All this looks pretty great. I need to look into mailer upgrades.
Wasn't a huge pain in my opinion. I always use http://railsdiff.org to start, but yeah I did run into a couple of unmaintained gems that weren't compatible and I had to patch myself.
