What's new in Rails 5?
blog.michelada.io
blog.michelada.io
1) I hope ActionCable is as seamless to integrate and works as well as Rails features ought to; you can, of course, achieve web sockets right now using Faye or various other implementations, but it's quite complex to get right (though the faye-rails gem is pretty handy) - and realtime functionality is becoming more and more important.
2) I wish they'd just give up on Turbolinks. Maybe some people are using it and love it, but it's always the first thing I turn off when I start a new Rails project, and I know quite a few people who feel the same. For those of us who never thought it was a good idea in the first place, I'm not sure any number of improvements are going to change our minds.
Ditto for Coffeescript. I realise you can't just remove it, but the whole dev community is raving about ES6 - there's a whole of JS devs who could be a lot more interested in Rails.
Does it directly impact me now that I choose to ignore it? No. Does it impact a newcomer, particularly one that's into JS? Yes.
It's not perfect but it's how I learned coffeescript.
Other than that, I don't think Rails necessarily pushes either for/against coffeescript. You can either use it or not. Plenty of rails apps have been written in plain 'ol js.
As for ES6, there is the sprockets-es6 gem. According to their github gem, their goal is to get in es6 support into sprockets 4. This, obviously, is not a perfect solution - but I think this is going in the right direction.
The server-side partial replacement, for example, is wonderful.
The intent of Rails is to make writing web applications easier, but that writing web applications actually got much more difficult for me as a Rails developer when Angular and Ember and then later React got popular. I love Ruby, but I respect the fact that the Javascript-client-side-heavy/"single-page" part of the app is where the magic is for at least a few years now- really several years.
Other than Rails helpers in the 2006-2008 timeframe being a big deal, Rails' has not ever really helped out a whole lot on the JS side, and you wouldn't expect it to. The asset pipeline is wonderful, and coffeescript support with in it is ok I guess, even though I don't use it. But, writing JS client-side is not any easier. To be a full-stack developer in today's world I have to accept the fact that Ruby, as much as I love it and would rather develop in it all day and night, is just not taking over in every facet of development. There is no Rubyscript on the client side taking over the world. There is ES6/Typescript- that is the future.
A substantial number of Ruby masters are jumping over to the Phoenix/Elixir bandwagon. I look at it, and want to like it, but I just haven't gotten into it yet. I know it is fast, but it just isn't as readable yet for me. And it won't solve the problem that the client still needs to be written primarily in Javascript.
And the answer is not Node either, because every serious Javascript developer I've talked to says, "Node is still not ready."
I just feel let down. I want to get excited about Rails again, but give me a path. I don't really like Ember a whole lot, because the community is just not where it is with Angular and React. Someone please take your favorite frameworks and show me how my life is supposed to get better by using them. Show me how it is fun. Bring back the magic, because right now it all just seems like more and more of a PITA as attention deficit has fully set in within the web application development community and there is no clear way ahead for the next few years.
When considered as a whole of the combination of what is possible with the stdlib and all of the best gems available, Ruby can be written clearly and tersely. Those are the two first and most important things that I look for to do general web application development. From that perspective it beats Javascript, Python, Php, Java, C#, Go, Scala, Erlang, Haskell, OCaml, and every other language I've used.
I'm not saying Ruby is the best language ever. It has its flaws. In a few places in the stdlib, it doesn't make sense. There are languages, with maybe Smalltalk and Lisp at the top of the list, that beat Ruby from a simplicity and purity standpoint. But, Ruby is just great to use. I love reading it and love using it. It took a few years in the beginning of love and hate, but if I was stuck on a deserted island and had one programming language, Ruby would be it for me.
If it weren't for the Ruby core group being so exclusive and bitter towards others getting involved to make it even better, and if it weren't for the Rails core team just having too much to do and being unable to execute on support, documentation, performance, clarity, simplicity, and important features all at the same time, then maybe it would be the world's number one language and Rails would be the number one web framework.
Instead Javascript had emerged years ago as the language of choice in the browser, had plenty of attention spent on making it execute quickly, etc. though it was an uglier language than Ruby, and because of that attention, it is today's number one language for the web. But, I still like Ruby.
> There is ES6/Typescript- that is the future.
According to the sprockets-es6 github page, its goal is to have es6 functionality in sprockets 4 by default.
> Node is still not ready.
I'm not quite sure what you mean by this statement. It's very ambiguous.
Anyways, you might want to look at MeteorJS. It's a rails-like framework in javascript. It's not ready yet if you want to use a database other than mongo.
> I just feel let down. I want to get excited about Rails again, but give me a path.
One of the lessons that I've learned working with OSS is that we as individuals & developers are responsible to create these paths. The people who develop Rails & other awesome oss are just regular janes/joes like you and me.
> I don't really like Ember a whole lot, because the community is just not where it is with Angular and React
The ember community is not as big as Angular's or React, but it definitely does exist & is very friendly helpful.
IMO, Ember (along with Ember-Data & Ember-CLI) is the Rails of the js frameworks, it follows strong conventions and comes with a lot of magic right out of the box. You should check out their guide - perhaps they could have an overview that actually states the features that come out of the box.
Not really sure why you say that whilst TL3 tries to solve exactly that issue in a simpler, classical way [0]
I love the idea of being able to use the usual Rails helpers combined with JS in a React-kind of way and at first sight that's what TL3 could manage to do.
[0] by that I'm referring to the clean HTML that still looks semantic and has all the normal separation of views and styles whereas in React et al if one's inspects the code is just looks horrid.
Regarding SPAs the isomorphic approach seems really contrived at this point and for most web apps TL3 seems like an elegant solution whilst keeping the full power of Rails intact.
Sure there are cases with heavy UI apps that require components et al but for my use cases TL3 + Rails5 looks like a breath of fresh air, maybe a middle step to full SPA.
Even though I'm a JS-first dev but I second that. ( HTML & CSS in JS ) is a bad idea and not considered to be progress from the messy yet working templating engines (JS in HTML).
Proponents love to argue that integrating HTML & CSS into JS makes it easier for testing since JS is amenable to thorough testing as opposed to HTML & CSS.
While this is partially true and template files are not straightforward to test esp when you throw app logic into the mix but it still manageable if you kept to a minimum to the view part only and don't go overboard with it.
Also and this is very important, It's a given that HTML & CSS are forgiving compared to JS when it comes to errors but that doesn't mean that it's unlikely for a developer to shoot himself in the foot or to introduce unwanted/unintended bugs in the app through them esp. CSS and these usually are harder to catch and fix.
Turbolinks 3 sounds like it's going to be real nice. My biggest reason for using SPA's are not the components, or the data flow, or the states, etc. It's for the partial rendering and the nested views. With Turbolinks 3 coming out, if it is as advertised, then I will pretty much be reaching for Rails for most of my projects.
I've moved on from Rails to Node for websockets. For ActionCables, the real-time library for Rails, I have to admit that it does kind of sound like a PITA to have a second server running for it. Doesn't sound right. But I can't judge it before it comes out (nor do I really have any right to judge. It's so easy to be entitled as a FOSS user). But if it is a pleasure to use, just like the rest of the Action* family, then that's another nail in the coffin for my use case for anything else. But then again, my needs and your needs may be different. I usually build small to medium sized apps that will never hit 4 figures in terms of users.
It sounds like you're looking for that "magic" you've felt when you first got into Ruby and RoR. We all do! But things like Rails once comes once in a blue moon, so even though it may not be the new hotness, I just like to appreciate that it happened. I don't think you'll find any other tech that will give you that "this is it!" feeling like Rails did for a long while.
In the mean time, instead of stressing out about tools, just focus on writing good software.
https://github.com/TannerRogalsky/sprockets-es6
Rails is still a second-class JS citizen due to the asset pipeline being opinionated and controlling compared to the node way of doing things, but it gets you closer to 'the new hotness'.
-----
Right now, the web frameworks that are on my radar are: Laravel(PHP), Phoenix(Elixir), React+Meteor(JS), and RoR(Ruby). This list is by no means exhaustive, just that recently they caught my attention and I am contemplating to choose one for an upcoming CMS project.
Would like to know if these frameworks each has its own segment or/and sweetspots, or they kind of compete against each other and the choice is mostly personal preference?
The goal is to hear what people like/dislike on a particular framework. Inputs from those who have worked with multiple frameworks will be awesome.
Thanks in advance.
Thing is, none are CMS's. If that's what you need, why would you start with a framework? Sure it's fun to build and I always think I can do better than the existing CMS's do, but it's never a good use of my time - or good for the client.
Please, if you need a CMS, use a CMS. If you need a Content Management Framework (CMF) one of the above could save time. If it's an application surrounded by managed content, your choices are different again. But please don't reinvent the wheel if you can avoid it.
I've used it on a project and was quite pleased. Using their API, separating content publishing from the presentation becomes much more robust than with a traditional integrated CMS that you customize using themes or whatever.
If this is a small business website and will never be built on ever again, then absolutely ignore the hate and go Wordpress. If it's something that might be extended over the years into use cases beyond just a webform to post an article with a title and a body then it's worth evaluating if you might be able to custom tailor a better fit for your business.
All CMS' suck, a bit like all OS' suck. As soon as you do anything non-standard their inherit flexibility becomes a burden. If you have skills in rails and need an off the shelf CMS find a popular one and use it you like but if you need to create a web 'application' look at Sinatra, rails or whatever but don't use a CMS as the foundation for an application.
Most of all, if my team and I have one take away: Stay far away from Drupal and people that preach its relevance. It is a world of hurt with an 'expert beginner' community. That has cost so many organisations more time and money than they ever anticipated.
Treat ever 'off he shelf' product with a degree of disposability - don't get locked in and never get into the trap that you've chosen 'the best'.
Also, because they're acronyms you pronounce by enunciating the words, my instinct would be to use OS's (as you would pronounce the 's, O-S-es). But that's up for debate.
For example:
The OS's kernel blew up (possessive apostrophe, the OS owns the kernel)
He had a wide range of OSes to choose from (pluralization, there are many OSes)
I'm more in favor of this convention (OS') when it comes to possessive apostrophes for word that end in an "S" which is to omit the trailing "S" and leave to the reader or interlocutor to infer the meaning from the context.
I haven't worked with Phoenix or even Erlang/Beam that much (though I've used Rabbit quite a bit). I think the overall model of the runtime is brilliant, but I'm not sure you need to buy in to the whole ecosystem to benefit from the learnings of it. There are actor systems for a lot of languages (Celluloid and Akka come to mind). Celluloid works nicely for weird long running things. I'm not totally sure how much it matters for your typical web app that would work fine enough with a CGI model (though I guess it's not totally different).
I've only played with Meteor, but I've used Node and React pretty extensively. React in particular is brilliant. It provides a nice way of thinking about the UI of your app in a more functional way. Of course, the devil's in the details, but it works pretty well. I'm less keen on Node as a backend language. A lot of backend code is between the lines, waiting on the DB or dealing with crazy errors. Node and JavaScript aren't very good at those things today. ES7 Async functions have some promise (hah!), but interoperating between libraries can be a little confusing at first.
Rails is an old friend of mine. You can do a lot with Rails, and it's almost sacrilege to say these days, but a well written monolithic, non-javascript heavy Rails app can be a joy to work in. It's pretty good for CMS type content; I've used it a bit to build various web stores to good effect. Things can get hairy when you try and step outside of "the Rails way", but that's less of an issue these days. It can also be a little funky using the asset pipeline with newer frontend libs, but there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).
Are you thinking of Rails Assets?
Rails is suitable if you're greenfielding a complex new site (as would be Go or Elixir), Laravel probably if you like PHP (haven't used it), definitely not Drupal, Typo3, Wordpress etc if you are thinking of extending them in any significant way. Meteor doesn't strike me as particularly suitable for a CMS. Django might be worth looking at as it has built-in admin which is more CMS-like than others?
Since you mention building a CMS, my 2 cents on that:
If you need something very simple which is a good fit for a particular CMS and/or are on a very limited budget, just use a prebuilt CMS product and adjust some templates, otherwise you're reinventing a lot for not much gain. Doesn't sound like you want this option.
If you are producing a bespoke site consider writing most of what you need from scratch rather than trying to use modules/plugins etc. because the capability to use modules/plugins tends to invert authority in an app, and require you to do the things the framework way or not at all. Every bit of code you import from elsewhere comes with a significant cost in maintenance, security and complexity. So don't choose a framework in the hope you can just plug things other people have written together and make it all work.
Avoid CMS products which try to allow the end user to customise records (custom fields, nodes etc), install hundreds of badly written modules, and do a limited form of programming by manipulating records or templates in the database (I'm thinking of things like Drupal and to a lesser extent Wordpress). If you try to use them for something complex it will usually lead to an unmaintainable morass of poorly understood code.
Now that looks interesting. Thanks for sharing.
/me goes back to trying to apply visual design changes to a site 'built' via Visual Composer... kill me now.
All solutions have trade-off. Obviously rails isn't adapted if an app is focused on websockets, Elixir gives you good primitives for distributed programming and PHP runs on cheap hosting. Rails is really like "ok , I have like 2 weeks I need to develop a complex CRM for a client" , something in my opinion that cannot be pulled off that quickly with other solutions.
But yeah , there is no silver-bullet. When I read articles like these I wonder if the author really believes it or if he is trolling :
https://www.linkedin.com/pulse/go-dominate-next-decade-ian-e...
Every solution has its share of problems,even Go.
I have this dream of not having to work with Drupal ever again, so I often daydream about what I'd build if I were given the chance. In a sense I'm in the same position as you, except that it's probably never going to happen and that I've been thinking about this for years.
I'd go Rails, and here's why.
Rails is easy to learn - even if your team has never written Ruby it's an easy language to pick up with way fewer gotchas than either PHP or JS. I've evaluated Laravel, and it's probably the best PHP option out there right now, but knowing Rails, I often find myself hating how much code you have to write to accomplish the same thing in Laravel just by virtue of it being PHP. The resulting code feels clunky (though, that's surely just because I also suck at programming).
Rails is extremely mature - it's been around for over a decade. The upgrade from 2 to 3 was painful, the upgrade from 3 to 4 was much less so. I imagine the upgrade from 4 to 5 will be as well, and so on. The ecosystem is very filled out, the package mgmt story is there, the testing story is there. These are new developments on the wider PHP scene that will probably takes several more years to reach the level of adoption and familiarity that Ruby enjoys. I love writing JS, but the whole ecosystem over there is in this constant state of tectonic upheaval right down to the language (ES6), and unlearning the old gotchas so I can learn the new ones doesn't appeal to me right now.
Rails is exceptionally well documented in terms of blog posts, the Rails Guides, and the API docs. None of these other technologies even come close. This is especially true of Laravel, and I've only ever read 1 blog post about Phoenix, so good luck with that.
This was supposed to be short, sorry.
This was me, until three years ago. I am freelancer, all my gigs, clients and my whole network was about Drupal. Hell, I still receive requests for Drupal work on a weekly basis: my name was established, so almost impossible to move out of Drupal.
So I wrote some op-eds on why Drupal was not always a good choice for projects (most notably: government projects) citing from my experience as rescue-consultant-for-failing-drupal-projects.
And then I wrote http://berk.es/2012/10/01/farewell-drupal/ and declined all work Drupal related.
It does not have to be Rails. It could be Opal, Django, Spring, Symphony, Yii, anything. But if you are really unhappy with Drupal, as you seem to be, cut the ties. There's more then enough work out there.
And working in an environment that is built for developers (instead of building a webapp by clicking checkboxes and clumsy html interfaces in the Drupal backend). Move to a community that encourages clean code, "craftmanship", designs, patterns and so on, you will become a better programmer. If that is what you want.
I'm now a happy Rails developer. Who learns new things every day. I like my job a lot; so much, that I can't imagine not coding for work (And already I am almost always that Old Guy on the job). In ten years it'll probably not be Rails anymore, but WhateverFancyFramework is the default then. And because within Rails I really learned coding, picking up new languages, frameworks and whatnots is not that hard at all, anymore.
I mostly just do everything else in the org - infrastructure, architecture, mgmt, etc - and let the other guys actually do the Drupaling. Drupal is a minimal part of what I do day to day now, so it's not as if I hate my job. Quite the contrary. And I'm constantly learning new things and getting better as a dev, not just a Drupal dev. And the only one of my "really big ideas" that has yet to be implemented is the one where we build a custom (Rails) CMS and get out of Drupal/Features hell for good. And my boss doesn't even hate on the idea, it's just not the front burner item yet. The time will come, oh yes. It will...
Good bumping into you again.
Hopefully, Drupal 8 is going to bring all those fun parts again.
On the one hand, if there's not a large market uptake of Drupal 8, there won't be any reason for community devs to learn all the new ins and outs when they could just learn the ins and outs of something smaller and simpler. On the other hand, if there's not a decent D8 developer pool for companies to hire from then I don't know how there could be a large market uptake...
I'm not all that deep in Drupal anymore, but from what I hear: I doubt it.
Drupal has to choose a target audience and focus on that. If they choose "developers", then it will become a great tool that is fun to develop in, no doubt.
But as long as it remains in a limbo between "end-users" (the one's browsing the site you are building), "webmasters/editors" (those managing the content and configuring tidbits) and "developers" this won't happen.
There are just too many conflicting interests there. Real use case: can a webmaster change some settings in the image-cache? certainly not! Changing the width of an image will break all your carefully crafted CSS grids: it is tightly coupled to the Theme (which lives in Git and goes through a release-cycle).
If Drupal chose "developers", a thing like "imagecache" won't even exist in its current set-up. It won't have a database to store its settings, nor a web-interface. Instead it would be an Image class that you can inherit and then define some settings and methods in order to get an image-derivative.
From what I've seen, Drupal 8 does not change this conceptual basis. So I highly doubt it is possible to develop sites when your basis is conflicting with what you want to do on such a crucial level.
How did those go down and what happened after you wrote them (both from the community & potential clients)?
I am sorely tempted to publish some I've written about a CMS over the last 3 years, but prudence has kept me silent so far.
Quite some people felt betrayed and were angry. Thing is, though, what I wrote was simply provable true. Backed up with numbers and such. So, I could conteract with "well, then show me what facts are wrong".
For myself, I felt relieved and a little sad. Sad that I could not achieve what I worked so hard for: to make Drupal the best framework for developers to build CMSes with.
The realisation that this was not going to happen, made me angry too. Untill the moment that I realised that pushing Drupal into a direction "it" did not want to go was frustrating. But also that, instead of turning Drupal into a Rails, I'd rather use Rails instead: why spend energy turning it into a framework that already exists, and that I can use today, without spending that energy. (I believe this mechanism is one of the greatest threats to WordPress, Drupal, Joomla and many other PHP-frameworks: once people grow into better programmers, they often simply leave, instead of pulling their framework up with them, to higher levels).
Shouldn't it be called Rails 4.3? That been said, you could get the performance improvement by just upgrading to ruby 2.2.2
And there will be Turobolink 5 too.
I was guessing they have some more things to announce soon.