For further actions, you may consider blocking this person and/or reporting abuse
Read next
Github's Top 36 items of Dec 19, 2024
Gittech -
Understanding Java Strings: A Comprehensive Guide
Bharath S R -
Learn How to Create Responsive Admin Dashboard Using HTML CSS & JavaScript
sharathchandark -
Building a Nickname-Based Crypto Transfer Service Like WhiteBIT's QuickSend: A Developer's Guide
Kaan Kaya -
Top comments (56)
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 💜
Some comments may only be visible to logged-in visitors. Sign in to view all comments.