9 ms·
Rails 5.1.0 Beta 1
- lucascaton 10y ago
- deleted 10y ago[deleted]
- wes-k 10y agobiggest 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.
- randall 10y agoThe marquee upvote worthy headline: ES6 love + webpack + Yarn in the asset pipeline. If you're still in rails land this seems pretty cool.
- out_of_protocol 10y agoActually 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
- sergiotapia 10y agoYou 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.
- elsurudo 10y agoCould you go into more detail on the concrete benefits?
- chaostheory 10y agoES6 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... https://github.com/lukehoban/es6features https://github.com/lukehoban/es6features
- LouisSayers 10y agoI'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.
- emodendroket 10y agoI mean, I don't know your tech background, but think of, like, the different between Web Forms and MVC or something.
- ivrrimum 10y agoDebatable.. You can just use plain Typescript + jquery and still be "clean" without all the nonsense of react/angular. P.S I have worked with both of those frameworks and like them, just sometimes they are too mutch.
- donjh 10y agoI think the JavaScript updates are great news, enough for me to finally dive into Rails.
- CoachRufus87 10y agoWelcome!
- pastullo 10y agoThis 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.
- pastullo 10y agoThis 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.
- oomkiller 10y agoSure 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.
- allover 10y agoHrm, 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.
- oomkiller 10y agoWhy would you build a SPA, if not for a more snappy user experience?
- maxthegeek1 10y agoNot sure why http2 and SPA's are in conflict here. If anything they complement one another.
- oomkiller 10y agoThey 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.
- pyrophane 10y agoI imagine many rails developers were doing something like this anyway and just working around "the rails way" of handling frontend assets.
- deleted 10y ago[deleted]
- config_yml 10y agonice! A welcome addition to my default stack. Thank you rails team for putting in the work!
- poorman 10y agoI'm happy they've provided a solution to Encrypted Secrets instead of simply saying "You should not commit secrets".
- artursapek 10y agoThere'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.
- stouset 10y agoEven 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).
- jrochkind1 10y agoI 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 https://gist.github.com/josevalim/470808 There are other such threads in various places from over the years. Here's one blogger explaining the race condition issue, with the ActiveRecord architecture not actually being concurrency-safe in this use case: http://influitive.github.io/news/2015/09/02/dont-use-shared-connection.html http://influitive.github.io/news/2015/09/02/dont-use-shared-... 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 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.
- sergiotapia 10y agoAt StackShare[0] we're using the webpack-rails gem to use React and ES6 javascript. https://github.com/mipearson/webpack-rails https://github.com/mipearson/webpack-rails 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. [0] - https://stackshare.io/stackshare/stackshare https://stackshare.io/stackshare/stackshare
- swilliams 10y agoIs CoffeeScript still the default then? I see it referenced in the codebase still.
- sealthedeal 10y agoplease nooooooooooo
- evolve2k 10y agoI'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.
- examancer 10y agoCoffeeScript 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.
- technion 10y agoI 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).
- stouset 10y agoThis 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.
- deedubaya 10y agoWhat should be the default?
- stouset 10y agoAES-128-GCM (or ChaCha20-Poly1305 if you're feeling particularly hipster) with a new, random IV every time data is encrypted.
- technion 10y agoIt 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/Cipher.html http://ruby-doc.org/stdlib-2.4.0/libdoc/openssl/rdoc/OpenSSL... Always create a secure random IV for every encryption of your Cipher
- timdorr 10y agoLooks like you opened up an issue, which is a good first step: https://github.com/rails/rails/issues/28135 https://github.com/rails/rails/issues/28135 Not sure how much of the Rails team browses HN comments, but an issue will certainly get their attention.
- stouset 10y agoAnd I opened a PR to fix the issue :)
- Soliah 10y agoHow is the upgrade to 5.x from 4.x? Kinda dreading rolling out the upgrade and running into the inevitable gem incompatibility dance.
- elsurudo 10y agoWasn't a huge pain in my opinion. I always use http://railsdiff.org 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.
- chaostheory 10y agocompared to rails 2 -> 3 and 3 -> 4, not bad
- mark_sz 10y agoIn terms of integration with Javascript, RoR seems to be behind for example (PHP) Laravel.
- elsurudo 10y agoAfter this integration with webpack, will it still be behind?
- yeskia 10y agoI wouldn't have thought so. Laravel 5.4 shipped a month ago with browser integration testing and Webpack by default, now Rails has the same.
- ivrrimum 10y agoAfter this update Rails is on the track. And even before, you could use gems to make the use of modern JS stuff. This update just made it faster/easier to start using it.
- mark_sz 10y agoIn terms of integration with Javascript, RoR seems to be behind for example (PHP) Laravel.
- desireco42 10y agoLooks 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.
- verisimilidude 10y agoThis 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.
- losvedir 10y agoHow 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.
- abritinthebay 10y agoIt'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.
- TheAceOfHearts 10y agoYou 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. [0] https://github.com/kossnocorp/assets-webpack-plugin https://github.com/kossnocorp/assets-webpack-plugin [1] http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#including-precompiled-assets-in-views http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#...
- deedubaya 10y agoGreat improvements here which will eliminate boilerplate setup in a lot of circumstances. Thanks to everyone who has contributed!
- LouisSayers 10y agoVery 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?
- stouset 10y agoIn 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.
- LouisSayers 10y agoSo, I guess now these same developers will commit two keys into their repos? :D
- oliwarner 10y agoThese 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. [1]: https://docs.djangoproject.com/en/dev/releases/1.11/ https://docs.djangoproject.com/en/dev/releases/1.11/
- LouisSayers 10y ago+1 for better release notes - examples would be highly appreciated.
- polutropos 10y agoI found Big Binary's Rails 5 blog more useful than the Rails 5 readme/release notes. Hoping they do the same for 5.1. http://blog.bigbinary.com/categories/Rails-5 http://blog.bigbinary.com/categories/Rails-5
- deleted 10y ago[deleted]
- andreasklinger 10y agoThey switched lately from no-js-needed-ignore-those-fancy-kids to we-now-use-js Imo worth rationalizing and explaining to their community
- matt4077 10y agoI 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.
- TheAceOfHearts 10y agoThis 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. [0] http://trailblazer.to/ http://trailblazer.to/
- ksec 10y agoI wonder how Shopify due with it too.
- pierrehenrit 10y ago
- romanovcode 10y agoI 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?
- nsommer 10y agoBecause it's a fullstack framework.
- jincheker 10y agoI feel like it should be version 6 instead of 5.1. Many should be considered as major release