Hacker News Reader

Rails has always given me conventions to follow when creating/writing apps - except for javascript. Rails never really had any conventions for writing javascript. Hopefully, you and your coworkers had good habits when writing/organizing your js, but rails never really gave you any guidance except to throw it in your apps/assets/js folder.

> 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.

I'm the opposite. This release excites me more than it did for Rails 4.

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.

I am excited about Rails API becoming an official part of the Rails ecosystem. I don't expect Rails to solve my client-side needs (templating was always slow, sprockets suboptimal), but I love to use it as an API and have a simple node server to proxy my website calls to that api. An additional benefit of this is that your client consumes the same API, as your other clients, so you don't have to worry about two api versions anymore and it improves your TDD.

I think you can try solve the "rails no longer excites me" problem by finding a more exciting language than Ruby. There are more than plenty of them out there.

Like what?

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.

You could use Clojurescript (another functional language). I've enjoyed my experience with it thus far.

It's an exciting time for Haskell developers right now, we just got an a awesome new build tool (stack), an incredible new server-side framework (servant) and our compile to JS tool (GHCJS) is improving by leaps and bounds.

Try Clojure and ClojureScript, there a few people who went from Ruby to Clojure, it seems to attract Rubyist. "Clojure Programming" book is very good and compares Clojure to Ruby/Python a lot so it's easier to understand. David Nolan's talk about Om (React wrapper) is pretty awesome and shows the power of Clojure/CLScript. In fact Om is faster than React.js! You can write server and client side apps in Clojure and utilize JVM libraries. Plus it's a very small language but powerful, it's a LISP with no nonsense and production ready. Anyway, check it out. Clojure and Ruby are two of my favorite languages and I actually understand Ruby much better now after playing with Clojure.

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.

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.

[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.

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.

"That's the power and diversity of web programming! As long as it spits out HTML, you can power your server by steamboat, no one knows/cares."

https://twitter.com/dhh/status/576425023222755328

"And it won't solve the problem that the client still needs to be written primarily in Javascript." Nothing's going to solve that. But rails could definitely work on making working with Javascript front ends easier. As great as Sprockets is, it doesn't fit so will in modern JS workflows.

What's their rationale for saying That Node is not ready? I've found it to be stable and performant, and if it doesn't have quite the volume of useful libraries Ruby/Rails does, it's certainly fast approaching.

Rails API and react-rails gem should be good combination.