I've faced the same issue with multiple teams,in different business domains, some with rathe heavy UIs (canvas rendering, sophisticated graphs etc).
From my experience, modern frontend frameworks seem to not have taken into account these kinds of problems. To my recollection, in all of those cases, we ended up managing state and rerenders with vanilla, rather than react or angular.
A rewrite on those occasions, I do not consider possible. Most businesses are way to deep into frameworks.
What I personally advocate is to choose frameworks with valid escape hatches, and then make sure to staff a team with JavaScript programmers rather than some-framework Andies.
In an even larger scale, I advocate for web-component based solutions. I try to stay close to vanilla as much as I can. Whether I like it or not, it's the highest value professional decision, imo.
I'm using Tuxedo for the last year for work and it's been amazing. I've been using the InfinityBookPro. Their support is insanely good, they even helped me troubleshoot OS issues caused by my own stupidity, quite often.
In terms of quality, I find that the modularity of the laptop under the hood is amazing. I can tinker and change stuff with ease. Battery lasts ~9 hours while coding, browsing, watching videos, and video calls.
I will highly likely buy more for my company as needed.
I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense.
> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.
Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground.
I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality:
> But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send...
You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything.
I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.
> I don't understand the allergy of the so called "back end" developers with JS
I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable.
A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and flows, e.g. List/Show/Edit (which is fine in many cases), but to do complex UIs that many modern apps need, it's a huge pain. Worse situation to dev is forcing 80% of the functionality via server side, then the last 20% you ask "front end" to wedge in with jQuery style development.
As someone who suffers from this allergy, I'll chime in with 2 additional thoughts:
It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with.
Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.
Clay is very malleable and has all sorts of wonderful properties. As a building material it has fundamental limitations as it’s less suited for tensile loads.
It’s funny, because you can continue the analogy and compare optionally typed languages (like TypeScript) to adding wood/rebar to a brick building, allowing it to go vertical.
A good example: the Chrysler building sports 3 million specially made bricks for its facade. By blending both materials, you receive the thermal and maintenance benefits of brick with structural integrity of steel.
.NET 8 comes with Blazor United (renamed to simply Blazor) that combines the Blazor Server and Blazor WebAssembly frameworks.
For client side components C# code is compiled into WebAssembly that manipulates the DOM just like JS.
Today with Blazor Server, the main drawback is the slight delay you can get when you click something. .NET8 essentially blends Server and WebAssembly and solves the problem, even giving you the best of both worlds since WebAssembly has high first load times, .NET8 Blazor loads initially with Server side and provides client side after it loads all resources.
I think that transformed news by language models is just another hole to jump in. I'm definitely tired of the internet being filled with mostly junk nowadays. I just don't like the idea of learning things via a language model. I prefer to filter this myself. Maybe it's more effort but to me feels more valuable.
I mean we whine all the time about Google directing your searches to specific places. This feels the same of worse.
Recently started my own company with a couple of pals. I intend to focus on open source as much as my income lets me.
This is our first try to create something useful and open source. It's not groundbreaking but still it took some effort to test cover this as well as make it UX friendly.
Let me know what you think.
Created a query builder for microsoft's KQL for making my life easier for a client project. Turned out that this company still uses this library after 5 years :).
What are your thoughts on KQL? I’m biased, but I love it. Kusto/ADE as a whole is an amazing platform - it’s a shame how poorly it has been marketed outside of Microsoft
Hey, first of all congrats. To be honest with you your description is vague and I expect not for no reason, so I'll also give a generic answer as I believe the "correct" answer (if there is one) lies within the specifics of your domain.
I see no problem in extending an already successful product with a set of new features. You can always keep your promise regarding one-time licencing, that does not mean you cannot create a business model on top of that that leverages addons for example.
Personally I feel that spinning up a standalone product involves more risk as a rule of thumb, but again, the answer lies within your domain.
If I had the choice I would probably leverage the "already achieved" success and since you believe that this feature will help your customers, I would give them the feature within my product suite. Also more revenue does not exclusively mean higher price. It might also mean *more* clients.
