> In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time.
Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on the back end and Vue 3 on the front end.
In short:
- .NET is one of those boring workhorse choices, like Java - it's pretty stable, the performance is good, the type system is decent, IDEs are as good as it gets (Rider, VS), can run on Windows or Linux with no issues, there is an ecosystem that feels very coherent (more focus on ASP.NET than something like Spring in Java, because there's fragmentation around that, Dropwizard, Quarkus, VertX and so on)
- Vue feels really nice to work with, the Composition API feels simpler than React, the developer ergonomics are fine, the documentation is nice, packages like Pinia, VueUse and VueRequest keep things simple, in addition to something like PrimeVue giving lots of UI components that you can use to iterate out of the box
- however, while I think that the SPA approach can be nice to keep the front end separate from whatever technology you use on the back end, it comes at a cost of duplicating your data model and the interfaces between them (REST endpoint and client, for example), in addition to needing to think about how to deploy it all (separate domains vs context paths on the same domain, CSP, CORS etc.), though it's mostly doable
- I did definitely run into problems with Vue not being the single most popular choice out there, for example I wanted to integrate Mapbox maps and the VueMapbox package is for Vue 2 only, whereas Vue 3 Mapbox GL breaks when you try to integrate it with mapbox-gl-directions. Eventually I switched over to Vue Map (Leaflet based) with leaflet-control-geocoder and leaflet-routing-machine but even those tended to break, because adding markers for a calculated route makes the map break when you zoom in/out, due to it losing a reference to the map JS object; in the end I just used patch-package to fix a few lines of code that didn't work in the offending packages instead of forking/building them myself, but that's a bit of a dirty hack
In short, I think that .NET is pretty good, Vue is pretty good, but the JS ecosystem feels like it works well only sometimes, even for reasonably popular solutions. On that note, I'm all for trying out things like Blazor, but then again my past experiences with Java and something like JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit (which is also why I prefer to keep the front end decoupled from the back end as much as possible, sometimes to my own dismay).
Honestly, it sometimes feels like picking anything that's not React is shooting yourself in the foot because everyone's building their libraries/packages/integrations for React. At the same time, I don't really enjoy React much at all.
I spent a decade with C# and .Net and even in its current form which is easily the best it’s ever been I vastly prefer to work with Typescript.
Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up to require that you build and maintain “template” projects, have strong linting, testing and pipeline governance, so there is a lot of freedom to make it work easily for your organisation exactly the way you want it to. Typescript is obviously not alone in this, but it’s far less opinionated than something like .Net.
The main reason is that .Net always becomes burdensome once you start using it’s included batteries. This isn’t really an issue with C# as much at it is an issue with it’s libraries. Take OData and Entity Framework as an example, the .Net magic behind them sort of share the same model builder, but they do so differently. What this means is that a lot of the cool OData features like patch doesn’t actually work with EF, meaning you’ll either have to rewrite a lot of the model builder (don’t) or have to work around it. .Net has always sort of been like that. It variates between being 50-90% “done” but it never really gets there until it moves on. Like EF, much of the EF 7 road map isn’t implemented yet, but here we are, moving on to EF8.
I think for a lot of use cases it’s a wonderful technology, and Blazor will probably be awesome until Microsoft moves on, but at least around here, it’s also a technology that doesn’t really see adoption in anything but small-midsized companies, and in my opinion, .Net is part of what hinders growth. Obviously not a huge contributor, but once you step out of where it excels, you’re just going to have to fight .Net so much harder than you will with Typescript. Which is sort of interesting considering they are both Microsoft products which align more and more. That being said, it’s not like it’s bad either.
It seems a little disingenuous of you not to mention how I never hide the fact that it's an issue with the batteries. I'd also say that considering how great OData's patch is with the modelbuilder it's actually EF that's being bad in this case.
I enjoyed using ServiceStack. Write your data model in the C# API, run a tiny CLI command and it spits out Typescript definitions to match your data model.
> however, while I think that the SPA approach can be nice to keep the front end separate from whatever technology you use on the back end, it comes at a cost of duplicating your data model and the interfaces between them
Can you elaborate on this? I'm not sure I get it, because once you have your view model in asp.net, it seems like it should be easy to derive a JS/TS model from it using various techniques (reflection, source generators, etc.).
Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on the back end and Vue 3 on the front end.
In short:
In short, I think that .NET is pretty good, Vue is pretty good, but the JS ecosystem feels like it works well only sometimes, even for reasonably popular solutions. On that note, I'm all for trying out things like Blazor, but then again my past experiences with Java and something like JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit (which is also why I prefer to keep the front end decoupled from the back end as much as possible, sometimes to my own dismay).Honestly, it sometimes feels like picking anything that's not React is shooting yourself in the foot because everyone's building their libraries/packages/integrations for React. At the same time, I don't really enjoy React much at all.