If you are asking this question, probably the best answer for you is old fashioned sales/marketing.
Relatively high paying jobs usually fulfilled via network, which happens the way you described ("land in my lap").
You need to do marketing activities to extend your network, so more work lands in your lap.
In person works best if where you live has opportunities for this. Try chamber of commerce if there is one. They usually have lots of events for local business owners where you can meet with many potential customers.
Try cold emailing otherwise, it has the best ROI when done right.
Bonus points: This skills will be needed to get the project you are working on off the ground too.
At this point my only hope is that they bake TS into the JS engines so that we could use type information at runtime. It's too entrenched to replace otherwise unless we jump into a new UI paradigm.
Checkout git subrepo [0] if you also find working with submodules cumbersome.
It has a different set of trade offs and works without any problems or changes to your workflow if they fit. (Only thing it has problems is rebasing, under specific circumstances)
Just checked subtree and while they aim to provide the same thing, they are using different ways.
- You can mix subrepo commits and main repo commits freely in a single commit, it’ll take care of submitting only the relevant changes when pushing upstream.
- Publishing changes from a subrepo iş just a single command.
- Subrepo adds a .gitrepo file to the subdirectory for metadata
The readme on repo does a good job of explaining things.
I haven't ever actually used git subtree to push changes, but I'm pretty sure that all of those are true for it too, and git subtree doesn't need a `.gitrepo` file so that seems like a point in its favour.
I'm sure there are advantages to git subrepo, but I am still not sure what they are.
The typewriting participants were explicitly not touch typing - they were instructed to... type with a single index finger...
> participants were instructed to either (a) write in cursive with their right hand the presented word with a digital pen directly on the screen, or (b) type the presented word using the right index finger on the keyboard.
> The typewriting participants were explicitly not touch typing - they were instructed to... type with a single index finger...
Looks like this did this because "allowing the use of (the fingers of) both hands would cause many unforeseen effects on the brain, which would make it hard to interpret the results," since handwriting is done with one hemisphere.
That might not be enough without any assessment of the subject's typing skill. Touch typists have effectively memorized the keyboard layout and would need less effort to find the key to type, even if limited to one finger at a time
still people who are touch typists are able to find the characters faster on the keyboard than others. this message is written that way to test that out, in parts where it was possible.
however, in my case the blank keycaps did make the task a bit more difficult. i would write faster in cursive, and it might feel less effort.
also the reason was outlined:
> Allowing the use of (the fingers of) both hands would cause many unforeseen effects on the brain, which would make it hard to interpret the results.
For server-rendered UI, look for resources that uses Razor, ignore Blazor stuff at the beginning.
For .NET Backend/JS Frontend, look for resources that uses minimal APIs. MVC is also good but has a lot of backwards compatibility baggage that led to the creation of minimal APIs.
Certainly I also can't imagine how you would get strong performance out of Server Blazor in real world/Enterprise conditions. RPC busses are going to RPC and roundtrips are still roundtrips even when SignalR-backed web sockets. Flooding UDP web sockets with HTML chunks isn't necessarily a great idea, even if HTTP3 (QUIC) kind of/mostly succeeds at it, but SignalR as good as it is certainly isn't HTTP3.
On the other hand, Client Blazor has huge initial overhead (it compiles a form of the entire .NET platform in WASM; you can golf it down a bit, but it's still an entire runtime and GC and most of a standard lib depending on what your app does, and its dependencies), but once it is loaded it can be as performant as just about any other Virtual DOM-like (modulo the overhead between DOM/JS and WASM, but that overhead is surprisingly small in current browsers and seems to only get smaller as browsers continue to optimize WASM scenarios).
I don't think I'd recommend it for most consumer-facing websites any time soon, but in my experience Client Blazor is still much better than Angular for performance in an Enterprise/Internal App scenario.
Blazor Server in an enterprise (intranet) is extremely fast because the network is extremely fast.
Across the Internet, it's still quite fast if you use Azure SignalR service, which is effectively a globally distributed CDN. Most commercial apps use this service.
Blazor WASM is better than I thought it would be. My company has built a healthcare SaaS app that has ~5k daily users on it and no one has complained about the initial rendering and download time to pull down 25MB on the initial load. This sounds like a lot but with modern broadband, 5G, and CDNs, this takes about a second or two.
It's the slowness/sluggishness, not the looks. Most of the time even a simple interaction like clicking a checkbox takes ~1-2 seconds, which probably comes from tracking the state on server.
(I don't mind outdated for .NET stuff, nearly everything from enterprise vendors looks like it just jumped out of WinXP anyway.)
I've never seen that behavior, even in the preview/beta versions. That example is less complicated than the sample project that you get when you create a brand new project from the visual studio template (it's something like increment a counter on the server side via button clicks iirc).
There were definitely some quirks and issues early on but they've done a pretty good job at smoothing that stuff out since it's gone through two LTS version of .NET.
The pipeline for something like that is click->js/wasm websocket->server code->websocket->ui updates. If you're doing something absurd on the back end when a checkbox is clicked, sure 1-2 seconds but that's a developer problem, not a Blazor problem. If you put me in front of a React app, I'd probably do something stupid like that too because I don't have much experience with it.
I suspect your complaint is more related to .NET/Blazor making it easier for less experienced developers to develop a working site/page with a lot of spaghetti where that same developer would struggle to create the same page in another ecosystem. If you compare to equally senior/experienced developers in different frameworks, I suspect you'd see the same basic performance from the two platforms up until a scale that very few of us are actually working in. Blazor can be quite fast if you don't write bad code.
I find a lot of the complaints about .NET to be that it enables developers who write bad code to get things done inefficiently instead of not being productive at all. IMO, having senior developers doing code reviews is pretty essential if you have junior developers on a team but the ability to build something, even if poor, can really accelerate the learning process when a senior person can look at a complete project, point out the issues and show the difference that the corrections make.
Sorry for the rant and sorry if this doesn't really apply to you specifically.
I get where you are coming from, and I'm on the same page. I'm not complaining about Blazor, I'm complaining about not finding any good examples. That's why I'm asking around.
I'm looking for something that will make me "wow, Blazor can be used to build great apps!" or "ok has advantages over the React/Vue etc. equivalent".
Because if there aren't any, in similar thinking with parent, I'm afraid that it won't catch up and it'll go the way of silverlight, so I refuse to invest any time.
Something is wrong there, probably someone is screwing up form validation in their component framework or something, but IME that’s not a Blazor thing.
Drop-in means replacing an existing thing with a new one without changing anything.
This is not compatible with other servers plugins/data/configurations, so just replacing the binary and expecting to continue where you left off is not possible.
Relatively high paying jobs usually fulfilled via network, which happens the way you described ("land in my lap").
You need to do marketing activities to extend your network, so more work lands in your lap.
In person works best if where you live has opportunities for this. Try chamber of commerce if there is one. They usually have lots of events for local business owners where you can meet with many potential customers.
Try cold emailing otherwise, it has the best ROI when done right.
Bonus points: This skills will be needed to get the project you are working on off the ground too.