Hey there,

Mia && Trinity here from railsnew.io.

It’s been a while since our last update! We wouldn’t blame you for thinking, ‘oh well, yet another mailing list I signed up to, just to witness the project go Tango Uniform.’ There’s some truth to it, but fortunately, it’s far from the reality! So what’s going on?

The Past: Humble Beginnings

The original project is indeed dead (although still living at railsnew.io at the time of writing this email - to be replaced by v2.0 soon!). It was a Vue/Nuxt setup, cobbled together in a few days. While Nuxt was great to quickly hit the ground running, it all went to hell fast! To put it mildly, the code quality turned out to be utter crap by the time we got to the public release:

• no architecture - just haphazard “if the user clicks this checkbox/radio button, do that“ pieces of spaghetti code sprinkled all over various components
• no tests - “hey, I can just click around and see if things work” (until there were too many components to click)
• no refactoring - “it’s a weekend fun project, we won’t touch it again” (except, that turned out to be false)
• no code reviews - see above

Disclaimer: none of the above was caused by choosing Vue/Nuxt/Javascript per se. Gung-ho “there’s no tomorrow“ cowboy coding would have resulted in a similar mess, regardless of the language/framework.

Anyways… As a result, we have reached a point where

• random, one-off bugs started popping up
• it was challenging to add new RailsBytes
• it was difficult to add new features confidently (i.e., without the fear of breaking things)
• since there were zero tests, refactoring was somewhere between difficult and impractical

The original setup served us well to validate the idea and push out something quickly, but it was not a solid base to continue building on. Thus, we decided that scrapping the current codebase and starting from scratch was the right course of action! Enter…

The Future: railsnew.io on Rails

We decided to rewrite the app with Rails. Thanks to railsnew.io, we were up and running in a couple of clicks 😂.

To be honest, we were not 100% sure Rails was the best choice. For a heavily UI-focused application (especially without a backend), Vue/React seems like the ideal framework - and we should always use the best tool for the job, right?

A couple of weeks later, having achieved feature parity with the original version, we can confidently say that Rails *was* a solid choice, even without a backend (and it becomes a no brainer once we’ll add one).

For now, we didn’t need anything more than Turbolinks + Stimulus. We have also used ViewComponent, which we found to be an excellent fit for our app (the jury is still out whether ViewComponent should replace the good ol’ ActionView in general - but that’s a discussion for a different day). ViewComponent really shines when it comes to testing. We have dozens of component tests with hundreds of assertions, testing all nooks and crannies - and the test suite takes less than 1 second to run!

We have many system tests, which are way slower (although, without a model layer, still very fast). However, knowing that the component tests take care of various edge cases, we could concentrate on testing the bare minimum there, mostly concerned with user interaction.

All in all, it was a great experience to implement railsnew.io with Rails, and the next time, we would not hesitate to pick Ruby on Rails for a similar project. It didn’t feel any less ‘modern’, clumsy, or slow than Vue/Nuxt.js - and we got to write Ruby rather than Javascript (except the Stimulus controllers, obviously - but those were not too bad either.) Massive win in our book!

What’s Next

We need to tie up some loose ends, finish a couple of minor bugs, add some polish aaaand… we are ready to switch over! If nothing goes horribly wrong, the new version should hit railsnew.io before Xmas.

Once that happens, we will concentrate on adding a lot of new RailsBytes (with the current architecture, it’s going to be relatively simple/fast). However, there’s a limit to the number of RailsBytes we can realistically add, for a simple reason: combinatorial explosion! We need to create a new RailsByte for EVERY possible combination of the offered choices. It might not seem a lot, but we did the math and found out that a few dozen RailsBytes would yield hundreds of thousands of combinations! Obviously, that’s not feasible to create/maintain/support!

Thus, we will limit the number of ‘classic’ RailsBytes that can be added - the usual suspects like Stimulus (Reflex), Tailwind, Devise, Redis, etc.

But what about the frameworks/configs/tools that won't make the cut?

To address that, we will create a ‘custom setup’ section. It won’t generate the `rails new` command line in real-time. However, you'll be able to add many more things (potentially including custom content, not just RailsBytes or otherwise pre-configured snippets). These will be stored under your account on railsnew.io (so at that point, a backend/need for user registration will enter the picture). As a nice side effect, you'll be able to load/share these setups.

Another area we are thinking about is deployment. Let’s face it: deploying Rails applications is still a pain in 2020. With this feature, you should be able to

• provision a new Digital Ocean VPS
• set up a couple of things (public IP, ssh keys, `rails secret` and such)
• deploy your brand new app to your VPS - with all the bells and whistles, like domain name && SSL setup a real site needs.

And finally, we’d like to implement CI/CD setup. The ultimate goals of railsnew.io are:

• minimize the need to configure the new app (d’oh)
• eliminate boilerplate as much as possible
• set up remote infrastructure
• create a stable development environment

CI/CD is part of the last point: pushing your code -> running the tests and other checks (Rubocop, brakeman, etc.) -> merging your changes is a huge productivity boost in our experience.

As usual - let us know if you have any feedback - ideas, comments, bug reports, feature requests, etc.

Until next time,
Mia && Trinity