Nice post, Gabriel. You touch on very interesting points and I can relate to several of them.
In the same line of full-stack frameworks, and similar to the direction taken by Blitz.js, have you tried RedwoodJS? I went through their project tutorial and had it (almost) completed; it looks promising to me, although there's still a learning curve, as in any other framework, maybe less related about specific technologies, but more related to architecture, structuring and high-level decisions.
I wonder if that's one of the reasons that would push people away from embracing a full-stack framework or platform (and me, from completing the tutorial... :P), opposed to just write some React code, and make some web requests, and, you know, make it work. You mention "Lack of Conventions" as a main disadvantage, but I wonder if that's actually appealing to some developers, specially the ones not familiarized with the hurdles of backend work.
I run technology at Ingenious, an agency specializing in building products for the healthcare industry. 💛 remote work ‧ sometimes 🔨 are the best tool for the job.
Thanks Esteban, I'm glad you liked it! I haven't tried RedwoodJS (neither Blitz.js tbh), but I know the big picture.
I understand structure and conventions may push back some people, but honestly, if you are doing any decent sized app you will need to come up with structure yourself. The debate is not no-structure vs Redwood structure (or rails or Blitz), but your own clunky structure vs a tested one.
Of course if the app is small, then maybe no-framework is the best framework, but when there's more than one dev on the team -even on small apps- structure and conventions make a huge difference.
A word on the difference between RedwoodJS and Blitz.js, and why I mention the later. I think Blitz enhances the idea of a monolith making the API you call from React to your controllers an implementation detail. It has an API, but it looks you are calling a node method. This fuzzes the client-server line, same as django or rails does with the view layer, where you can declare a variable in the controller and access it in a template.
For me, this thinking produces a faster development experience, you are not required to think where in the stack you are, you have less moving pieces resulting in less information in your head. I think I cover some of that on my previous post telling how we currently think at Ingenious.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice post, Gabriel. You touch on very interesting points and I can relate to several of them.
In the same line of full-stack frameworks, and similar to the direction taken by Blitz.js, have you tried RedwoodJS? I went through their project tutorial and had it (almost) completed; it looks promising to me, although there's still a learning curve, as in any other framework, maybe less related about specific technologies, but more related to architecture, structuring and high-level decisions.
I wonder if that's one of the reasons that would push people away from embracing a full-stack framework or platform (and me, from completing the tutorial... :P), opposed to just write some React code, and make some web requests, and, you know, make it work. You mention "Lack of Conventions" as a main disadvantage, but I wonder if that's actually appealing to some developers, specially the ones not familiarized with the hurdles of backend work.
Thanks Esteban, I'm glad you liked it! I haven't tried RedwoodJS (neither Blitz.js tbh), but I know the big picture.
I understand structure and conventions may push back some people, but honestly, if you are doing any decent sized app you will need to come up with structure yourself. The debate is not no-structure vs Redwood structure (or rails or Blitz), but your own clunky structure vs a tested one.
Of course if the app is small, then maybe no-framework is the best framework, but when there's more than one dev on the team -even on small apps- structure and conventions make a huge difference.
A word on the difference between RedwoodJS and Blitz.js, and why I mention the later. I think Blitz enhances the idea of a monolith making the API you call from React to your controllers an implementation detail. It has an API, but it looks you are calling a node method. This fuzzes the client-server line, same as django or rails does with the view layer, where you can declare a variable in the controller and access it in a template.
For me, this thinking produces a faster development experience, you are not required to think where in the stack you are, you have less moving pieces resulting in less information in your head. I think I cover some of that on my previous post telling how we currently think at Ingenious.