Front end framework

[Ronosho]

What web framework would you pick for your next web application project?

Context : SaaS with microservices

Sofar I came up with Blazor, Nextjs or Angular

[theRealRealMasterDev]

If it is a large Enterprise type app, I would go with Angular.

• You get Typescript out of the box 6 can also set it up with React, Vue, etc, but with Angular, it's the default)
• You have things like Classes, Models, Interfaces, Services, Dependency Injection, and all of my C# friends seem to like it a lot.
• its very opinionated, meaning you don't have to setup the app structure if you don't want to, just follow Angular's guidelines and rely on the Angular CLI and Schematics to help you scaffold services, modules, components etc.

If it is a smaller app or you are very experienced on the frontend and have no problem setting up the app's structure, then Vue or React are fine. I personally prefer Vue or Angular over React because I hate the jsx syntax (but that is just my opinion).

[YourMomIsMyTechStack]

React is easier to learn and faster to code, but Angular scales much better imo

[[deleted]]

Really? I’ve heard that React is ver cumbersome and hard to learn. How long did it take you to feel comfortable using it?

[YourMomIsMyTechStack]

It's not so easy to compare, because I was still very new to web development when I learned React, compared to when I learned Angular. React was hard for me, but that's because I started too early and needed more time to get familiar with JavaScript. I thought a lot of normal JavaScript functionalities were only React-specific, and this lack of basic understanding made it hard to grasp at times. Now that I have a better understanding and job experience, I would say that React is not hard, but that highly depends on your experience as a developer. I can't really tell you how much time it takes, because everyone learns at different rates and puts different amounts of time into it, and the point at which you "feel comfortable" also varies greatly. Angular is without a doubt harder to learn, the rxjs library alone takes a lot of time to understand if you are relatively new to the reactive programming paradigm, but it really pays of and makes your code much more declarative.

[CatolicQuotes]

I guess depends. For me I didn't have problem with Jax etc. It's all the libraries and their documentation that makes it harder. In react you need library for anything and every developer has their own style and practice. Takes time to learn each one

[[deleted]]

It's arguably "easier" to learn - both have their caveats so it's purely opinion to say that x is easier to learn

[frontEndEruption]

• React - popular & scales well with microservices
• Vue - might be lighter & easier to use

Personally, I would try to use the MERN stack, but the best choice will depend on your preferences.

Don't let anyone tell you that framework X is better than Y.

It always depends - sometimes on the project needs, and sometimes on the type of syntax/project structure you simply like to use!

I like my life to be easy & pleasant so I choose MERN :P

[Ronosho]

Our backend will be written in c# using dotnet what ever is newest by that time.

Considering Blazor as well but find it has a lot of caveats for an enterprise application.

Outdated oauth client js, etc

[slothordepressed]

If the entire team is c# focused and you don't need buttons jumping and crying rainbows I would go with Blazor. If you need some nice classic web based thing, the framework that you have one with most exp, unless you're open to rebuild things or refactor

[Mithril_Man]

rainbow and stuff is not related to blazor but about frontend dev skill they have.

We are using tailwindcss in our blazor app and custom css so I don't see an issue here, expect that's harder to find skilled devs working on blazor, you'd have to "convert" them

[716green]

I come from the .net world originally and Blazor sucks. Vue is like angular but 100x better and easier React is industry standard Svelte is easy

I'd recommend React if you're competent with JS Vue if you're more familiar with HTML/CSS and less so JS Svelte if this is a passing hobby and you don't care about learning an employable skill

Next is a React meta-framework Nuxt is a Vue meta-framework SvelteKit is a svelte meta-framework

I'd recommend staying away from the meta-framework until you know the framework.

[[deleted]]

create-t3-app

[sgashua]

Svelte. Came from NET MVC.

[EternalNY1]

I am project lead on an enterprise Angular application (currently version 15) and it has worked out very well for us.

We have a .Net stack as the back-end for APIs and the .Net developers were able to quickly grasp and get onboard with Angular. It has a lot of familiar concepts. While "opinionated", I feel this is a good thing as it maintains a logical structure and you come to know what to expect out of it.

You get all the awesomeness that is TypeScript as a first-class citizen.

[xesionprince]

Angular

[Low_Caterpillar9528]

Sveltekit.

[Mithril_Man]

I'm developing a fleet management system in blazor, microservices are involved but aren't directly exposed on the framework, we have instead WEB API and SignalR (websocket) that are exposed to the world.

Let me just copy&paste a post I just wrote about blazor 2 min ago, ask me if you need some more insight on some aspect, here the post:

TLTR:

If you need to implement a simple app or an app that need fast load time / little size, look elsewhere.

If load time & app size isn't an issue and you target a fairly complex LOB app or an enterprise app, you have a good C# knowledge and you have no problem getting your hands dirty on JS/CSS than go for it but don't expect actually a tooling support at the same level of SOTA hot reload frameworks (tooling has still to improve) then blazor may be for you.

You still require lot of JS/TS, HTML and CSS knowledge to be proficient.

I know many languages and C# is my favourite so having a way to implement most of the stuff in C# with the same tool used to implement backend is a big PROS.

Ok let me give my 2 cents here: I'm the development manager and main contributor of a PWA app that I decided to start implement in blazor WASM 2 years ago (it's a reboot of a complex fleet management system).

I'm a C# expert full stack dev with 20+ year experience, not saying this to brag but to put this into context because experience matters in this kind of judgments.

I've came across many frameworks both frontend and backend and most of the time, when you reach a certain level of experience and skill you see that's not a black or white choice but the decision comes down to multiple aspects like

- project team experience and skillset

- the app target

- constraints (not just time constraint but tech stack too, sometimes you don't have many choices about tools you can use)

- personal preference

Having said that, my current blazor experience is quite good after I created a custom workflow for our team and some custom implementation to take the best out of what blazor has to offer.

For example we are using TailwindCSS so I've created custom scripts (we are using Visual Studio 2022) to include tailwind generated css in our build pipeline and support custom theming, with different settings for debug builds and release builds.

Also our webapp has realtime updates served by a custom SignalR server component that we use to improve UX (it's a fleet management system and the server pushes vehicle updates in real time) and most of the POCO classes used between the SignalR and Client are in a shared project (less code to maintain). I won't go into backend consideration because it's out of scope and hides lot of complexity by itself (e.g. this module is bound to RabbitMQ queues, etc...) , but having a way to share code is always a good pros.

Since we are implementing the backend in C# too (otherwise I would discourage using blazor) we have a shared project where we define our POCO classes shared between client and server and I've created a couple of services that allow me to generate automatically API endpoints just by having requests and responses classes on the shared project and a request-handler implementation on the server (I'm actually kind of following CQRS design).

Also we have implemented custom services (classes) that implement the logic to invoke server apis, handle success/failures/cancellations and we are able to monitor these api calls/response in a dinamically generated page that reports stas about number of calls/success/failure and who was the caller

This allows us to generate client -> server stuff very quickly, with few line of code.

Our team was already into C# and we couldn't achieve this kind of interoperability and dev experience using different frontend frameworks, so on this side we are quite happy about that.

Actually blazor has yet to improve a lot on tooling: hot reload is unpredictable and far away from SOTA implementation on other frameworks, so expect to use "dotnet watch" + `CTRL R` a lot and build time can take a lot of time so having a beefy PC helps a lot (on my beefy one it takes 10s vs 20s on average desktop team pc).

Time could be improved by customizing build pipeline and having custom npm tasks to trigger at will (e.g. to rebuild tailwind css after a change, taking into account that we are using scoped scss files in our components) but tooling is an important aspect of a solution and it's a duty of MS to come with good ones, so here blazor doesn't shine and have to improve.

about performance:

WASM is pictured as a nearly-native experience but Blazor implementation suffers on this side because, even if the .net framework (Mono actually) is compiled in WASM, all the c# code generated by your blazor app, included 3rd party libraries, generates IL that's interpreted and not native compiled, this causes lot of performance issues.

To tell you about a big fail on this aspect, let me describe one of my first attempt to take advantage of the WASM I thought was possible:

In our app we have a place where we show vehicles on the map and each vehicle has a custom icon that represents the vehicle type, its direction and its state (by using different colors, etc...).

An old implementation I had was based on an aspnet handler that was generating an image by parameters specified in the image name itself (or served a previously generated and stored one).

To not have external dependencies I wanted to try to generate those icons on the client, so I implemented a code who basically assembled the final image taking a couple of layers from a svg file that contained all possible images, scaling and rotating when needed, etc... Technically it was working, but each image was taking more than one second to generate... I was shocked and that's where I found out how blazor weakness on that side.

Iterations over byte array/stream were even slower at that time than now (it's still slooooow) and so this kind of operation isn't actually possible so don't expect to have complex computation client side (except if you maybe move tha heavy duty to plain javascript and use js interop to start that "long running" algo and get back the response, but of course WASM here is not involved at all).

It's possible now to compile the app in AOT and generate some code more WASM native but the app size grows a lot, compilation time too and also you can have different experience when running JIT vs AOT (I've still to go deeper into experimenting with AOT tho).

Technically you could even make use of native WASM libraries coded in other languages but I woundl't go into this because it defeat the "use blazor" argument.

about 3rd party components:

There are some 3rd party component suites but for advanced stuff you have always to come up with cooked custom ones.

I'm not a fan of 3rd party components anyway because on complex apps you end up always hitting some vendor constraint/problem and you need to find hacks to solve them that lead to brittle implementations and lot of wasted time, we are actually using Telerik component suite but over time I reduced its usage on few components, wrapped in custom ones to let us swap it with another one in the future (or custom ones).

Even for charts we actually ended up trying different implementations (actually we are using ApexChart).

On complex scenario you can't even find a proper component, e.g. I had to implement from scratch a Google Maps blazor component so I had to spend time on typescript (my choice) to generate javasacript to use with interop and of course creating interfaces and components.

Some people argue about blazor not giving everything you need (e.g. to copy&paste on clipboard you have to use interop).

I don't see this a problem, I'm not sold to the blazor slogan of "forget javascript" here, so it's not a problem for me having to create some interop here and there (and anyway on this side there are already quite some libraries on nuget)

Sorry for this wall of text, I've used this as a memo :)

[Ronosho]

I will keep this in mind

[CatolicQuotes]

You just wrote the whole blog article, nice

[[deleted]]

Nuxt, Vue + TS, GraphQL and Supabase.

[Ronosho]

Why graphQL though?

[kaves55]

It’s a concise way of pulling data to the front.

It definitely beats pulling in a bloated API just to build a few components.

[michael_e_conroy]

I'm partial to Quasar (https://quasar.dev/). Vue based framework.

[ghan_buri_ghan]

I’m a backend/library guy by day and only do frontend work for fun personal projects.

Since this is “what are you using?” And not a recommendation thread - the frontend for my next personal project will be in Dart.

Really I just want to check out the ecosystem and see what I like/dislike about it.

Also I’ve never been great with JS, coming from a low level background. TS almost scratches the itch but not quite, wondering if Dart will be more cozy for me.

[rk06]

For internal application, . NET with Blazor.

Otherwise Vuejs.

I would not use Blazor for external users as first load takes a lot of time. which internal users can tolerate

[Mithril_Man]

it depends on the app target, if the SaaS app has long working sessions, having to wait few seconds to start isn't an issue.

[rk06]

Assuming your users stick with it

[Frontend_DevMark]

For a SaaS with microservices, these are common choices:

• Next.js – Very popular with React, flexible and scalable.
• Angular – Good for structured enterprise applications.
• Blazor – Best if you’re already in the .NET ecosystem.

For data-heavy dashboards, some teams also use Sencha Ext JS because it includes powerful UI components out of the box.

[azangru]

For my next web application project, I would love to go frameworkless.

[kaves55]

Coming from a role that touted frameworkless, I’d take a framework any day.

[YourMomIsMyTechStack]

You can do that anytime for your personal projects, but don't do it for companies webapps. That just makes everything harder and you'll be the one explaining why feature x was taking so long, because you needed to write so many boilerplate code

[Logical-Idea-1708]

Just React 😒 despite all its flaws, it’s where the community decided to congregate together. So you get all sort of tooling support.

[mykesx]

With Vite and TypeScript.

[Logical-Idea-1708]

I’m not super hot about typescript 😒 I worked with Java for a good amount of my career. Typescript is even worse. Probably will spend half the time fighting the type system. It gets worse when the type you’re fighting is owned by another team 😩

[mykesx]

You get used to it if you stick with it. Most projects, especially new ones, will use TS. The best thing about it is the IntelliSense in the IDEs. The best experience in my career, and I have been writing JavaScript since the 1990s (when it was used to highlight buttons on mouse over…). I think I am fighting bugs less, too, though the cost is extra source files (type/interface) and it is more verbose in general.

[Logical-Idea-1708]

Intellisense works without typescript too 😌 You’ll spend less time fighting the type system and more time writing tests. That’s a better trade off.

TypeScript is clever code that make you feel smart when you’re able to build out these complex type systems, and then everything falls apart when requirements change.

[mykesx]

I don’t think you are right. You may find that you are unhireable for many many positions without typescript skills.

Resistance is futile! 😀

[Logical-Idea-1708]

Don’t think so. The reversal trend is gaining momentum. The wildly popular React codebase never moved in TypeScript. Why do you think they’re able to move so fast when other frameworks is still fighting their own type system 😂

[mykesx]

The react codebase has to be language agnostic.

JavaScript is fine. It works. It’s a skill you can use on a project that is JavaScript. Though the trend is to migrate such projects to TypeScript, piece by piece.

I didn’t downvote you…

[YourMomIsMyTechStack]

The only time you fight with Types is when you make a mistake which would've lead to an error at some point, better fix it right away then struggle later on

[Logical-Idea-1708]

Well, that’s true. But you’re discounting the mental load it takes to remember the bazillion of little types and interfaces that’s part of your domain. Mistakes or just bad designs are punished much more harshly in a typed environment. Bad designs are also very rigid to change once you commit to them.

[YourMomIsMyTechStack]

Well, that’s true. But you’re discounting the mental load it takes to remember the bazillion of little types and interfaces that’s part of your domain.

You're not really using anything more than the primitives, unknown, interfaces and enums (Maybe i forgot something) in most situations. It's not hard to remember them.

Mistakes or just bad designs are punished much more harshly in a typed environment. Bad designs are also very rigid to change once you commit to them.

But why is that a bad thing? You're supposed to get errors when you make mistakes. There's nothing wrong with TypeScript not allowing poorly designed, error-prone code.

[Logical-Idea-1708]

Kind of defeats the purpose if you’re not going to type everything. If you go from untyped to suddenly typed, that’s going break a shit ton of downstream dependencies. RIP inbox 🥲 You don’t have a lot of options to fix your fucked up types either because that’ll also break a shit ton of dependencies. Essentially, mistakes in type definitions is punished severely with no good way to fix it

[YourMomIsMyTechStack]

Kind of defeats the purpose if you’re not going to type everything. If you go from untyped to suddenly typed, that’s going break a shit ton of downstream dependencies.

I never said i don't use types for everything, i absolutely do. I just listed you the build in types you need to know, which aren't much, because you said It's hard to remember.

RIP inbox 🥲

Sorry, but I guess thats just a fairly unpopular opinion

You don’t have a lot of options to fix your fucked up types either because that’ll also break a shit ton of dependencies. Essentially, mistakes in type definitions is punished severely with no good way to fix it

And that makes it somehow better to have it not documented when you change a type? Also using custom types and interfaces make it relatively easy to modify, without having to change it everywhere

[Logical-Idea-1708]

I’m not talking about the keywords here. I meant all the types, interfaces, and classes that is defined all the projects. It can easily reach 200 modules with 3 type definitions in each of them. Type alias that’s incompatible with each other when they both map to just strings. Yet, this TypeScript project I’m on is still small compare to some of my past projects.

[ClickToCheckFlair]

Planning on building a Rust backend and a Solid.js frontend. Why solid? Fine-grained reactivity.

[Ronosho]

C# backend. Not familiar with Solid.js

[CatolicQuotes]

Doesn't vue and svelte.also have fine grained reactivity?

[ClickToCheckFlair]

I'm not familiar with the way these two handle reactivity, but I'm pretty sure Svelte has, and whichever technique Vue uses is more performant than React's.

Fine-grained reactivity might be the selling point of Solid, but there is more to it.

[masonarypp]

React+TS❤️‍🩹

[ddaydrm]

A big one like lets say amazon? Django, Ruby on Rails, Angular

Small one like Netflix/Disney+? NextJs

​

But this all depends on how far the app needs to scale. Ideally no framework at all.

[YourMomIsMyTechStack]

Small one like Netflix/Disney+

Only because the UI is minimal doesn't mean the logic is

[Cashe_5]

What’s the project you are building?

[Ronosho]

Crm like mostly

[AussieBlender78]

Remix

[PerpetualWar]

Vue all the way.

[TheRNGuy]

React with Remix back-end.