React frameworks: Redwood vs Blitz
If you want to build and deploy your project quickly, a boilerplate or good framework could help you be more productive. Some days I miss working with Rails, which is why I look forward to working with a React framework like Redwood.js and Blitz.js.
Redwood aims to bring full-stack to the jam stack. It wants to provide a great developer experience and easy scaling. It's built Built on React, GraphQL, and Prisma.
Blitz also calls itself a Fullstack React framework, and is built on top of Next.js (which is built on top of React) and adds cool stuff like a “Zero-API” data layer lets you import server code directly into your React components. It now also comes with auth included.
Both frameworks are not having a 1.0 release and do not recommend using it in production applications just yet, but they both make great progress so that could change very soon.
Would you go for one of these frameworks in the near future? And if so, which one would you choose?
Serious question: why on earth wouldn't you just use Rails?
What is it that you believe you need an SPA for that Rails wouldn't do better?
I only ask because Rails is kicking ass right now. More and more people who were seduced by the React hivemind are waking up to the realization that Rails has always been there for you, getting better all of the time.
I am appalled at the sheer amount of bikeshedding people in the JS world seem willing to do. Would you rather be testing pre-release quality frameworks or shipping features?
Fair point. I’m not saying that they should be compared and I would still totaly go for Rails for a lot of apps, but if you are used to working with React then you might be missing a framework on top of that library. Coming from rails, I like that preople are working towards a framework for React that is in some way inspired by Rails.
Could you explain more about what you mean when you say "missing a framework on top of that library"? After all, React-the-library doesn't provide much more than a structure upon which to build other things.
When you're talking about Rails + StimulusReflex (+ ideally Turbolinks) you don't need anything else that React itself provides. The client is built on Stimulus, so you have a full MutationObserver-driven lifecycle management infrastructure built in. What else are you looking for? Genuinely curious.
StimulusReflex sounds interesting, but I'm not familiar with it. I've not worked with Rails anymore for the last couple of years. At my current company, we have API's that are built as microservices with Go. Most of the frontend applications are in Angular, which is already more feature-rich than React.
What I think is missing from React is a framework that has some similarities as Rails, not as a full-stack framework (wich React of course isn't), but as a design perspective. Currently, when you start a frontend with React you first need to install like 10 other libraries to have things like a router, form validation, and (arguably) global state management, etc. Also, there is not really a standard for a lot of things like how to structure your project for example. Although the flexibility of React is powerful, I think the front-end world could really benefit from a framework built on top of React that has "rails-like" features like scaffolding, build-in features, standardized file storage, and programming conventions.
Next.js is already a very nice framework that handles a loth of things for you like code-splitting, SSR, and routing, but Blitz or Redwood might take this a little further.
Ruby on Rails might be a very good option for a lot of projects, but not all developers have this option. You might work for a company with a different tech-stack or you have a project that requires a lot of JavaScript (and not that much back-end). Not all projects require the same kind of work. When you go for a fronted-end first approach and work with serverless technologies to do some of the back-end stuff, you could benefit a lot from a feature-rich front-end framework that helps you be more productive. Working with serverless services like Firebase or Amplify means you could (also as a "front-end developer") very quickly build a full-stack application and pay only for what you use. This is also great for side-projects that may not get traction. I'm still paying for a Rails app that I host on Heroku and nearly maintain anymore but still don't want to kill it. Going with Serverless services has more benefits, but of course also some drawbacks.
Thanks for the reply.
I'd be genuinely interested for your take on things if you spent a few hours actually building something with StimulusReflex.
We're motivated by the idea that you can't get someone to switch by being 5% better. You have to be several orders of magnitude better. What we're seeing is individual developers able to deliver functionality 4-5x faster than by using either a classic SSR approach or a heavy client-side approach. It's an extraordinary leap, just as Rails was when it came out in 2004.
I'm not here to tell you where to work or whether serverless is the road to hell, paved with good intentions. You are going to feel a strong bias towards whatever you've currently invested yourself in, which is super human of you. :)
I guess my hope is that you - not the ephemeral "all developers" - are a perfect example of someone with just enough Rails knowledge to be dangerous who could be totally blown away by what can be done with StimulusReflex and CableReady. Like, religious conversion level, "what just happened" level excited.
Given that we're already seeing a substantial increase in the number of job postings that mention SR immeditately after Rails and Postgres in the stack description, it's safe to say that even having this conversation is getting a heads up way before most people will be aware.
Again, give it a shot and tell me if you have any questions or ideas. There's a small army of us waiting to help on Discord as well.
Thanks for your explanation. I’m definitely going to check it when I’m having some time!
I'm not sure what the comparison is here - React & Rails are two completely different things.
If we're talking about why should a JS dev not use React + Rails over React + Node, the answer is very clear: using a 100% Javascript stack means working with one language.
Why learn Rails when you can write the backend using the language you already know? Why hire two developers, when you can hire one?
Even on a productivity level, there's no cognitive strain switching between back and front-end. Switching between two different languages is terrible for productivity.
I saw that you asked if StimulusReflex was component-based. If you read the documentation or watch the video I linked to, you'll see that the question doesn't really line up. The whole point is that you don't need any of that stuff.
That said, StimulusReflex has first-class ViewComponent support baked-in, and there is an excellent library called ViewComponentReflex that allows you to easily make ViewComponents that remember their state between updates with zero code.
Furthermore, the client library is built on Stimulus, which is the perfect foundation to build web components, if that's a thing you want. This is precisely how much of Hey.com works, in fact.
Productivity.
I had used Node and various front-end frameworks professionally for years before really digging into Rails. In under 2 weeks, I was more productive with Rails than I'd ever been with Node.
This doesn't make any sense at all. Projects built on MVC frameworks such as Rails, Laravel, Phoenix, etc, generally take fewer developers to get a web app built, not more.
The point I was making was that a single Javascript developer can write and be highly proficient in writing both front-and backend code in a single language.
It’s much harder to find an expert in two completely different languages.
I'd be extremely wary about hiring anybody to write JavaScript for whom learning Ruby would pose any real challenge. The two languages are fairly similar.
Going from JS to Ruby is trivial. Ruby is more self-consistent. Every variable has block scope. Everything, including numbers and string literals is an object, it's thoroughly OO, etc. But in the big scheme of things, they're both flexible, dynamically typed, high-level languages with first-class functions.
Going from Ruby to JS is slightly more difficult due to having to learn about the prototype chain, async, multiple ways of handling scope, etc, but it's still very straight-forward. Learning CSS is a much bigger jump from either JS or Ruby, and yet people seem to manage!
IMO, the real challenge with the same person handling front-end and back-end isn't language semantics. It's other needed skills like database design or how to test responsive layouts.
You're overlooking my original point again, there is no need to go from JS to anything. If you know JS you can write front and backend code by default (with a few additional skills like you pointed out like DB design).
That is a huge benefit for many developers who don't want to learn and keep up to date with two languages and also for many businesses who can hire one developer to do both. There are a lot more Javascript developers than there are Javascript developers who also know Ruby (or any second language).
Adopting a new language may be trivial, becoming an expert, staying up to date and writing consistent high quality code is not trivial - it's a lot of work to stay on top of one language.
But whatever works for you, there's no 100% correct answer here – if you're more productive with Ruby + JS and that works for your business, then that's the best route for you. I used to code in PHP + JS and it wasn't efficient for me, being able to jump between front and backend in the same language is a huge bonus for me and since making the switch, my ability has increased exponentially because I'm 100% focused on Javascript and not using half my time and energy to keep up to speed in developments in the PHP world.
It's worth pointing out the asymmetry here.
While you have a financial interest in getting people to use JS on the back-end (so they can use your product), I have zero financial interest in suggesting Ruby. In fact, all the products I sell are in a different language ecosystem. I'm just trying to offer advice that will help founders get to a win.
I'm not overlooking your point. I just disagree with it. Doing the back-end in JavaScript is generally less productive and means hiring more people to do the same amount of work. I've seen it on multiple teams.
Here's a data point: over half the valuation of top YC startups was from those who built their back-ends in Ruby, even though it was never the most popular language! From what I've read, both in this and other analysis, JavaScript is extremely popular, but using it on the back-end is negatively correlated with startup success.
Again, this strikes me as a bit silly. Why would one have to be an expert in a language in order to write an app in it? Unless it's an exceptionally poorly designed language, that shouldn't be necessary.
If it's "a lot of work to stay on top of one language", then you've probably hired the wrong engineer or chosen an unstable language. In any given week, I work with half a dozen languages and am barely a half-time engineer at this point.
Beware I am not sure you can draw any conclusions from the data in the link.
"self-reported data about technology usage"
"signal score for each startup. it’s not 100% clear what this represents"
Also the goals of startups are to become unicorns.
So you might want to optimise for "OK" as a solo, and choose PHP :-)
The 2nd link is from a VC with skin in the game, so to speak. The data was aggregated from Angel List.
Edit: If you read it, you'll see that an evaluation was made, not just on the frequency of usage but of the general outcome buckets different languages were correlated with. For example, while Node was used more often than Rails, of the % of the times it was used it was less likely to be correlated with "good" or "great" outcomes.
All this says is these languages were popular at that time, which is obviously the case considering Ruby has been around since 2004 and many of these companies were founded prior to 2009 BEFORE Node and React were even created.
This is just turning into a silly 'my programming language is better than yours' debate. All languages have advantages and disadvantages and ultimately the best choice is the one we prefer and that solves our goals effectively.
It might be less productive for you - it’s not for me. You’re preaching personal preferences here 😊
This article is just a list of startups and the languages they used - there’s absolutely no correlation between the language and the startup’s valuation. I’m unsure why you think any customers of these startups could care less what the language used was.
You should reread it. There was an enormous correlation.
Relative productivity across programming languages is a topic that has been studied for decades. The tldr is that language choice matters. Beyond the language itself, tech stacks are something multiple VCs have put a great deal of time into thinking about, including one who funded the company that bought IH.
While I shared some personal experiences, I'm not speaking of my preferences when I'm talking about the productivity of one stack vs another.
I don't think they do. Why would you even suggest that?
My reply was informed at least partially by Jake's own words: he's clearly used Rails in the past and we should all temper our advice based on what the developer in question already knows. I was compelled to reply because Jake's tone implied that Rails was somehow an option that used to exist but doesn't anymore, and so I asked why. I'm sure he doesn't need you to speak for him.
The answer to all of your questions is that Jake could use StimulusReflex to drive all of the reactive behaviour his application requires from the server. StimulusReflex is similar to LiveView (Elixir) and there are comparables in other languages like PHP as well. They all use websockets to deliver state transformation instructions to the client in realtime, making the whole idea that you would need two developers, two teams, a separate front-end and back-end all completely unnecessary.
If you've looked at or used the recently released Hey.com email service, you'll be familiar with the power of this approach - it downloads faster, there is no render process, no abstraction, no virtual DOM. All of the complexity that comes from attempting to manage and synchronize state between the client and server are completely eliminated. If you consider that ~80% of the effort put into web development these days seems like it's all about state, you understand why folks using Rails with StimulusReflex are freaking out because they are cranking out features 4-5x faster.
So, to be clear: if Jake was not already a Rails developer, I'd probably tell him to use Express and something like SR but based in JS. However, if he's already part of our community, there's no good reason to even consider starting a React project at this point.
Jake: there's a popular video showing a quick build here: https://www.youtube.com/watch?v=F5hA79vKE_E and you can get 24/7 support on Discord: https://discord.gg/XveN625
This comment was deleted 4 years ago.
Too tightly coupled?
I do think API-less is a great innovation for prototyping CRUD apps, especially for front-end devs who are not familiar with the backend.
However, there are just too many risks involved – what if I run into an unforeseen limitation with the framework?
For eg, what if I want to introduce some machine learning into my app, will the framework support it or will I end up refactoring everything to run on a traditional setup with backend server?
I'm not sure if either of these frameworks support it or not, but accessible API's are a core feature in most applications, having the API intertwined with client components is an extremely limiting structure.
With a traditional setup with backend + API + database I know that I can pretty much do anything I need to and I'm not going to hit any restrictions.
The traditional client - API - backend structure is going to be around for a long time, it's reliable and widely adopted. The risk with taking a very niche approach to app structure is these frameworks may no longer be supported in 3 years. React, Node & Express are well established and will be around for the foreseeable.
I think two very important questions on day one that people often don't think about in the excitement of making something is: will this scale effectively and how much technical debt will I create?
Its opensource
I use Gravity, made by @kylegawley. It's been extremely versatile and trustworthy, well past a 1.0 release. I personally like MySQL, so it worked well for me
Thanks Dave! :-)