Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Not SPAs, What?

macwright.com

Post reply on HN
Print view View original

161–170 of 456 posts

Re: If Not SPAs, What?

#161

Post by kumarvvr »

ablekh wrote: post #102
jolux wrote: post #45

One entry in this space that doesn't get a lot of attention is ASP.NET Blazor [1]. Blazor gives you the option of writing views in C# that will actually compile to WebAssembly and run in the browser, or run on the server and send DOM updates over a SignalR connection, a lot like LiveView. [1] https://docs.microsoft.com/en-us/aspnet/core/blazor/

Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo a…

2 MB should not be an issue nowadays. Considering 5G roll out & substantial coverage in most mature markets, in say, 2 - 3 years, 2 MB is acceptable.

Re: If Not SPAs, What?

#162

Post by kumarvvr »

wyattpeak wrote: post #126
ablekh wrote: post #102

Earlier quoted context omitted.

Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo a…

Is offline mode widely used? I remember it being released to great excitement and then I never heard about it again. I assumed it died out when being offline became too much of an edge-case for your average user to be worth dealing with.

I would describe it as more of a "tail end" case, a small percentage of use cases, but a long list of users.

Re: If Not SPAs, What?

#163

Post by resoluteteeth »

jolux wrote: post #135
ablekh wrote: post #102

Earlier quoted context omitted.

Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo a…

Are the latency issues specific to Blazor Server or are they inherent in any framework that uses this pattern, like LiveView?

It doesn't seem like there's any major difference so it's interesting that latency is perceived as being a reason not to use blazor server in production but not as such with liveview.

Re: If Not SPAs, What?

#164

Post by kumarvvr »

unsignedint wrote: post #81
jolux wrote: post #45

One entry in this space that doesn't get a lot of attention is ASP.NET Blazor [1]. Blazor gives you the option of writing views in C# that will actually compile to WebAssembly and run in the browser, or run on the server and send DOM updates over a SignalR connection, a lot like LiveView. [1] https://docs.microsoft.com/en-us/aspnet/core/blazor/

And best of all, both Server and WebAssembly has a lot in common, so it is possible to make that movment as needed. (I often prototype in server, as it's a lot easier to debug, too!)

If you are using Blazor Server, you don't have to even think about REST APIs. Depending on your app, that might be good or bad. But if you primarily target browsers on Desktop, you can tremendously improve productivity, because you can directly use C# POCO Models for UI and backend data services.

Re: If Not SPAs, What?

#165

Post by bob1029 »

On the spectrum of client-server rendering, I am leaning very far into the server-side philosophy.

Right now, we use Blazor with server-side rendering for our internal dashboards. This feels almost perfect to me. There are still some rough edges and I still have to ultimately deal in terms of HTML/JS/CSS.

I've got a side project that takes the Blazor server-side concept to the absolute extreme. But, I haven't had much time to work on it this year considering... Hoping to get back into the crusade in early 2021. Looking to pilot it as a replacement for one of our Blazor server-side apps in 2H 2021. One of the bigger objectives is to develop a web application that is perfectly auditable and secure as possible. If you render final client views on the server, you can DVR precisely what each client is experiencing. The client source can be ridiculously lightweight and betrays nothing regarding the business. My prototype currently serves a ~50kb single-file HTML payload that runs the entire show for each client. I am looking at things as deep as server-side rendering of the mouse cursor. Looking at each client as a simple event stream from the server's perspective is a really neat way to organize this problem.

Re: If Not SPAs, What?

#166

Post by pcjthug »

Scarbutt wrote: post #105
jolux wrote: post #45

One entry in this space that doesn't get a lot of attention is ASP.NET Blazor [1]. Blazor gives you the option of writing views in C# that will actually compile to WebAssembly and run in the browser, or run on the server and send DOM updates over a SignalR connection, a lot like LiveView. [1] https://docs.microsoft.com/en-us/aspnet/core/blazor/

ASP.NET core is still all the same over-engineered enterprise baggage you see in the Java world.

it smokes Spring in benchmarks, often by a factor of 10x or more, and on plaintext it's 50x faster than spring and even with the fastest Rust/C++ frameworks, so must be some awfully light baggage

Re: If Not SPAs, What?

#167

Post by jolux »

resoluteteeth wrote: post #163
jolux wrote: post #135

Earlier quoted context omitted.

Are the latency issues specific to Blazor Server or are they inherent in any framework that uses this pattern, like LiveView?

It doesn't seem like there's any major difference so it's interesting that latency is perceived as being a reason not to use blazor server in production but not as such with liveview.

The audience for Blazor Server is probably an order of magnitude larger than the audience for LiveView, and it's mostly not the Hacker News crowd that needs to be won over, but the large enterprise with half a million lines of Web Forms that has grown into an unmaintainable behemoth.

Re: If Not SPAs, What?

#168

Post by kumarvvr »

bob1029 wrote: post #165

On the spectrum of client-server rendering, I am leaning very far into the server-side philosophy. Right now, we use Blazor with server-side rendering for our internal dashboards. This feels almost perfect to me. There are still some rough edges and I still have to ultimately deal in terms of HTML/JS/CSS. I've got a side project that takes the Blazor server-side concept to the absolute extreme. But, I haven't had muc…

> This feels almost perfect to me

This. This is the sentence I am going to use to describe Blazor Server from now on.

Re: If Not SPAs, What?

#169

Post by taeric »

dralley wrote: post #100
cblconfederate wrote: post #35

Earlier quoted context omitted.

That's not possible for SPAs outside localhost. Every single SPA i know is clunky, including gmail which is probably one of the most barebones. The lack of visual indication that something is happening or downloading alone is infuriating with SPAs. Most of them reinvent the browser in a very poor substitute that invariably fails to both be practical , and to mimic a native mobile app (i think the latter is the reason…

>including gmail which is probably one of the most barebones. And yet, it still uses 130 flipping megabytes of RAM, more than Youtube does, as well as more CPU than Youtube does at idle, as well as requiring several seconds to "start up" when first opening a tab. Ridiculous.

I think gmail is a bit of a parody of itself nowadays. For extra hilarity someday, try pressing "c" for compose as the site is loading. Literally seconds to get a compose window showing.

Re: If Not SPAs, What?

#170

Post by [deleted] »

Scarbutt wrote: post #97
throw_m239339 wrote: post #91

Earlier quoted context omitted.

> I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. It sounds crazy to say that now but Angular became big because it was actually quite lightweight compared to other JS frameworks of this era, declarative 2 way databindin…

In fact writing an REST/Web API should be easier than writing a server-side generated HTML website (no need for templating language, ugly form frameworks,...). Why is that easier? It's more work, you are now rendering two views instead of one, a JSON one(server) and HTML one(in the client) with all the JSON encoding/decoding that it entails. You are still using a templating language and, dealing with forms in React i…

[deleted]
Post reply on HN