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

Comments

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

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

[Adda Younes Abdelatif]

thanks for the article

[Anurag Vohra]

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.

[John Nyingi]

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)

[Camilo]

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.

[𒎏Wii 🏳️‍⚧️]

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 💜

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

[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

[𒎏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.

[Hardeep Kumar]

Pros

• It's nuxtjs v2(vue js)

Cons

• It's nuxtjs v2(vue js)

[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

[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

[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?

[Alex Lohr]

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.

[Kasey Speakman]

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)

[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

[Kasey Speakman]

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

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

[Kasey Speakman]

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.

[John Wright]

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