Why We Choose Blazor over React and Vue: Matt Jones

um so thanks to our sponsor bit Labs bit Labs works on custom software projects that require a significant investment of time money and energy from businesses they help by defining goals and scope managing the process and ensuring goals are achieved thanks business labs for being a local sponsor and be on the lookout we are having an attendees survey sent out after the conference we would love your feedback to make sure that 2024's Thunder Plains is even better and now for our next speaker meet Matt Jones a senior software developer with 11 years of expertise in the net World he's your go-to guy for implementing full stack applications and isn't afraid to dabble in react and other JavaScript Frameworks when he's not coding Matt enjoys soccer golf and quality time with his family today Matt will will take us on a journey familiar to many companies they were content with net Razer Pages until Blazer's production release opened doors to a new front-end framework but rather than jumping into the next Microsoft stack they explored and compared Blazer react and view Matt will share the factors they loved hated and remained indifferent about leading to their choice of Blazer as their Spa framework join us for insights from Matt's decision-making process and a glimpse into the Blazer Journey all right why we chose Blazer over react and view um real quick just kind of want to do a quick survey is anybody currently using Blazer out there hey my people all right any any dot Deb people okay quite a few of you awesome so uh just real quick again I'm Matt Jones senior software developer at 1898 and Co a part of Burns and McDonald uh I'm based out of Kansas City Missouri uh primarily been doing net development for 11 11 a half years now primarily as a software consultant and so what that means is we're typically going to our clients we are solving their problems typically with AET web app of some sort some data integration of some sort or some Cloud development of some sort again I want to make sure everybody's clear on this one this is not meant to be a Blazer sales pitch so Blazer is probably not the right framework for everybody emphasis on probably uh I'm a little biased sorry if that kind of bleeds through in this present a little bit um but really this is meant to be kind of our journey for how we got to Blazer so we were on razor Pages before but again we didn't want to jump straight to Blazer and just just go with it we wanted to make sure that we took our time we evaluated the different options out there and we made the right decision for us and to be successful in the future so this is really meant to be our retooling journey why I wrote this talk specifically we had a client conversation and this still resonates with me all the time the specific quote we had with a client was uh after they found out that we were using Blazer this talk came up and they said hey we're actually going to choose what framework we're going to use for our spa on Friday this week which one should we choose right that didn't make any sense to us we had spent a couple months a couple weeks trying to figure out what we were going to do moving forward they were just going to flip a coin and say yeah we're going to do this we're going to do react or we're going to do Blazer or we're going to do angular or something along those lines after kind of talking to him a little bit more in that same conversation um we got the idea that they were using net for their backend on the front end they really had no common denominator they had a couple people doing HTML jQuery CSS but that was really it and they're not alone in this journey right there's a lot of us that are here even today right where you're trying to get insights on what people are doing trying to make decisions moving forward what are the cool new trends going on right now and so this was really something that you know they're not alone in this journey but again they didn't have any Direction they were going to flip a coin basically is what it seemed like so why were we trying to move away from Razor Pages we had been working on razor Pages for I don't know 3 years four years and it was okay emphasis again on the okay it was never like perfect it was never really great we didn't really enjoy it a ton but it allowed us to really execute our projects we were successful we were getting them done we were getting them done on time delivering to the clients they were happy we were kind of happy right and I listed a couple things up here that you know specifically were you know felt wrong or not quite right in our opinions um I'm not going to go into too many of those things but some of the ones the anti-forgery token always makes me laugh if anybody's familiar with the anti-forgery token it's a security measure put in place to help secure your communication from your front end to your back end with razor Pages typically all it needs is one line of code just one line of code you forget that one line of code your afternoon is probably gone trying to debug that situation and that has happened way too many times to me and the rest of our team so that's one specific example another example is again with our razor Pages applications um we were doing a lot of net on the back end your typical cend um we had situations where we had kind of a microservice architecture you so you'd have an MVC API over here some razor Pages front end over here things were okay um we enjoyed the MVC side of things but on our Razor side of things we tend to have I don't know 10 50 100 lines of Razor syntax and then tenfold of that in jQuery JavaScript to get done the UI side of things that we needed done so we are already kind of splitting our skill set here and writing tons and tons and tons of jQuery to get done what we needed to in Razer again just a couple more things that were just like this doesn't feel quite right to us kind of a square peg and a round hole sort of situation and then on the other side of things from the Microsoft World it seemed and this started probably about two years ago when we took this journey um the writing was already kind of on the wall for razor pages and it still feels that way to us today so if anybody's familiar with net comp uh good conference sets out starting next week uh free it's a really good one it's all virtual um if you go and look at the agenda for that you're not going to see a single topic or single conversation about razor Pages you will see tons of them about Blazer though and this was already the case two years ago when we were kind of going through this journey so the writing already seemed to be on the wall then and it certainly is now that razor Pages was kind of getting phased out you know the support for it may still be there but you're not going to be getting those new features that everybody's looking for so that's really where Blazer kind of stepped in and this is where we started decide you know what why are we still putting up with this why are we doing this we're seeing all these people at conferences talking about how much they love react how much they love you we've considered Blazer already it's probably time for us to take action and that is when we embarked on our pilot project here I have up on the screen here pilot project is greater than hello world I'll kind of come back to that but um I'm going to steal a quote from the net rocks podcast episode 1800 uh they had a guest on there Heather Downey and she said this specifically I have a LoveHate relationship with hello world and that has really resonated with me to this day ever since I heard that if the tool that you're using the library that you're using the framework you're using makes it really really easy to get in and get Hello World up on your screen awesome but if everything after that is really really painful it's probably not the right tool so again if hello world is the only thing they're doing right definitely not the right tool and so that's where that LoveHate relationship comes in everybody wants that quick gratification of getting up and running but you need to go deeper than that and uh so we'll go into the pilot project and kind of the other factors that we kind of talked about too that led us towards our decision in our pilot project we had a couple things hopefully you guys can read that um a couple things that we wanted to keep consistent across uh the pilot project so we had built out an MVC backend uh using net that was going to be the same across all three front ends we had three of our team members um set out to build the same front end using the three different Frameworks so we built one with react one with review or one with viu and one with blazer in that pilot project I specifically am highlighting the terer Grid on here we'll talk about that one specifically uh and why uh another component library of some sort and then with those component libraries they need to be consistent with or at least support the material theme so our team had bought in on the material UI standards um we're not we're not uiux people we've got a UI person but the material theme is really kind of helped simplify what we're doing so it gives us kind of that standard looking feel instead of standards that we can work with form data entry um that's pretty common stuff you know you got to be able to do your CR oper operations if you can't do that then it's probably not going to work uh we have way too many Engineers that love the term Google like search so okay fine we'll put in a search bar with autocomplete of some sort in this pilot project and then the final item I've got up here is a mapping component I put in parentheses a bonus here we have a lot of GIS related data geospatial data that we work with on a pretty regular basis so um I put this as a bonus because I think we already kind of had a good feeling for where this was going to fall into the three different Frameworks uh mapping components tend to be pretty JavaScript heavy and uh we'll talk about that one a little bit more specifically so not like a super complicated front end but something to at least get us a little bit deeper than hello world right in here I'm going to talk specifically about the teric grid so if anybody's familiar with teric or Kendo UI um they've got a really really nice set of components and component libraries out there and there's more to it too they've got some document processing and some other tools out there too but it is a paid licens to use their tools now the GD specifically has saved us so so so much time so again I mentioned Engineers we work at an engineering firm and a lot of our problems to start the applications that we're building or requirements are coming to us to build projects they come from Engineers who have taken an Excel spreadsheet and they cannot get away from it they love love love their spreadsheets they have a spreadsheet that's 15 Megs it doesn't hardly open they have way too much data into it way too many uh pivot tables way too much macros it's just awful and so that's where a lot of our problems come from and from that we don't only build grid based web apps or grid based Solutions but it certainly helps with adoption and getting those users into these applications and making them feel more comfortable with the solutions that we're building so the teller grid has certainly saved us tons and tons of time in that space and then component libraries another component Library outside of terer was something we wanted to explore to with teler again I mentioned that it's a paid model for licenses to work with now there's certain situations that's not going to work for our clients so there's times where we're going to come in we're going to build a solution we're going to ship it to a client's environment and then we're done we hand it off to them their it their hosting in their environment their development team that happens enough to where this is something that we needed to explore when we do that the client's going to need to have a paid license to T to and so again that's not something that's always going to work for our clients and so we needed to at least kind of explore what other options there were out there I realized now after seeing some of the presentations that some of the dark screen may be a little tough to read so I apologize we'll still talk about this but yes I am a dark themed person sorry for you light themers out there on the left we've got a Blazer implementation of aeric grid on the right we've got a react one now both pretty simple on the Blazer side of things we've got some razor syntax it looks kind of like XML um it's got six columns and it's got sortable equals true that's all you need to sort a grid display a grid and make each of those columns sortable sortable equals true that's pretty nice on the react side of things you've got three columns I could have put six in there I put three it still gets the example across sortable equals true sort equals sort on sort change set my sort that's now three four a couple different things that you need to do just for the Sorting so sortable equals true or sort equals true sort equals sort on sort change set my sort there's a couple different things you got to remember in there and so right away the Blazer side of things was certainly a little bit more appealing again some perspective on the react side of things though again we weren't we were trying to hide our bias right we're trying to make sure that we're giving everything a fair chance and you know it really came to us like hey I can actually inject my own sorting algorithm in here if I want wanted to or if I have really smart people that are doing nothing but sort or come to the table with some really really strong sorting algorithm you can inject that in to react really easily okay that's kind of cool actually that's kind of nice all right that's so you know maybe not necessarily a super negative here but for us sort equal sortable equals true has been kind of key here and and kind of the same thing applies for other different options within that grid pageable equals true filterable equals true that's all it needs there's quite a bit more to react and view side of things from the components Library side of things um I've got three listed up here with the fourth one we'll talk a little bit more about that fourth one here uh mui I may be pronouncing that incorrectly I understand that uh beautify and mud Blazer those are going to be the material themed component libraries that we found specifically to support this pilot project they're both pretty supported um very easy to use so no really complaints from any of those three you know those pilot projects went pretty smooth with those the final one with custom devops artifacts um so we have bought into Azure devops you know boo yay you know depending on what side of the house you you fall in here what we can do and what we have the option to do now we're not doing it all the time but there's still the option now with custom devops artifacts is we could actually host that privately and pull those into our projects so when we start making components or reusable chunks of code we could host those through nougat npm pip Maven what have you and that's already done for us so you know we could take these these component libraries the mud Blazer go build our own and kind of blend them into our Solutions so that was certainly a win and again there wasn't really a downfall here for any of the different options but certainly something to consider uh search with auto complete I'm not going to go to this one too much they were both pretty straightforward and I understand that again sometimes it might be a little tricky to read some of the dark screen but not too much to this they were both pretty simple and straightforward to implement so a lot of the other components were pretty nice and then again from the mapping component we again kind of had an idea of of what this was going to look like Blazer was not anywhere on the map for this one no pun intended but uh you know the Google Maps API leaflet cesium other like arcgis from ezri these are all really really strong JavaScript libraries that we considered and we have used in the past so you know if we were going to go that Blazer route which we did we were still going to need to have to write JavaScript if we have a mapping components so that was something that you know still had to be in our mind when we were trying to make this decision moving a little bit outside of the strict development of that pilot project there are other things that we wanted to consider too and that's what we're going to kind of get into now I've got on here learning curve and documentation is kind of the next thing that we wanted to talk about learning curve we had an idea of what this was going to look like from the doet side of things with the Blazer side it was probably going to be a little bit quicker than react and view and it was you know full disclosure it was but the magnitude of it we'll talk about in a little bit but from the documentation side of things again from the hello world side of things we need to make sure there's good examples out there two years ago Blazer was still pretty new so you know were we too bleeding edge to have good examples have good blog posts have good stack Overflow questions right if you're if you can't go find a stack Overflow answer to the problem that you're having that's a problem and you know this was again pre- chat gbt and pre-pilot but if those questions and answers aren't on stack Overflow are we the ones having to make those and try and figure that out that would be a pretty big concern for us cuz you know how how long could that delay you if you can't find the answer for what you're looking for so these are all things we wanted to consider from the documentation side of things both had pretty good docs they were pretty easy to use again a little bit biased we're used to the Microsoft docs so this was a a straight one to one we're using the Microsoft docs for um our MVC projects our razor page projects and that just transition straight into the Blazer projects so no issues there and again we were already using C for our logic so that was an easy transition from react and view it was also a pretty easy transition there the documentation was really good there was quite a bit of examples out there plenty of blog posts I put a little cave on here of react hooks versus class components so when we did this the react documentation was not very clear that hey all your friends their friends their grandmas they're all using racked hooks you should use that we did not see that on the documentation and it was not super clear to us so we did it through class components um we realized now that you know maybe we would have changed our mind about react but here we are we didn't do it with react hooks so you know there's a little bit of a caveat to that and definitely want to recognize that the duration that it actually took to execute this pilot project was a huge win for the Blazer side of things and again there's going to be some bias here you know we're familiar with C familiar with that logic but we weren't familiar with Blazer and the guy that took and did the Blazer project it took him one night to do this build that pilot project in a single night the two of us that were working on react and view it took us two weeks of working nights weekends whenever we could find time right with busy schedules to actually get this implemented and so when we sat down and had that conversation with them like what the hell man you did this in a night so that was a huge huge win for our team for Blazer and again you know a little bit of bias here so um you know if your team's already strong in typescript you know that may be something that happens a little bit different right your Blazer timeline may take a little bit longer but for us again that Blazer guy took him one night that was a huge win if we could take what we're doing now and spend quite a bit less time moving forward talking about talent pool and team structure um kind of building off the last talk a little bit from this um we're going to talk about LinkedIn here shortly but um our team structure is certainly something we had to consider too so we're software consultants and we're working on a lot of Green Field applications sometimes our projects are really big scale you have a whole team of developers five six seven eight 10 however many developers sometimes you have one and so if there's a clear divide of work you know are we going to be in a problem here if we've got five react developers and five net developers and we've got a ton of react work with not a ton of uh net work what's that going to do to our project and our team structure right who are we going to have to go hire for re or who are we going to have to go put Rex out to hire for so these are something that we wanted to consider too I'm going to show a LinkedIn I know the numbers are probably going to be pretty small so I'll read them specifically um we had an idea of what this was going to be to but this was pretty drastically different from uh in favor of the Raa and view side of things so just going to LinkedIn searching for reactjs and clicking people so how many people have react in their profile of some way shape or form about 3 million there's 2.8 million people that's a lot of people right it's a big fish there's a lot of people out there you could probably go find a react person tomorrow if you needed to hire somebody so that that was a big win right you know the people were out there the resources are available view about a half a million 512,000 people so still quite a few people out there probably a little bit tougher to find a view person but um chances are you're going to find that person Blazer not so much 34,000 and this is actually from about a month ago so this is like recent recent so imagine that two years ago that that number was probably way way less and uh so I mean that was a concern that was a concern right there and kind of to build on that we've been interviewing since that two years we've interviewed a ton of doet people and not a single one of them has ever said that yes I have worked on Blazer so you know take what you will with that they've all picked up Blazer pretty quickly but I kind of the moral story of the of the staffing pool was if you wanted to find a react person tomorrow you probably could that Blazer person they're going to be a lot tougher to find and they may not be looking for a job either who knows moving into the developer experience right you know if you're when you're building these applications are you having a good time are we frustrated with this similar to how we were frustrated with razor Pages you know we didn't want to go from some tool that we didn't really love or some framework we didn't really love into something we didn't really love again right you know you wanted to have a good time when you were developing when you were working wanted to enjoy it and then the tooling available um what sort of options are out there from an ID perspective from um other third party libraries things along those lines from this side of house we were very familiar obviously from the net space with Visual Studio vs code of course we use that all the time this was pretty Universal for both for for all three of the different Frameworks so no real complaint here there were tons and tons of examples or uh templates especially from the visual studio professional side of things for blazer for react for view so no real complaints there now on the second icon there there's a little fire icon if you're familiar with this one this is actually the hot reload icon out of Visual Studio people love hot reload and myself included we want that instant gratification right I'm I'm in a debugging session I see something I don't like or I see a bug I want to go change it immediately hit save I want to see that reflected in the browser hot reload works really really well for react and view right Works awesome for Blazer it's it's kind of Hit or Miss it's kind of Hit or Miss and I don't know if that's going to get a ton better than it is right now it's gotten better but I don't know how much better it's going to get because it's still got to compile that down to web assembly and get that pushed out there and some of that process you know is still kind of out there for me but I don't know if it's going to get a ton better so that was something that we wanted to consider too and then the third icon uh is the GitHub co-pilot icon so I mentioned that this wasn't really around two years ago so it didn't factor into our decision but if you're using co-pilot today it's a really really powerful tool right it really helps with some of those things that you don't want to spend a ton of time thinking and things that you've already done it's a really good option for you and same thing with chat GPT with co-pilot today I've never really gotten strong razor syntax out of it to fuel my blazer so that's you know something to consider right I've always been able to get really good typescript whether it's with react view or just playing typescript so probably a win on the JavaScript side of the house now chat GPT is a little bit different story I've had plenty of success getting tons of Razor uh syntax out of chat GPT so you know just depends on what tools you have in your tool belt at that point in time cicd everybody's favorite thing to talk about maybe not necessarily do um I mentioned that we're on the Azure devop side of things so specifically how did this play into our build pipelines our release pipelines what did this look like for us where were where were we going to see this you know everybody loves learning yaml right so um this is this is not something that we're super familiar with we're familiar enough we know where the documentation is we know how to kind of dig through it but sure as heck do not like to write AML so what's this going to look for us if we go down the Blazer route what's it going to look like if we go down a react route or a view route and quite frankly they look pretty simil and I guess after seeing how similar they look you okay yeah that makes total sense I guess they would be similar so on theet side of things you've got your specify your version use Net 7 I need to restore itet restore I need toet build and then I need to package things up to publish them out to um my release Pipeline on The reative View side of things it's pretty much the same just with some different commands I need to specify what version so I've got node 16 18 20 whatever version of node you're using I got to do an npm install so I got to restore those packages I need to run some build command of some sort um probably within your package Json file or some mpm script I've got to package that up get it ready to rock and roll and I've got to publish it out so those look pretty similar the huge benefit for us choosing the Blazer side of things is this is the same build pipeline that we're using for every other net project we're using so our MVC build pipelines look exactly the same as this and this actually came from a template it's not even just a single file so when we right now when we've got both our bill our back end and our front end they're using a template file so if I need to inject another step in there so I need to run like a sneak vulnerability scan on my dependencies it's really easy to do and it's worked in both places so that's something that we would we know was definitely been a big win for blazer for us if we wanted to do that for reactor View and you're splitting kind of those those pipelines you'd certainly have to go figure that out in a different language so something to consider I've got a huge list of honorable mentions these aren't things that we spent a ton of time on but I think they're worth considering still especially today um performance performance isn't always like the biggest deal breaker for us you know typically when we're building apps it's for the tens of users it's for the 25s of users the hundreds of users we're certainly not on the Google the Facebook scale of what people are working on so while performance is always in our mind it was certainly not a deal breaker and if you've ever worked with blazer that first load sucks it is so painful you got to download all those DLS into the browser and it's got a cach them after that performance is great no complaints there but that first load is not going to be fun and if your users are not are not ready for that and they're expecting a quick page load that's going to be something you need to going to need to communicate with them subsequent loads loads after that again the browser cashes them pretty aggressively so it's not too bad but that first load is not good kind of same thing on the react view side of things you still got to load that JavaScript right but typically it's going to be quite a bit smaller you know the the Blazer side of things I've easily seen it 15 Megs so it it can get pretty large pretty quickly depending on what you're pulling in browser adoption and like long-term support stability especially from the browser adoption we felt pretty safe here on both sides uh Blazer WM especially compiles down to web assembly so web assembly is a standard okay we feel pretty safe here javascript's been around for quite some time so again felt pretty safe here didn't really feel too too worried about that especially from the browser adoption side of things but the long-term support and stability wanted to think about it a little bit I don't know if anybody's ever worked with like silver light before but um I know some people probably have a horrible memories about that thankfully we never built applications using silver light so we dodged that but nobody wanted to go through that again right nobody wanted to get that email or that blog post saying hey it's going away and there's nothing you can do about it you're going to have to change your tooling right we didn't want to change our tooling to then have to go do that again in a year a year and a half so that was something we wanted to consider here and um you know we certainly felt pretty safe with Blazer and especially from the reactive view side of things it felt pretty safe there too crossplatform development not a huge concern here they all kind of offered their own uh crossplatform options um zamer forms was the option two years ago it's now Maui um react native VI native I think is what it's called so it's there we're not doing it too often but it's something to consider legacy app integration with blazer that's pretty non-existent from a legacy app integration so if you got a long running production app and you kind of want to convert it over to Blazer you're going to have to do some really tricky things to make that work you're going to have uh one sort of web application over here and then probably inject in some different routing to direct you to a Blazer application and you're going to certainly feel that when you're doing it so it's not really a legacy app integration but um you know that would be how you do it but on the reactive View side of things it's kind of what they advertise right oh start with your big application just peel away component by component do it and react and then push it back into your project and you won't even notice so that was definitely a win over there um integration with the Microsoft authentication Library Microsoft entra ID Azure ID that keep changing names on me um this is something that we definitely needed to consider and was part of the pilot project but not really like a you know a Forefront it was just something that was a mandatory requirement and it is for pretty much everything we do we don't really build any public applications so it's something that we needed to have you know our applications need to be protected by something and that Azure ad entra ad uh is is what we typically use for our authentication and then lastly I've got Azure and AWS infrastructure again there's there's definitely some perspective here right you know think about what you're doing and what you're trying to do in the cloud if you're just building VMS out in the cloud that's probably not the way to use the cloud it's an option you know they give give you those options but it's probably not the option um with theet side of things the app Services the W you know things along those lines we were already really really familiar with the services out there for react and view were pretty similar there still be some learning curve there but again don't necessarily stand up VMS and then same thing on the a AWS side of things the support for net in AWS has grown tremendously since doet core and moving into 5 6 7even 8 coming out next week um so you know we felt like the options were there whether we knew about them or not or had already used those Services was a different story but you know the options were there so that was that was at least something to consider going into kind of a retrospective about our pilot project and everything that we had talked about it was really really clear to our team specifically what direction we were going to head after we sat down kind of did the compare contrast what' you like what I like you show me yours I'll show you mine sort of thing I think we all sat down and said okay on three go ahead and say what you're going what you think our options should be and we all said Blazer it it was a no-brainer for us I kind of tried to put a score card up here a grade card a report card whatever you want to call it and again remember this is definitely really biased I'm not going to tell you that Yep this is the grade card for everybody's grade card but for us you know it certainly seemed more green more A's and B's in the Blazer category so thus we moved to Blazer but again kind of the moral of the story of this is be strategic about what you're trying to do don't just take that hello world or go to a conference tomorrow or today walk away and say hey I saw this really cool talk on react let's go use react go deeper right go a little bit deeper go past hello world don't just rely on flipping a coin to pick out what sort of spa you're going to use moving forward so that's uh that's what we did hopefully that's a little bit insightful and go Blazer but no I mean at this point in time I'll open up for any questions that anybody might have yes seems like most of the points you considered were iset supported Tex or is it we going be writinga kind of from your scard perspective the same and not to look at Ang yes about yeah so the question was why do we now look at angular is that correct yep um boils down to there were three of us is short story now um you know two years are passed and we've done an angular project we thought it's great would we have gone back and done things differently it's hard to say we're still really really happy with blazer But to answer your question the short answer is there are three of us and we had to draw the line somewhere right there's a lot of different options out there I'm sure there's a Java opt Java option a python option we could have picked so um you're right react and view were very very similar so it just kind of fell to what what we were kind of leaning towards at the time yes when you're doing your pilot project and you're paralyzing like that how do you pick what res get what do you that those resources are bring their own bias yeah yep so the question was um when building out our pilot project how do we pick who did what and how are we not being biased um yeah that stuff uh so specifically the guy that did Blazer had never worked with blazer before um obviously we were all net developers to begin with so you know was going to be biased but we were certainly very eager to at least explore react and view right we had seen and we've done a react project two since then too and we've enjoyed it but you know it's really hard not to bring bias into it I think we we tried to be very very clear on that up front and you know react was definitely a very close second um I think definitely I showed the slide with the calendars on it that I mean that was a huge game changer for us the learning curve that he went through that that time duration was was a pretty big deal breaker for for us so um you know it's hard it is hard not to be biased and we certainly were a little biased but you know we had to put that aside to some extent because we were very close to choosing react I think at the end of the day too yes sure so the question is um when we're hiring have we found have we looked at people who are familiar with react and View and trying to convert them to Blazer um not specifically we do have some projects and some teams that are working on react so our typically our Recs that we're putting out are standard net recks um so we haven't run into situations where we're putting out a react wreck and saying oh okay this person's got a bunch of react let's see if we can convert them to this um because I think there's enough net users out there andet uh developers so um specifically we're not necessarily putting out recks for those rack people people you know if we run across somebody who's got a good react background we you know sure we'll have that conversation and stuff but that may be more informal um something you you cross somebody at a conference or you know at a bar having a beer or something like that U but typically our Recs that we're putting out are are standard.net recks and that's what we have found has worked um again kind of going back to that learning duration it's it's taken us about a week for most of these doet users to really pick up Blazer and at least get running with some of our projects so we haven't really found that again the Blazer question has always been kind of a bonus but again we haven't found a single person yet who has actually said yeah we've got Blazer background so yes the makes it kind of a no-brainer for Blazer um as your project evolves you might find yourself needing other things that are much stronger in the job yeah uh yeah to some okay so the question was um you know the Blazer side of things definitely favored the T grid are are there any concerns with some of the more JavaScript based um things that you can do in JavaScript like virtualization and and things along those lines so from the Blazer side of things all that stuff is supported too um so you can do virtualization on a grid a lot of their autocomplete functions um they're newer you know within the past year or so they weren't necessarily there two years ago but they're certainly there and there's other options to do that natively with React 2 or uh sorry with blazer as well it's not a straightforward but there are ways to definitely tie into that and then to that too you know you're not you know so siloed into Blazer if you still need to write JavaScript to do something you can do that um so the mapping component example we still have projects today with mapping components where we have to inject tons of JavaScript to do that sort of thing so um would those make more sense to do a react or a view probably but um we're still happy with blazer so yes it's okay it's after launch I understand come to either I mean sure yeah yeah so uh the question was why did it come down to one over the other or instead of you know why not having maybe a hybrid approach or something along those lines um I think really what this boils down to is so typically we're building a lot of Green Field applications internally for our for ourselves and for our clients um we have a lot of projects that support internal clients and a lot of projects that support external clients um if we have full say over what's going to happen we're probably going to choose Blazer just because we have the most Staffing available to it we're most familiar with it especially now but we like I think I mentioned earlier we have had projects where clients come to us and say hey we have an angular application you kind of clean it up for us and refractor it for us or add these features so being Consultants we still are not going to shy away from that networ specifically so I don't know if that necessarily answers your question but you know if we're choosing the text act that we're doing we have full control over it Blazer just makes more sense for our team specifically yes um did I you say you guys ofation were you able toy time to yeah sure uh so the question was uh I said that we did this over nights and weekends sort of thing could we justify this with you know business hours or during the day right um we probably could have now we took the effort on this on our own behalf um so from our company's perspective as being Consultants the most important thing is to build a client for every hour that you're working right so that's just kind of the nature of a consultant um could we have packaged this into during the day yeah absolutely but you know this was something that we were all pretty eager about so you know working a little bit of nights and a little bit of weekends wasn't really that big of a thing it it was about 2 weeks at the end of it so it wasn't you know we spent months years sort of thing trying to investigate this and after kind of that two weeks any new development we certainly did during the day and we definitely build to a client all good questions anybody else have another question yes yeah yep something like that BL uh so the question is how does unit testing work for Blazer um yes it works really well in react view um unit testing definitely falls to the category of a nice to have for us uh you know we should do it more definitely don't tell don't tell anybody that I said that but um there are options for Blazer unit testing they're not as widespread as the JavaScript Frameworks um B unit would be the one for Blazer I don't think it was there two years ago but it certainly is now it's okay um most of our unit testing would certainly fault it's probably more of the back end is where we're going to spend most of our time doing that unit testing which uh there's tons of libraries that are supported from the net side of things to do the unit testing on say your backend apis so yep good question all right well thanks everybody for your time today

Channel: Techlahoma

Views: 4,126

Keywords:

Id: Q1XTZflrVKI

Length: 40min 22sec (2422 seconds)

Published: Tue Jan 30 2024