5 ms·
Blazor WebAssembly on Azure Static Web Apps
- runawaybottle 6y agoYou can develop and deploy a frontend and a serverless API written entirely in .NET. Microsoft doesn’t miss a beat, huh? Where are my VSCode, GitHub alternatives, I’m watching you carefully, for all of our sakes. No thanks MS, VSCode is nice and all, but I’ll manage.
- pedro2 6y agoThat made no sense. MS is in the business of making software easier to make, so it makes all the sense. Are you sure you aren't a reverse shill? :)
- sbelskie 6y agoI’m not sure I understand the vscode connection. This is just Azure + Github from what I can see. The thing I don’t really follow is how exactly the client is handled here. Is there something special being done to generate the static content from the Client and or could you generate the same assets by doing dotnet build or dotnet publish?
- shrewduser 6y agoi wonder when we'll see some good UI frameworks that eschew CSS/HTML in favour of writing pixels directly to the screen
- deleted 6y ago[deleted]
- TazeTSchnitzel 6y agoQt has already been compiled to run in the browser, and that's a very well-known high-quality UI framework from C++ land. http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos/ http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
- strbean 6y agoMy first reaction to parent was "what toolkit would be great to target WASM with", second was "let's scan the replies..." Qt in browser gets me excited :)
- pjmlp 6y agoHere is one, https://platform.uno/ https://platform.uno/
- bob1029 6y agoI have started working on something along these lines. I don't write pixels directly to the screen and I am continuing to use the browser and all of its capability, but I have abstracted the client viewport as a 2d surface that I can set arbitrary pixels on from the server. There is a tiled diff mechanism w/ JPEG compression in between client and server for more efficient real-time update of dirty parts of the view. 100% of client events are processed server-side. All the client browser does is display whatever tile it is told to as quickly as possible. Biggest advantage is response time on complex views, followed by the ability to guarantee pixel-perfect presentation on any device capable of websockets and jpeg decoding. Caching of content is on a final tile basis rather than full viewport. This increases the hit-rate substantially, as tiles are not at fixed pixel boundaries, but rather aligned with logical UI elements. Fixed sized elements will more likely produce the same final tile(s) with equivalent SHA256 regardless of client device. Hashing is performed in terms of the UI element's properties (dimensions, size, text, color, etc), so cache lookups can be made along these lines. Biggest downside is latency - This approach has a similar practicality envelope as Google Stadia, et. al. WRT distance from datacenter. 2nd biggest downside is the fact that this technique is fundamentally incompatible with classic web development ideologies and requires new ways of thinking about solving problems. I personally find this last point to be a benefit, but I recognize it would prevent wider adoption in the community.
- taejavu 6y agoI pray you’ll never need to display blocks of text, or do anything with text input. Font rendering and text editing are no joke, and browsers do it well with HTML + CSS. Latency might be the biggest downside for your specific use case, but I’d urge anyone tempted to roll their own browser renderer to properly consider text-related concerns first.
- bob1029 6y agoI currently use System.Drawing to produce text segments. I am not attempting to replace HTML/CSS or pass the Acid3 test. I am just going for something that would be sufficient for purposes of building highly-responsive internal business dashboards and other utilitarian applications where predictable and fast layout is more important than arbitrary style support.
- tl 6y agoIt's more likely that some good non-web UI frameworks will write WASM-based backends, so that your pre-existing code works in a browser box with all of the good and bad that came with Java, Silverlight, etc...
- frou_dh 6y agoWhen developers get creative with fully custom GUI drawing then the user is often rewarded with dodgy text rendering.
- nahuel0x 6y agoFlutter is basically this.
- IggleSniggle 6y agoIsn’t this basically what Flutter is?
- Latty 6y agoSounds like an accessibility nightmare.
- chickenpotpie 6y agoOut with JAMstack and in with CSAMstack?
- taejavu 6y agoWhat’s the client bundle size for a “Hello World” in Blazor WebAssembly? Last I checked it was ~2.5MB, which makes it a non-starter for public-facing web apps, imo.
- cm2187 6y agoDepends which. An online trading platform? Possibly. But great for internal applications.
- taejavu 6y agoI’d argue internal applications are _the only_ acceptable use case for Blazor. I only mention it because this quote from the article strikes me as mildly disingenuous: > An app like this can basically scale forever, cheaply. It can put the browser to work (which was basically hanging out waiting for anglebrackets anyway) > It’s no more scalable than any other SPA framework as an Azure Static Web App, but it does require shipping a .Net runtime to every user. I’m surprised there’s rarely a mention of this important consideration in the discussions I’ve seen around Blazor.
- cm2187 6y agoMy understanding is that they do (or will do) some tree shaking to only transmit the bits of the runtime that are actually used. It's not like you will download a 60MB binary on every refresh. And it's not like a typical SPA doesn't come with its own bloat of js libraries. I do expect it so be slightly heavier. But to the point that a user will notice?
- taejavu 6y agoYep, and that's what the "2.5MB" in my original post referred to. So, a Blazor app that does nothing but print "Hello world" to the screen is as heavy as a horrendously bloated SPA that presumably does something of value. Yes the user will notice, just the same as they notice that horrendously bloated SPAs are slow.