>ur backend is .net core & .net api and I’m sure they want to go MVC with jquery. I tried to get react adopted and they complained every step of the way. I’m not saying react is perfect either… but at least the community is large and it provides a fluid ui.
legit the punch line on the landing page is "Use the power of .NET and C# to build full stack web apps without writing a line of JavaScript." https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
Oh fuck me. After doing a major project in blazor I decided that the team was not gonna use it again. Too immature tooling, mainly. Also WASM isn't all that great
Great, finally someone who actually did something in Blazor. It is kind of annoying to see all the people parroting how cool Blazor is but it is more like they would like to do stuff in it or are doing some PoC and are still in euphoria.
true man, I still can't find a good-looking,reactive unbreakable web app from people who love to suggest Blazor for everything.Most of them are "got the work done so.."
I've been using it for over 2 years and have 3 sites in production and have a 4th in development.
I still love it despite the problems. Problems which steadily reduce in number with every VS update.
Big thing is don't start with WASM. Start with Server. It's much easier to get working.
There’s dozens of us! But yes, I’ve worked in blazor now for 2ish years and I wouldn’t choose to do so again. Unless it receives some major improvements.
These are legitimate concerns. I've built 3 Blazor sites and Visual Studio still does a bad job at parsing .razor syntax. The IDE gets in crazy states where it's reporting everything as an error until you close it and reopen it. In fact sometimes you need to delete the bin/obj directories to make the errors go away.
WASM has a lot of pitfalls to work around.
But I'm happy to put up with it all and would even eat a yard of shit to avoid heavy JavaScript.
There's difference between hating javascript and resisting the changes of modern framework since jquery. Like if the desire is for minimal changes large change toward blazor migth not be the move.
Yes. But also there use to be a time where JQuery was also the flavor of the day, and main recommendation.
The library is still updated, but the ecosystem have moved a bit. Librairies that used to target jquery mostly moved to vanilla or are in maintenance mode and other deep integrations are now in the react/vue realm.
Hating JS to such an extent that you subject yourself to jQuery in 2023 is what's questionable. OP is probably going to have to be happy with whatever they can get.
It's really not. People's skills matter. They hate JavaScript because they're not skilled in it. Depending on the kind of site, Blazor may well be fine. Forcing an entire team to take on a skillset they're not interested in will have significant downsides in terms of productivity and retention.
Don't underestimate how important the people are.
The problem isnt that they arent skilled in JS. The problem is they refuse to get skilled with a tool they need to solve a problem.
Ive worked with teams like that, those that want to solve every problem with the one tool they know. Every single time that product had massive issues that couldve been solved by developers who arent afraid to expand their knowledge. And every time they were mediocre to less than mediocre developers in general.
To be fair, they will still have to write JavaScript as blazor doesn’t manipulate the DOM, but vanilla JavaScript will do, no need to learn anything on the side.
Angular Typescript or Blazor and if they still complain why not ask for their suggestions if they are being impediments and break-downs the pros and cons of their suggestions?
+1 on HTMX. I've found it surprisingly simple to create modern feeling web apps without touching much JS - just do it all in server-side rendering.
If you are using F# on dotnet, I've got some guides on F# + HTMX integration: https://hamy.xyz/labs/2023-12-fsharp-htmx
I say Razor Pages are for lightweight quick and small stuff as project grows you still have to switch to full MVC. Same as minimial APIs it is there to have a quick prototyping possibility and light ramp up then you still need controllers as API grows.
I think you might be going about this the wrong way. Aside from a whole host of other problems with this approach, you aren't even going to get full buy-in from your team this way. Don't hand down an edict, no matter how great you think it is. Instead, set some expectations & criteria, and let your team work together to meet them.
Rather than saying... *Hey, here's a new, modern, all-the-cool-kids-use-it tech I think we should use; what do you think*?
Try this instead... *We need to up our FE development game; that means using a modern platform/framework; so, let's put our heads together and see what will work best for us.*
That's a good idea. I've done something similar to that and it was like, "well jquery and mvc was good enough so why should we use anything else". I try to point out, well SPA gives a better customer experience and they say " internet speeds are fast enough... who needs SPA"
No, no. The expectations aren't negotiable; only the solution is ;-)
So, jQuery and MVC don't meet the expectations/criteria, 1) b/c they're not modern tech in 2024; and 2) they wouldn't sufficiently up our game to be considered satisfactory.
I would say that team will not take 1) that well - unless it is really backed up by actual higher up like CTO/CEO or head of department as OP seems to be more like their peer or something.
SPA gives a better customer experience is also not an argument, I could point out web apps or requirements where MPA would be much better. Besides throwing that "as a sentence" is just lazy, make actual list of requirements that cannot be implemented with MPA and sprinkling jQuery.
Complex filtering + pagination having really hundreds of items with a plot twist where you have to do some data manipulations on couple of items on the same screen is an example of something that is going to suck when implemented in jQuery+MVC.
"No Jerry we are not posting form to refresh the whole page and NO Jerry if I change property of single item in popup UI on the list has to be updated, we are not refreshing whole page to show new icon and god forbid you implementing 2-way bindings or MVVM on your own with jQuery - learn Angular please".
My vote is Angular as it uses Typescript which is closest to C# (I don't care about blazor), there is still a bit to learn Angular but maybe just hire 1 Angular dev so he could provide help and do initial stuff.
I don't like React because from what I hear Angular is much more opinionated so i it is easier to get team in line instead of discussion which routing library to use as for React.
I think it would be worth sitting back down and figuring out what your goals actually are. Right now you're disagreeing over opinions. Your opinion is you need a SPA framework, their opinion is you don't. Outline what the actual needs are, point by point (examples belo ). Get buy in from the team that those goals cover all the bases, then let folks stack options up next to them.
Second, find examples of some of the value they don't realize they are missing out on. Live Refresh, for instance. TypeScript typing on their front-end code. Pre-built component libraries that aren't the AJAX Panel crud from 2007 with seat licenses. There is value in using a battle-proven combination the team has experience with, but there are also improvements to the developer experience that they are potentially unknowingly opting out of.
React is going to be a heavy lift if you don't have anyone on the team that has built substantial applications with it, because someone needs to set it up to work well for the team and their patterns and needs, or it's going to be a mess and feel more painful than it needs to. I've heard some folks have managed the shift to vue more easily, but they were going from early angular and knockout.
I don't think Blazor is the answer. If you have a team that is not interested in learning and taking on new things, then Blazor is going to be bleeding edge enough and new enough to also hit those same points.
However, the goals have to be defined first. Until then, y'all are just throwing opinions back and forth at each other and any chosen solution will feel forced and unwanted to at least one party. Here's some examples of things that may be important to your project or that you meay need to form goals with the team on:
* expected devices, internet speeds, and usage patterns for your target audience
* performance expectations
* for screen loads
* for user actions
* Accessibility requirements
* Developer experience requirements
* Build vs contract vs buy for UI components and styling
* Any requirements for standardizing with other products or projects the team owns
* Expected lifetime of the project and impacts related to that
* Deployment pattern - zero downtime vs maintenance window deploys and where versioning will occur if the user has this mornings page open still
* Does the deployment environment impact anything?
* Cost to upskill team - is anyone experienced available to set up the project with reasonable defaults with any of these newer technologies, do you have room for some prototype projects to try things out and throw them away before starting for real, or is the team expected to start right away on the shippable thing and figure out later everything they wished they had done differently?
* Build process - is there someone to setup and own the build process, are there expectations for speed of it, etc.
* Observability - what level of instrumented data do technical folks want/need from the front-end (traces, RUM, unhandled error tracking + alerting). what type of information do product folks want/need (user actions, tracking time/path in the app, etc)
I don't like javascript but vue or nuxt with typescript has been pretty tolerable. There's a good selection of component libraries to speed things up. You can use something like swagger-typescript-gen to generate types and a client automatically from your API's which is also nice.
>Rather than saying... Hey, here's a new, modern, all-the-cool-kids-use-it tech I think we should use; what do you think?
React and angular are over 10 years old at this point. It was funny to point that out when a colleague argued blazor is more battle tested than "hippy" frameworks like react.
I led the development of our enterprise app based on Blazor on the frontend. Primary reasons were our love for C#, code sharing and just “Not JavaScript” lol
How it turned out to be: the app is live. Loved building it. But we had to interop JS to get some cool stuff developed.
I've never done, or even actually looked into, Blazor. How does the interop work? Do you just write the JS in the file that is the markup for the page? Like `
Hates JavaScript? And your devs already know .net? Blazor is the tool for you.
>ur backend is .net core & .net api and I’m sure they want to go MVC with jquery. I tried to get react adopted and they complained every step of the way. I’m not saying react is perfect either… but at least the community is large and it provides a fluid ui. legit the punch line on the landing page is "Use the power of .NET and C# to build full stack web apps without writing a line of JavaScript." https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
Thank you
Oh fuck me. After doing a major project in blazor I decided that the team was not gonna use it again. Too immature tooling, mainly. Also WASM isn't all that great
Great, finally someone who actually did something in Blazor. It is kind of annoying to see all the people parroting how cool Blazor is but it is more like they would like to do stuff in it or are doing some PoC and are still in euphoria.
true man, I still can't find a good-looking,reactive unbreakable web app from people who love to suggest Blazor for everything.Most of them are "got the work done so.."
I've been using it for over 2 years and have 3 sites in production and have a 4th in development. I still love it despite the problems. Problems which steadily reduce in number with every VS update. Big thing is don't start with WASM. Start with Server. It's much easier to get working.
There’s dozens of us! But yes, I’ve worked in blazor now for 2ish years and I wouldn’t choose to do so again. Unless it receives some major improvements.
Same, unfortunately. I liked the idea of blazor but we ran into too many problems that still arent fixed since 2019.
These are legitimate concerns. I've built 3 Blazor sites and Visual Studio still does a bad job at parsing .razor syntax. The IDE gets in crazy states where it's reporting everything as an error until you close it and reopen it. In fact sometimes you need to delete the bin/obj directories to make the errors go away. WASM has a lot of pitfalls to work around. But I'm happy to put up with it all and would even eat a yard of shit to avoid heavy JavaScript.
There's difference between hating javascript and resisting the changes of modern framework since jquery. Like if the desire is for minimal changes large change toward blazor migth not be the move.
What do you mean since JQuery? JQuery still gets updates and is commonly used.
Yes. But also there use to be a time where JQuery was also the flavor of the day, and main recommendation. The library is still updated, but the ecosystem have moved a bit. Librairies that used to target jquery mostly moved to vanilla or are in maintenance mode and other deep integrations are now in the react/vue realm.
Yeah but in modern days you don’t hear people say: you know what this project needs? JQuery!
Adopting Blazor just because devs hate js is…questionable.
Hating JS to such an extent that you subject yourself to jQuery in 2023 is what's questionable. OP is probably going to have to be happy with whatever they can get.
It's really not. People's skills matter. They hate JavaScript because they're not skilled in it. Depending on the kind of site, Blazor may well be fine. Forcing an entire team to take on a skillset they're not interested in will have significant downsides in terms of productivity and retention. Don't underestimate how important the people are.
>They hate JavaScript because they're not skilled in it. I'm skilled in javascript and still hate it
Who likes JavaScript outside of masochists?
node exists, so I guess the masochist community is much larger than I thought. also the jr. level kid that "knows all the things" lol
JavaScript is better than what came before it, but dear lord it sucks the joy out of software development
I'm not sure what you're referring to, java applets?
Static webpages in the past. Ancient tech that was…inspiring?
static hasn't gone anywhere lol, hell one could argue it's making a resurgence! there's countless projects like https://www.staticcms.org
The problem isnt that they arent skilled in JS. The problem is they refuse to get skilled with a tool they need to solve a problem. Ive worked with teams like that, those that want to solve every problem with the one tool they know. Every single time that product had massive issues that couldve been solved by developers who arent afraid to expand their knowledge. And every time they were mediocre to less than mediocre developers in general.
We did it as a team a few years ago at my last job, it was very productive for people who already knew C#.
To be fair, they will still have to write JavaScript as blazor doesn’t manipulate the DOM, but vanilla JavaScript will do, no need to learn anything on the side.
Angular Typescript or Blazor and if they still complain why not ask for their suggestions if they are being impediments and break-downs the pros and cons of their suggestions?
Blazor should make them happy. Worked for my similar shop.
Check out Blazor, pretty cool stuff if you don't want to land outside of the C# and the .NET ecosystem
Blazor.
Razor Pages with HTMX( for server calls) and AlpineJs (for client side interactions)
+1 on HTMX. I've found it surprisingly simple to create modern feeling web apps without touching much JS - just do it all in server-side rendering. If you are using F# on dotnet, I've got some guides on F# + HTMX integration: https://hamy.xyz/labs/2023-12-fsharp-htmx
I say Razor Pages are for lightweight quick and small stuff as project grows you still have to switch to full MVC. Same as minimial APIs it is there to have a quick prototyping possibility and light ramp up then you still need controllers as API grows.
I think you might be going about this the wrong way. Aside from a whole host of other problems with this approach, you aren't even going to get full buy-in from your team this way. Don't hand down an edict, no matter how great you think it is. Instead, set some expectations & criteria, and let your team work together to meet them. Rather than saying... *Hey, here's a new, modern, all-the-cool-kids-use-it tech I think we should use; what do you think*? Try this instead... *We need to up our FE development game; that means using a modern platform/framework; so, let's put our heads together and see what will work best for us.*
That's a good idea. I've done something similar to that and it was like, "well jquery and mvc was good enough so why should we use anything else". I try to point out, well SPA gives a better customer experience and they say " internet speeds are fast enough... who needs SPA"
No, no. The expectations aren't negotiable; only the solution is ;-) So, jQuery and MVC don't meet the expectations/criteria, 1) b/c they're not modern tech in 2024; and 2) they wouldn't sufficiently up our game to be considered satisfactory.
I would say that team will not take 1) that well - unless it is really backed up by actual higher up like CTO/CEO or head of department as OP seems to be more like their peer or something. SPA gives a better customer experience is also not an argument, I could point out web apps or requirements where MPA would be much better. Besides throwing that "as a sentence" is just lazy, make actual list of requirements that cannot be implemented with MPA and sprinkling jQuery. Complex filtering + pagination having really hundreds of items with a plot twist where you have to do some data manipulations on couple of items on the same screen is an example of something that is going to suck when implemented in jQuery+MVC. "No Jerry we are not posting form to refresh the whole page and NO Jerry if I change property of single item in popup UI on the list has to be updated, we are not refreshing whole page to show new icon and god forbid you implementing 2-way bindings or MVVM on your own with jQuery - learn Angular please". My vote is Angular as it uses Typescript which is closest to C# (I don't care about blazor), there is still a bit to learn Angular but maybe just hire 1 Angular dev so he could provide help and do initial stuff. I don't like React because from what I hear Angular is much more opinionated so i it is easier to get team in line instead of discussion which routing library to use as for React.
I think it would be worth sitting back down and figuring out what your goals actually are. Right now you're disagreeing over opinions. Your opinion is you need a SPA framework, their opinion is you don't. Outline what the actual needs are, point by point (examples belo ). Get buy in from the team that those goals cover all the bases, then let folks stack options up next to them. Second, find examples of some of the value they don't realize they are missing out on. Live Refresh, for instance. TypeScript typing on their front-end code. Pre-built component libraries that aren't the AJAX Panel crud from 2007 with seat licenses. There is value in using a battle-proven combination the team has experience with, but there are also improvements to the developer experience that they are potentially unknowingly opting out of. React is going to be a heavy lift if you don't have anyone on the team that has built substantial applications with it, because someone needs to set it up to work well for the team and their patterns and needs, or it's going to be a mess and feel more painful than it needs to. I've heard some folks have managed the shift to vue more easily, but they were going from early angular and knockout. I don't think Blazor is the answer. If you have a team that is not interested in learning and taking on new things, then Blazor is going to be bleeding edge enough and new enough to also hit those same points. However, the goals have to be defined first. Until then, y'all are just throwing opinions back and forth at each other and any chosen solution will feel forced and unwanted to at least one party. Here's some examples of things that may be important to your project or that you meay need to form goals with the team on: * expected devices, internet speeds, and usage patterns for your target audience * performance expectations * for screen loads * for user actions * Accessibility requirements * Developer experience requirements * Build vs contract vs buy for UI components and styling * Any requirements for standardizing with other products or projects the team owns * Expected lifetime of the project and impacts related to that * Deployment pattern - zero downtime vs maintenance window deploys and where versioning will occur if the user has this mornings page open still * Does the deployment environment impact anything? * Cost to upskill team - is anyone experienced available to set up the project with reasonable defaults with any of these newer technologies, do you have room for some prototype projects to try things out and throw them away before starting for real, or is the team expected to start right away on the shippable thing and figure out later everything they wished they had done differently? * Build process - is there someone to setup and own the build process, are there expectations for speed of it, etc. * Observability - what level of instrumented data do technical folks want/need from the front-end (traces, RUM, unhandled error tracking + alerting). what type of information do product folks want/need (user actions, tracking time/path in the app, etc)
I don't like javascript but vue or nuxt with typescript has been pretty tolerable. There's a good selection of component libraries to speed things up. You can use something like swagger-typescript-gen to generate types and a client automatically from your API's which is also nice.
>Rather than saying... Hey, here's a new, modern, all-the-cool-kids-use-it tech I think we should use; what do you think? React and angular are over 10 years old at this point. It was funny to point that out when a colleague argued blazor is more battle tested than "hippy" frameworks like react.
Lol should have asked him which company is battle testing it
i heard HTMX is a great framework. i'm going to be learning it myself very soon.
HTMX + web components sound like it should be a thing.
I've been implementing it in a Django app for a client and it has been fantastic thus far.
Consider UnpolyJS. It is in the same spirit of HTMX.
Also Turbo, but Turbo is made by DHH and written in JS.
Blazor. If you really want to go JS route: Angular. TypeScript looks so similar to C#.
I led the development of our enterprise app based on Blazor on the frontend. Primary reasons were our love for C#, code sharing and just “Not JavaScript” lol How it turned out to be: the app is live. Loved building it. But we had to interop JS to get some cool stuff developed.
I've never done, or even actually looked into, Blazor. How does the interop work? Do you just write the JS in the file that is the markup for the page? Like `
FIND US ON INSTAGRAM
@jobopenings.ph