3 ms·

Blazor might pull me back into software development. About five years ago after close to three decades of doing software development, I got tired of seeing so m

Blazor might pull me back into software development. About five years ago after close to three decades of doing software development, I got tired of seeing so much software being bent and shoved into JavaScript. I absolutely loathe JavaScript so it seemed like a good time to move on to something else, which in my case was IT security. Occasionally I write a tool or two for use by my team but most developer jobs these days require coding in JavaScript so I hadn't given much thought to going back to full time development work. Blazor however has been a joy to work with. My understanding is JavaScript will still be required for a while on most webassembly apps but for my uses I've been able to avoid doing any directly. Maybe in another couple of years the market will change and those who don't want to use JavaScript everywhere and are horrified that even embedded systems are flirting with js, will again have a place in the world.

bob1029 7y ago
I have found similar joys in using Blazor. Once you get past the boilerplate stage, the productivity gains go exponential very quickly. Component reuse + strong typing + no API controllers or JSON contracts = how web development should have always been. I've got elegant LINQ statements right in my component markup. Creating extremely complex tables and views is so trivial with this combination of technologies. I can even subscribe my razor components to CLR events and everything works exactly the way you'd hope it would. The SignalR link between client and server abstracts away a huge bucket of questionable practices, with some potential trade-offs. Perhaps there is some downside I haven't found yet, but at this point I feel I could live with whatever strangeness might begin to emerge from the path I have taken. In my experience, it is not possible to completely eliminate JS from the equation with Blazor. I've had to write a single .js file which I currently use for 3 things: Reading a cookie, writing a cookie and focusing an arbitrary DOM element. The focus concern I could probably alternatively handle with an autofocus attr which is dynamically inserted into the razor component, but somehow this seemed easier. Cookie or local storage interop requires JS. This is a very simple bit of code to write, and I would strongly recommend implementing it yourself to become familiar with Blazor component lifecycle events (i.e. how you make sure this JS shim is loaded into DOM before invoking its methods). I've been wanting to create a public GitHub repo with a more practical Blazor boilerplate app that might help others get started with this kind of concern a lot faster. Perhaps something like an LDAP-authenticated business operations dashboard. Seeing an actual cookie session token read/written and how all of the code flows for session management purposes can save days of frustration. I already see some options out there for Nugets that claim to handle Blazor session management for you, but in my experience these almost always get in the way and force techniques upon you that you really didn't want to work with. If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.
- mycall 7y ago
  > no API controllers ... I've got elegant LINQ statements right in my component markup. You do need to be careful with requirements before choosing this tight binding. If you want single source, that's a great idea. If you need single source for mobile web + mobile app, you will be duplicating code. There are other reasons for API and business logic remaining server side. > . If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole. How do you suggest performing method authorization without claims?
  - bob1029 7y ago
    There is nothing stopping you from developing razor components which are capable of dynamically adjusting depending on the specific device you are targeting. You can add some JS interop to handle these queries, and then pass the device type information as a cascading parameter to all components from the top. I am not sure what sort of authorization schemes you are concerned with. All I use the cookies for is looking up an active user session via whatever SHA256 token is stored there (if any).

bob1029 7y ago

I have found similar joys in using Blazor. Once you get past the boilerplate stage, the productivity gains go exponential very quickly. Component reuse + strong typing + no API controllers or JSON contracts = how web development should have always been. I've got elegant LINQ statements right in my component markup. Creating extremely complex tables and views is so trivial with this combination of technologies. I can even subscribe my razor components to CLR events and everything works exactly the way you'd hope it would. The SignalR link between client and server abstracts away a huge bucket of questionable practices, with some potential trade-offs. Perhaps there is some downside I haven't found yet, but at this point I feel I could live with whatever strangeness might begin to emerge from the path I have taken. In my experience, it is not possible to completely eliminate JS from the equation with Blazor. I've had to write a single .js file which I currently use for 3 things: Reading a cookie, writing a cookie and focusing an arbitrary DOM element. The focus concern I could probably alternatively handle with an autofocus attr which is dynamically inserted into the razor component, but somehow this seemed easier. Cookie or local storage interop requires JS. This is a very simple bit of code to write, and I would strongly recommend implementing it yourself to become familiar with Blazor component lifecycle events (i.e. how you make sure this JS shim is loaded into DOM before invoking its methods). I've been wanting to create a public GitHub repo with a more practical Blazor boilerplate app that might help others get started with this kind of concern a lot faster. Perhaps something like an LDAP-authenticated business operations dashboard. Seeing an actual cookie session token read/written and how all of the code flows for session management purposes can save days of frustration. I already see some options out there for Nugets that claim to handle Blazor session management for you, but in my experience these almost always get in the way and force techniques upon you that you really didn't want to work with. If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.

mycall 7y ago
> no API controllers ... I've got elegant LINQ statements right in my component markup. You do need to be careful with requirements before choosing this tight binding. If you want single source, that's a great idea. If you need single source for mobile web + mobile app, you will be duplicating code. There are other reasons for API and business logic remaining server side. > . If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole. How do you suggest performing method authorization without claims?
- bob1029 7y ago
  There is nothing stopping you from developing razor components which are capable of dynamically adjusting depending on the specific device you are targeting. You can add some JS interop to handle these queries, and then pass the device type information as a cascading parameter to all components from the top. I am not sure what sort of authorization schemes you are concerned with. All I use the cookies for is looking up an active user session via whatever SHA256 token is stored there (if any).