Hello, World! I'm jzombie, a passionate software developer with a knack for problem-solving and a love for open-source. I believe in the power of code to change the world and make our lives easier.
It's pretty easy to point out what's wrong with Rails, but it's still so well loved for a reason. People who get used to working in it tend to be very productive and happy.
Hello, World! I'm jzombie, a passionate software developer with a knack for problem-solving and a love for open-source. I believe in the power of code to change the world and make our lives easier.
I develop a lot w/ JS and I think the cons are rooted in so many libraries defining their own ad-hoc type systems (i.e. JS itself [and TypeScript] one way, Apollo [GraphQL] another way, React prop-types another way, any object validation tool another way, etc.).
I'm speaking generally to Rails not coming up in an era where, say, GraphQL exists. Sure, there is plenty of support here, but there are also frameworks which really build around this technology as a first-class citizen.
I think it's the general downfall of being around longer and having to support more things. If you really want to go in on a more novel approach to web app development, you may want to go with something that is really designed directly to build around that approach.
I'm a Rails dev myself, full stop, but it's very much general purpose, and if you know you have a need for a different approach that's going to get support from the whole ecosystem, you may want to look elsewhere.
I have been slowly heading from haskell -> scala -> golang (~ few months) -> rails API (this month) over the last six years. I don't see graphql's applicability to a typical backend for frontend scenario. I think its great for build a public facing API, if you are building an API product, where you don't have access to all your potential clients. I may be proved wrong though. So, I don't see anything really missing in the default Rails API approach.
I am slightly concerned that the default recommendation is Turbo, rather than emphasizing React + Rails API, but I don't think it matters that much.
I am slightly concerned that the default recommendation is Turbo
I'm especially concerned given the last point of "DHH drama" since Turbo is still pretty darn immature. It's so much still his pet project and it's just not great if the community isn't acting in a super cohesive way on these things.
Of course, all the stakeholders in Rails aren't going to let this become that much of an actual problem, but it still poses a risk to the direction of the ecosystem. I'd like to think everyone is rowing in the same direction, but I'm not sure that's totally happening at the moment.
On the plus side, I was skeptical about turbo working out well on a static site and it has performed well, decent lighthouse scores. I know static sites are a niche area relative to a regular web UI frontend.
Rails is in this cosy place where it's well established, and the pros outweigh the cons by a lot in terms of productivity, but it's also very boring because of this.
Personally I like working with rails at work, but I'd rather learn COBOL than use it for any personal project just for how amazingly uninteresting it is. At every step it keeps you from making exciting, but also irresponsible decisions.
The danger, I think, lies in confusing these two aspects. Nobody should want an "exciting" tech stack at work. The less surprises, the better, really.
I love Rails, its what kickstarted my web dev career. I also really prefer using true intellisense, and I think the Rails "magic" gets in the way of that. I still think we can make a good intellisense tool for Rails, using static analysis, (sorta like rust-analyzer)
I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
embrace what Rails is and isn't and build a "majestic monolith"
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.
When I see a new and interesting technology and whether I want to get involved for the novelty of what's possible, I think of "flash intro pages" as my go-to "using this, even if it is popular, may be the wrong idea".
Many dev hours were lost creating awful experiences for the novelty of it all.
I always wanted to try solid, but until now the support for third party libraries prevented me. In React, I especially enjoy that using mui, I can easily import any icon and lots of nicely styled components. Is there something similar in solid?
Also, some people are currently trying to revive jscodeshift with a react-to-solid codemod. I don't know about their current state, but have heard that they successfully shifted a medium-sized app with minimal manual intervention.
In general, habits/instincts are muscle memory. Something done or thought often enough that your brain develops an "integrated circuit". So you can perform that task faster or have a strong instinct about new information, without resorting to slow, logical thinking. (See Thinking, Fast and Slow.) OO has a bit of ceremony (especially typed) and some common footguns. So years into a career many of these instincts are heavily reinforced. Becoming a barrier to learning other ways of doing things.
strong but unnecessary instinct to "protect" data at every step
OO principles lead us to divide and distribute mutable state across many objects. It doesn't take a new dev long to figure out that uncontrolled access to data is a footgun. Behaviors can be easily broken (and hard to trace) at runtime if data they depend on is changed by outside code. So out of necessity, we develop the instinct to protect data. To tightly control changes to object state through object behaviors. (Curiosity: is most OO code about data protection?)
This instinct is necessary because state is mutable. The thing about instinct is it doesn't have nuance unless the experiences that built it highlight that nuance. So when I first tried FP I could not figure out how to code in a way that felt safe or "right". It took a while and a lot of partially-OO F# code to make mutability a pre-condition to that data protection instinct.
difficult to mentally separate data and behavior
The previous point is a strong motivator for packaging data and behavior together. But the principles of OO also lead us there. Encapsulation and information hiding to start. Liskov (L in SOLID). And many OO "code smells":
data classes - Note: a common exception is a DTO (Data Transfer Object) for reading/writing wire formats.
switch statements - It is common to have data that can be one of several choices. Example: Payment can be Cash, Check with number, CreditCard with number and expiration, etc. A good way to represent that is with an abstract class and shallow inheritance data classes. To extract data, it is necessary to use a switch statement on object type. Considered bad practice in OO but fine in FP.
Overall, the instinct developed is that data doesn't belong on its own. In fact, many OO languages like C# encode this in the language -- data can only be defined as part of a class or object *.
*C# only recently added records, which are meant to be data only. Both C# and F# records use classes under the covers. They also expose data not as Fields but as Properties -- syntactic sugar for getter/setter methods over private data. Probably this design is for best compatibility with existing .NET tools/libraries/runtime primitives. Point being it's still deeply ingrained. Struct has been available for a while, but in .NET it is also class-shaped (constructor, methods, properties, etc.), and you don't want to use it as the default data container due to its runtime characteristics (stack allocated).
Thank you so much for the full response! This data over protection angle is an interesting one that I had not heard in quite the way you are putting it.
I've also seen people get really hung up by validation when switching from OO. Because we're accustomed to using the same mechanisms to "protect invariants" as we do to defend mutable data. We can intercept every new object (in constructor) and data change (in methods) to protect those invariants. Coming to FP and records, consumers set the data directly. Specifically in F#, record constructors and the built-in update syntax are not interceptable. So when someone suggests "just make a validation function", this feels like it can't possibly be sufficient by comparison.
But it is. And it is a cleaner separation of concerns. Sometimes consumers want the ability to use invalid data. Like representing what the user typed, even when its not yet fit for submission. I can use the validation function to make sure invariants hold. Without having to care how it was constructed or changed before it got to me. The consumer can also use this function to know if it's Ok to send.
Big fan of Laravel. For about 99% of what I need to do, it's incredibly simple and intuitive to use. I don't use many of it's "killer" features, but that's probably because I'm a little old-school with some things in that I prefer to know how something works rather than remember "these commands perform this type of magic". I've used a lot of PHP frameworks in my time (CodeIgniter, Symfony, Zend, Cake, Slim) and I would rather Laravel any day of the week.
Porting Laravel to other languages won't make much sense because all these languages are quite different compared to PHP. Laravel is in fact inspired by the most popular Ruby framework, Ruby on Rails, so in that case you would kinda repeat the similar thing but in a bit different way. Framework should closely follow the philosophy of a language it's written in.
(Loggedin to this account after so long time, just to reply on this)
I've used quasar extensively with vue2 in almost all of my projects, It made me fall in love with vue. Everything just became so easy.
I still don't hear much about quasar even after they release big update with vue3. It is still so unknown to even vue community.
One Con i found out after using quasar for almost a whole year, is that I cannot use anything other thn quasar to build vue apps, like I just cannot, to me after a year it seems like quasar was the default vue thing. (ps: quasar is just a layer on vue and everything is basically vue syntax and nothing else I'm talking about UI and components side of things, I literally forgot how to build some component like text / image because I was in love with quasar components) lol
I spent several years working with Ionic Framework and became a big fan of their solution for building PWAs and Mobile Apps
Pros
Well thought UX for the UI Components. If you use them properly, it creates a very fluid experience in the browser.
Progressive Web App & Mobile-first design
Strongly Typed
Able to package the same web application into a native mobile app binary
Large community and ecosystem
Cons
Front-end only
Mobile-first design is more like mobile-only design. I had to inject code to read the User Agent and swap out a base layout between web and mobile to have more usable interfaces between the two display types.
Sometimes, you have to dive into other programming languages to solve lower-level problems inside plugins
You can programmatically generate really streamlined, thin text content that runs fast over traditional node hops or through a CDN
Much easier to support a wide spread of devices
IF and only IF any CGI request inputs are sanitized and heavily monitored, it's a lot cleaner and more secure than having Javascript run clientside
No JS framework or dependencies oftentimes == No CORS to deal with
Low-quality images for overview, hiding full-scale content behind a click or a CSS blur, means that average scrollers on a site will cost less data and take less time for FCP (First Contentful Paint)
No frontload of JS for the client to process on first visit - esp when SPA's are concerned - means no Flash of Unstyled Content (often known by other names)
Cons:
Basically relegates all meaningful processing power to the server
Dynamic content isn't really a thing; you'd either have to pre generate next possible page visits per-user based on their last GET request, or generate on the fly and increase processor burst
Not gonna look near as fancy as you can make things with a good JS/SASS setup
CSS can make things -look- like an SPA, but you can't make it -work- quite like one without some decent clientside scripting; no more "Add this website to your home screen!"
Analytics won't be nearly as helpful; you'll only really get a drilldown on common user paths and link referrals.
Advertisements will probably be noticeably slower than the rest of the page, and that looks even uglier than ads normally do. Assuming they work at all on a fairly JS-less site.
Improved performance (every new version gets faster than the last one)
Cross platform
A ton of libraries and packages to do pretty much anything( which can target multiple platforms)
Open Source
New version (6+ ) have Minimal APIs
Multiple releases (LTS every 3 years and every year we get new versions with new features)
It simply has the Best Documentation out there.
Cons
Since it's a Microsoft product they pretty much control everything that goes into it.
Alot of dependency on Microsoft packages (which is a good thing a single source of truth) but some good open source packages never get the limelight (just to mention ABP framework)
Microsoft doesn't have a good reputation in the open source community but atleast .Net Foundation is changing the narrative.
For C#:
Null checking is getting bloated (too many ways of getting nulls resulting in more features to check null)
Was once on par with Muhammad Ali in popularity and strength
Version 2 broke out of taking Javascript hostage
Made Component creation easy
Refined continually
TypeScript friendly
Cons:
Like Mohammed Ali became old
Best developers left
Slow to make deep required changes. They implemented many things now native in Javascript but didn't obsolete them. Their framework now clashes with current Javascript standards, such as 'modules'
Although there are lots of packages (with access to the Erlang ecosystem too). Still behind from JS or Rails ecosystem. Nonetheless it worth it for the Pros.
Created my own BLOC based JS framework to create webcomponent.
(Search for bloc-them in npmjs)
It's based on lit-html for creating HTML templates.
Pros:
Reactive
I know every bolt of my framework.
No need to search stack overflow.
Continuous improvement have made it much more better than any framework.
Easiest framework (its a relative term)
Fast enough to cater all my needs.
Uses BLOC based approach.
Based on HTML standard: webcomponents. Unlike JSX which is not HTML standard.
Cons:
Only I use it in the industry,for my own business.
None.
Pros: Small size. Fast. Not over engineered. Breaking changes are rare. Learning curve shorter than other frameworks.
Cons: You might need to reinvent a wheel or 2.
Ruby on Rails
Pros
Cons
Do the cons outweigh the pros? They sound pretty hard hitting.
It's pretty easy to point out what's wrong with Rails, but it's still so well loved for a reason. People who get used to working in it tend to be very productive and happy.
I was mostly curious is all.
I develop a lot w/ JS and I think the cons are rooted in so many libraries defining their own ad-hoc type systems (i.e. JS itself [and TypeScript] one way, Apollo [GraphQL] another way, React prop-types another way, any object validation tool another way, etc.).
I don't understand this one - reference to isomorphic, blitz, serverless, something else?
I'm speaking generally to Rails not coming up in an era where, say, GraphQL exists. Sure, there is plenty of support here, but there are also frameworks which really build around this technology as a first-class citizen.
I think it's the general downfall of being around longer and having to support more things. If you really want to go in on a more novel approach to web app development, you may want to go with something that is really designed directly to build around that approach.
I'm a Rails dev myself, full stop, but it's very much general purpose, and if you know you have a need for a different approach that's going to get support from the whole ecosystem, you may want to look elsewhere.
I have been slowly heading from haskell -> scala -> golang (~ few months) -> rails API (this month) over the last six years. I don't see graphql's applicability to a typical backend for frontend scenario. I think its great for build a public facing API, if you are building an API product, where you don't have access to all your potential clients. I may be proved wrong though. So, I don't see anything really missing in the default Rails API approach.
I am slightly concerned that the default recommendation is Turbo, rather than emphasizing React + Rails API, but I don't think it matters that much.
I'm especially concerned given the last point of "DHH drama" since Turbo is still pretty darn immature. It's so much still his pet project and it's just not great if the community isn't acting in a super cohesive way on these things.
Of course, all the stakeholders in Rails aren't going to let this become that much of an actual problem, but it still poses a risk to the direction of the ecosystem. I'd like to think everyone is rowing in the same direction, but I'm not sure that's totally happening at the moment.
On the plus side, I was skeptical about turbo working out well on a static site and it has performed well, decent lighthouse scores. I know static sites are a niche area relative to a regular web UI frontend.
Rails is in this cosy place where it's well established, and the pros outweigh the cons by a lot in terms of productivity, but it's also very boring because of this.
Personally I like working with rails at work, but I'd rather learn COBOL than use it for any personal project just for how amazingly uninteresting it is. At every step it keeps you from making exciting, but also irresponsible decisions.
The danger, I think, lies in confusing these two aspects. Nobody should want an "exciting" tech stack at work. The less surprises, the better, really.
I'm not in the loop regarding this one - can you give more details about that?
Edit: Okay, I saw your comment below now. I think Elm community has similar issue now because of it's author.
I love Rails, its what kickstarted my web dev career. I also really prefer using true intellisense, and I think the Rails "magic" gets in the way of that. I still think we can make a good intellisense tool for Rails, using static analysis, (sorta like rust-analyzer)
What is the work around for this? Multiple Rails apps a al microservices, if the app grows?
I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.
FYI:
Bring Clarity To Your Monolith with Bounded Contexts (2016; YouTube)
Flash
Pros
Cons
Ok, Flash isn't my preferred web tool, but I do have some nostalgia sometimes as making games with it taught me programming.
When I see a new and interesting technology and whether I want to get involved for the novelty of what's possible, I think of "flash intro pages" as my go-to "using this, even if it is popular, may be the wrong idea".
Many dev hours were lost creating awful experiences for the novelty of it all.
Flash got me started in my programming career 😁
2 words: Stick Fight
This the right answer :D.
Solid.js
Pros
<div>in your JSX is just a<div>in the DOMCons
I always wanted to try solid, but until now the support for third party libraries prevented me. In React, I especially enjoy that using mui, I can easily import any icon and lots of nicely styled components. Is there something similar in solid?
Also, what's your favorite GraphQL client?
There's SUID, which is MUI for Solid.js (there are a few others, like solid-headless or hope-ui) and for GraphQL, there's @solid-primitives/graphql and solid-urql; currently, the Solid Community has a Hackathon, which might turn out even more solutions.
Also, some people are currently trying to revive jscodeshift with a react-to-solid codemod. I don't know about their current state, but have heard that they successfully shifted a medium-sized app with minimal manual intervention.
F# MVU, front and back. More of a pattern than a framework.
Pros
expected = actualfor decided state+side-effectsDataLoaded ...,SaveClickedCons
Great features!
Can you elaborate on why the normal dev struggles with these 2?
Elaborate, I shall!
In general, habits/instincts are muscle memory. Something done or thought often enough that your brain develops an "integrated circuit". So you can perform that task faster or have a strong instinct about new information, without resorting to slow, logical thinking. (See Thinking, Fast and Slow.) OO has a bit of ceremony (especially typed) and some common footguns. So years into a career many of these instincts are heavily reinforced. Becoming a barrier to learning other ways of doing things.
OO principles lead us to divide and distribute mutable state across many objects. It doesn't take a new dev long to figure out that uncontrolled access to data is a footgun. Behaviors can be easily broken (and hard to trace) at runtime if data they depend on is changed by outside code. So out of necessity, we develop the instinct to protect data. To tightly control changes to object state through object behaviors. (Curiosity: is most OO code about data protection?)
This instinct is necessary because state is mutable. The thing about instinct is it doesn't have nuance unless the experiences that built it highlight that nuance. So when I first tried FP I could not figure out how to code in a way that felt safe or "right". It took a while and a lot of partially-OO F# code to make mutability a pre-condition to that data protection instinct.
The previous point is a strong motivator for packaging data and behavior together. But the principles of OO also lead us there. Encapsulation and information hiding to start. Liskov (L in SOLID). And many OO "code smells":
Overall, the instinct developed is that data doesn't belong on its own. In fact, many OO languages like C# encode this in the language -- data can only be defined as part of a class or object *.
* C# only recently added records, which are meant to be data only. Both C# and F# records use classes under the covers. They also expose data not as Fields but as Properties -- syntactic sugar for getter/setter methods over private data. Probably this design is for best compatibility with existing .NET tools/libraries/runtime primitives. Point being it's still deeply ingrained. Struct has been available for a while, but in .NET it is also class-shaped (constructor, methods, properties, etc.), and you don't want to use it as the default data container due to its runtime characteristics (stack allocated).
Thank you so much for the full response! This data over protection angle is an interesting one that I had not heard in quite the way you are putting it.
You are welcome.
I've also seen people get really hung up by validation when switching from OO. Because we're accustomed to using the same mechanisms to "protect invariants" as we do to defend mutable data. We can intercept every new object (in constructor) and data change (in methods) to protect those invariants. Coming to FP and records, consumers set the data directly. Specifically in F#, record constructors and the built-in update syntax are not interceptable. So when someone suggests "just make a validation function", this feels like it can't possibly be sufficient by comparison.
But it is. And it is a cleaner separation of concerns. Sometimes consumers want the ability to use invalid data. Like representing what the user typed, even when its not yet fit for submission. I can use the validation function to make sure invariants hold. Without having to care how it was constructed or changed before it got to me. The consumer can also use this function to know if it's Ok to send.
I thought this might be underlying what you were saying, that makes great sense.
Laravel
Pros
Cons
Big fan of Laravel. For about 99% of what I need to do, it's incredibly simple and intuitive to use. I don't use many of it's "killer" features, but that's probably because I'm a little old-school with some things in that I prefer to know how something works rather than remember "these commands perform this type of magic". I've used a lot of PHP frameworks in my time (CodeIgniter, Symfony, Zend, Cake, Slim) and I would rather Laravel any day of the week.
oh come on, you cannot expect packages that was made for laravel to be used on non-laravel project.
I personally would try Laravel if it were ported to Python, Ruby, or Go.
Porting Laravel to other languages won't make much sense because all these languages are quite different compared to PHP. Laravel is in fact inspired by the most popular Ruby framework, Ruby on Rails, so in that case you would kinda repeat the similar thing but in a bit different way. Framework should closely follow the philosophy of a language it's written in.
Try Masonite :) is super similar to Laravel in Python
Been using a lot of Remix lately.
Pros:
Cons:
(just created an account to comment on this, because im in love with this framework and I always wonder why its so unknown and not much talked about)
Quasar
quasar.dev
Vue3 based frontend application framework
Pros
Cons
If anyone knows Quasar I would be interested in other opinions. Am I missing something?
(Loggedin to this account after so long time, just to reply on this)
I've used quasar extensively with vue2 in almost all of my projects, It made me fall in love with vue. Everything just became so easy.
I still don't hear much about quasar even after they release big update with vue3. It is still so unknown to even vue community.
One Con i found out after using quasar for almost a whole year, is that I cannot use anything other thn quasar to build vue apps, like I just cannot, to me after a year it seems like quasar was the default vue thing. (ps: quasar is just a layer on vue and everything is basically vue syntax and nothing else I'm talking about UI and components side of things, I literally forgot how to build some component like text / image because I was in love with quasar components) lol
I spent several years working with Ionic Framework and became a big fan of their solution for building PWAs and Mobile Apps
Pros
Cons
None,
and/or static sites with CGI requests.
Pros:
Cons:
Okay, so I already gave an answer for the back-end, but I feel like talking about front-end as well, so here goes:
My own JS micro-framework
(Yes, I like reinventing the wheel)
Cons
Pros
ProxyorReflectMeta-programming is fun 💜
Angular
Pros
Cons
DotNet
Pros
Cons
For C#:
Aex
Pros
Cons
Looks like this is brand new, can you elaborate on it?
Angular
Pros:
Cons:
Phoenix Framework
phoenixframework.org/
Pros
Cons
Slim
Pros
Cons
Created my own BLOC based JS framework to create webcomponent.
(Search for bloc-them in npmjs)
It's based on lit-html for creating HTML templates.
Pros:
Reactive
I know every bolt of my framework.
No need to search stack overflow.
Continuous improvement have made it much more better than any framework.
Easiest framework (its a relative term)
Fast enough to cater all my needs.
Uses BLOC based approach.
Based on HTML standard: webcomponents. Unlike JSX which is not HTML standard.
Cons:
Only I use it in the industry,for my own business.
My own, Lua-based abomination
Cons
Pros
At work I use Rails, but there's really nothing to say about rails. It works. It's good. It's boring.
None.
Pros: Small size. Fast. Not over engineered. Breaking changes are rare. Learning curve shorter than other frameworks.
Cons: You might need to reinvent a wheel or 2.
Pros
Cons
thanks for the article