DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Pitch me on the pros and cons of your preferred web app framework
Ben Halpern
Ben Halpern

Posted on

Pitch me on the pros and cons of your preferred web app framework

Top comments (59)

Collapse
ben profile image
Ben Halpern Author

Ruby on Rails

Pros

  • Mature and established
  • Strong track record of launching very productive/successful companies
  • Driven by convention over configuration for fast productivity
  • Backed by highly expressive Ruby language
  • Works with pretty much any strategy for frontend β€” generally flexible
  • Has kept up with the times and stayed innovative as an environment
  • Great community

Cons

  • Conventions can be "magical" and hard to understand/debug at first
  • Not very modular
  • Must support lots of huge/established use cases, meaning some legacy cruft
  • Ruby is not very memory efficient or fast
  • Not "native" to some cool new ways of building web apps
  • Drama with creator DHH is concerning for stability and progress
Collapse
jzombie profile image
jzombie

Do the cons outweigh the pros? They sound pretty hard hitting.

Collapse
ben profile image
Ben Halpern Author

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.

Thread Thread
jzombie profile image
jzombie • Edited on

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.).

Collapse
codewander profile image
codewander

Not "native" to some cool new ways of building web apps

I don't understand this one - reference to isomorphic, blitz, serverless, something else?

Thread Thread
ben profile image
Ben Halpern Author

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.

Thread Thread
codewander profile image
codewander

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.

Thread Thread
ben profile image
Ben Halpern Author

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.

Thread Thread
codewander profile image
codewander • Edited on

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.

Collapse
stojakovic99 profile image
Nikola StojakoviΔ‡ • Edited on

Drama with creator DHH is concerning for stability and progress

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.

Collapse
faraazahmad profile image
Syed Faraaz Ahmad

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)

Collapse
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

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.

Collapse
codewander profile image
codewander

Not very modular

What is the work around for this? Multiple Rails apps a al microservices, if the app grows?

Collapse
ben profile image
Ben Halpern Author

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.

Thread Thread
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

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.

Thread Thread
codewander profile image
codewander

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.

Collapse
peerreynders profile image
Collapse
auroratide profile image
Timothy Foster

Flash

Pros

  • Enhance your website with rich beautiful vector-based animations!
  • Create fancy video games that integrate directly on the web!
  • Play multimedia such as video!

Cons

  • something something security
  • I guess you can do all this stuff without Flash nowadays
  • Oh yeah and it isn't supported in any browser anymore πŸ™ƒ

Ok, Flash isn't my preferred web tool, but I do have some nostalgia sometimes as making games with it taught me programming.

Collapse
ben profile image
Ben Halpern Author

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.

Collapse
arjenpostma profile image
Arjen Postma

Good times! I miss the good old days of making games in Flash. Like you, I also learned programming with Flash.

Collapse
jamesthomson profile image
James Thomson

2 words: Stick Fight

Collapse
michaelbrooks profile image
Michael Brooks

Flash got me started in my programming career 😁

Collapse
karandpr profile image
Karan Gandhi

This the right answer :D.

Collapse
lexlohr profile image
Alex Lohr

Solid.js

Pros

  • Achieve performance with ease
  • Isomorphic JavaScript - write once, deploy + run everywhere, from static server-generated pages to full-blown desktop apps
  • Elegant fine-grained reactive state management - without hook rules!
  • Minimal package size, fully tree-shakeable
  • Welcoming and helpful community
  • Growing ecosystem with a choice of rather high-quality primitives and components
  • Support for SSR/hydration/streaming
  • No superfluous arbitrary vDOM abstraction with reconciliation, <div> in your JSX is just a <div> in the DOM
  • Debuggable output code (you can use your normal dev tools)
  • Feature-complete with Fragments, Portals, Context, Suspense, etc.

Cons

  • Does not support older browsers (w/o support for Proxies)
  • Reactivity breaks on destructuring
  • Due to a limitation of babel, source maps are incomplete, so line coverage cannot be collected by unit tests
  • You will like other frameworks less after trying it
Collapse
peteole profile image
Ole Petersen

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?

Collapse
lexlohr profile image
Alex Lohr • Edited on

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.

Collapse
michaelbrooks profile image
Michael Brooks

Laravel

Pros

  • Mature and established
  • Fantastic documentation
  • Fantastic and welcoming community
  • Always evolving with many great tools and libraries
  • Uses PHP which is a long and well established language

Cons

  • There can be a lot of "magic" happening which can be hard to understand/debug
  • Very opinionated which makes it hard to break out of some conventions
  • Many Laravel packages can't be used on non-Laravel PHP projects
  • Uses PHP has been given a bad image
Collapse
ashleyjsheridan profile image
Ashley Sheridan

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.

Collapse
dendihandian profile image
Dendi Handian

Many Laravel packages can't be used on non-Laravel PHP projects

oh come on, you cannot expect packages that was made for laravel to be used on non-laravel project.

Collapse
codewander profile image
codewander

Uses PHP has been given a bad image

I personally would try Laravel if it were ported to Python, Ruby, or Go.

Collapse
stojakovic99 profile image
Nikola Stojaković

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.

Collapse
clsource profile image
Camilo

Try Masonite :) is super similar to Laravel in Python

Collapse
kspeakman profile image
Kasey Speakman • Edited on

F# MVU, front and back. More of a pattern than a framework.

Pros

  • Deterministic decisions
    • easy testing: expected = actual for decided state+side-effects
    • no test doubles necessary
    • functions understandable in isolation, safe to change or swap out
  • function wiring (explanation here)
    • traceable execution path, no magic
    • easy to change / extend
    • compiler tells you when you forget something
  • easy repro of bugs (esp UI)
    • save UI messages with bug report
    • dev can replay locally, integrations not needed for replay
    • messages have context unlike state changes: DataLoaded ..., SaveClicked
  • time travel, go back and forth thru user actions
  • multiverse capable, change Msg stream to explore alt timelines
  • straightforward code: more focus on user needs, less on code needs

Cons

  • boilerplate
    • function wiring, some changes can be tedious
    • lots of types, many provide dev value, some are chores
  • hard for seasoned OO devs to switch to FP (was for me)
    • difficult to mentally separate data and behavior
    • strong but unnecessary instinct to "protect" data at every step
    • some patterns "bad" in OO are okay in FP and vice versa
    • examples: matching on type, transaction script
  • less developed library ecosystem
    • example: no built-in or well-known repro library
    • counter: easy to code your own
  • straightforward code, tempting to reinvent wheels. I did:
    • back-end URL routing (7 files)
    • executing SQL (9 files)
    • event store on postgres (6 files, 4 more for event listener)
    • validation (4 files)
    • backend-end MVU, minus View (1 file)
    • event parser (2 files)
Collapse
mrjjwright profile image
John Wright

Great features!

Can you elaborate on why the normal dev struggles with these 2?

  • difficult to mentally separate data and behavior
  • strong but unnecessary instinct to "protect" data at every step
Collapse
kspeakman profile image
Kasey Speakman • Edited on

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.

  • 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.
  • feature envy and inappropriate intimacy - Both discourage using another object's data.

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).

Thread Thread
mrjjwright profile image
John Wright

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.

Thread Thread
kspeakman profile image
Kasey Speakman • Edited on

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.

Thread Thread
mrjjwright profile image
John Wright

I thought this might be underlying what you were saying, that makes great sense.

Collapse
diballesteros profile image
Diego (Relatable Code)

Been using a lot of Remix lately.

Pros:

  • Strong ecosystem as it is tightly integrated with React
  • Progressive enhancement is at the forefront
  • Extremely fast bundling with ESBuild
  • SSR means its very fast
  • Uses the platform so you learn a lot about native APIs
  • Does not require Javascript

Cons:

  • Still early into the development cycle so it's still being actively worked on
  • The ecosystem isn't as big as lets say something like Next.js so googling for issues can be difficult. However the Discord is active
  • The documentation is still being quite actively updated and could be better with providing examples
  • Very extendable, can feel overwhelming
Collapse
perelin profile image
Sebastian • Edited on

(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

  • One codebase - all platforms: web (spa/ssr/pwa), mobile (cordova/capacitor), desktop (electron), browser extensions
  • Phenomenal documentation
  • ALL batteries included
  • Active and dedicated developer and community

Cons

  • Quite opinionated. Probably more suitable for startups, prototypes, PoCs, etc

If anyone knows Quasar I would be interested in other opinions. Am I missing something?

Collapse
dhruvsaxena1998 profile image
Dhruv Saxena

(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

Collapse
theaccordance profile image
Joe Mainwaring

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
Collapse
therealgrinny profile image
Connor • Edited on

None,

and/or static sites with CGI requests.

Pros:

  • 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.
Collapse
darkwiiplayer profile image

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

  • Everything is JavaScript. No extensions to the syntax.
  • Very incomplete. Features get added as I need them.
  • Building anything with it has me spend 20% of the time extending the framework.
  • Browser support? Is that some sort of SEA dish I haven't heard of?

Pros

  • Everything is JavaScript. No extensions to the syntax.
  • Very small code-base, easy to copy-paste around for prototyping, or link from a CDN
  • I've become comfortable with lots of weird JS features like Proxy or Reflect
  • Ability to rely on the latest browser features for performance and simplicity

Meta-programming is fun πŸ’œ

Collapse
alaindet profile image
Alain D'Ettorre

Angular

Pros

  • RxJS <-- That's just great!
  • Great developer experience
  • Forms are easy and flexible
  • Routing just works
  • Modules are a good concept for code reuse
  • Dependency Injection
  • CLI
  • It's a framework

Cons

  • It's a framework
  • Bad reputation due to old Angular.js, general verbosity and very different from all other frameworks and libraries
  • Market share is shrinking
  • Third-party libraries are incompatible and/or luckluster
  • Build times and build sizes tend to be heavy
Collapse
j0nimost profile image
John Nyingi • Edited on

DotNet

Pros

  • 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)
Collapse
clsource profile image
Camilo • Edited on

Phoenix Framework

phoenixframework.org/

Pros

  • Elixir
  • LiveView (Realtime with Websockets)
  • Erlang VM (30+ years of production readyness)
  • Surface UI (Similar to React.js)
  • Similar to Ruby

Cons

  • 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.
Collapse
jwp profile image
John Peters

Angular

Pros:

  • 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'
  • Heavy weight with steep learning curve
  • Error messages are terrible
  • Their migration paths are bad.
Collapse
610470416 profile image
NotFound404 • Edited on

Aex

Pros

  • Simple
  • Object-Oriented Support
  • Decorator support
  • No MVC, but Web Straight Line backed.
  • Fast
  • Async/await support
  • Very extensible
  • Compatible with most express.js middlewares
  • Easy data filtering/validation
  • Unified error support
  • Scoped data passing through for requests
  • Focus on backend and http only

Cons

  • Small Community
  • No MVC, but Web Straight Line backed.
Collapse
ben profile image
Ben Halpern Author

Looks like this is brand new, can you elaborate on it?

Collapse
huncyrus profile image
huncyrus

Slim

Pros

  • Super small.
  • Super fast.
  • Advanced PHP ideas.
  • Flexible.
  • Easy to understand.
  • Easy to extend.

Cons

  • Some module/middleware ain't up-to-date for the latest version.
  • Could be hard to not use for REST API.
Collapse
anuragvohraec profile image
Anurag Vohra • Edited on

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.

Collapse
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

My own, Lua-based abomination

Cons

  • Buggy as fuq
  • Building anything with it has me spend 60% of the time extending the framework
  • If something breaks, nobody knows why, myself included
  • Standards? what are standards?
  • Forget about ever using this at work
  • Unstable API would be an understatement

Pros

  • Extreme familiarity with the inner workings
  • Inherently personalised to my workflow
  • Very easy to selectively optimise where needed
  • Extremely valuable learning experience
  • Lots of fun, even when things break

At work I use Rails, but there's really nothing to say about rails. It works. It's good. It's boring.

Collapse
jfbrennan profile image
Jordan Brennan • Edited on

Vue

Pros

Single-file components

<template></template>

<script></script>

<style scoped></style>
Enter fullscreen mode Exit fullscreen mode

Cons

Starting to carry some baggage, but still relatively small.

Collapse
klausdonnert profile image
Klaus Donnert

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.

Collapse
wrench1815 profile image
Hardeep Kumar

Pros

  • It's nuxtjs v2(vue js)

Cons

  • It's nuxtjs v2(vue js)
Collapse
addayounes profile image
Adda Younes Abdelatif

thanks for the article

Collapse
Sloan, the sloth mascot
Comment deleted

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.