Live data from Hacker News

If Not SPAs, What?

macwright.com

131–140 of 456 posts

Re: If Not SPAs, What?

#131

Earlier quoted context omitted.

What is Live View not good at?

It's not suitable for using the client's computer to mine crypto currencies, doing graphics processing on the client, doing numerical processing on the client or doing anything purely on the client without server interaction. For things where you generally need a trip to the server anyway, like validations, it's great.

Yup, exactly. If you’re mostly building a client application (or a p2p client-server application!) but it happens to live on the web platform, PLV does not seem like a great fit...at least not this year. Honestly BEAM seems great it ought to be great for that generally!

Maybe if you ran the server portion of PLV in the browser...but then you’re just back at React anyway I suppose.

Re: If Not SPAs, What?

#132

> SPA pattern has failed to simplify web development The SPA pattern is fine, it is React Router and Redux that has overcomplicated things. Here's an example of an app written using the MVC pattern that is way simpler than the React stack: https://github.com/Rajeev-K/eureka It uses two very simple libs: A 500-line router: https://github.com/Rajeev-K/mvc-router/ A 200-line templating library that uses JSX syntax: http…

I suspected things were getting too complicated in this space when I read that someone wrote a 150 page book on React Router

Re: If Not SPAs, What?

#133

Micro front-ends and packaged business capabilities. Build encapsulated domains (views, events, apis, data store) with their own dependencies (not shared with umbrella app) and pluggable with meta data.

I genuinely understood nothing to that comment. Are you talking about frames? Please develop.

My company talked about using micro front ends for a while. basically there was one microservice that actually served the web page itself and all of the controls and widgets on the web page were pulled from other microservices via API calls that each handled their own internal state.

Re: If Not SPAs, What?

#134
post #37

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. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…

> developing became more and more inefficient

Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly linear and the past 5 years have not matched the growth I achieved in my first 5. Frontend tooling has never been better than it is today.

What I believe, is that the bar to build web applications has been lowered, and there are more programmers than today than ever before. You have people who are not experts in frontend development and javascript trying to build complex UIs and applications. So you take this person who doesn't have the requisite experience and put them to work on a paradigm with a lot of depth (frontend) using frameworks that are really simple and easy to get started with, but compound problems as they are misused.

Another factor is that since SPAs are stateful, complexity mounts aggressively. Instead of a refresh on a stateless page every few seconds, one page causes bugs that rear their head for the duration of the session. These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. But when designed properly, these problems are largely negated.

I'm not advocating that SPAs are the solution to all problems. I think there's gross overuse of SPAs across the industry, but that is not an indictment of SPAs themselves. That is someone choosing the wrong technology to solve the active problem.

With respect to angular (1, I never touched 2) specifically, I always found it extremely overengineered, poorly designed, with terrible APIs. But that's a problem with that specific framework and says nothing at all about SPAs at all.

Re: If Not SPAs, What?

#135
post #102
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…

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

Re: If Not SPAs, What?

#136
I love working in the SAFE stack since I'm a fan of F#. Being able to develop for the web using one programming language that gets transpiled to the needed JavaScript and uses the model view update pattern with elmish makes so much sense to me.

Granted, I am allergic to developing any JavaScript myself because of how many anti JavaScript comments I have read on hacker news ;)

Re: If Not SPAs, What?

#137
post #12

My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…

> When anything takes more than 50ms to react, it becomes mentally jarring to the user.

Depends.

Pressing a key and not seeing a character in less than 50-100ms, yeah, it's quite frustrating.

Clicking on a link and waiting for the content to load? Not so much.

Re: If Not SPAs, What?

#138
post #63

Earlier quoted context omitted.

Agree completely. My only concern is that so many imitations are attempting to pop up in other languages and you just can’t do it as effectively. There are so many tradeoffs present that happen to result in the necessary set of functionality to do this efficiently that aren’t easily present outside of the BEAM.

What about this can't be done with async/await?

It can be done, but you’ll see a lot of weak points. It’s probably worth a blog post to explain it. There are several layers in the language that combine to make this work.

At a high level, is the combination of process isolation, memory isolation, template delivery, websocket capability and resilience on top of all the standard web bits.

It will be really difficult to pull off with a good developer experience and minus several deficiencies outside of the BEAM. Anything’s possible though.

Re: If Not SPAs, What?

#139
post #84

The Phoenix LiveView pattern is one that I thought was the near-ideal interactive page architecture 20 years ago, long before Elixir and even before XHR was standardised. (We had other methods for AJAX and server-sent events to achieve it in those days.) It surprises me that there are so few implementations using this pattern today. The Meteor pattern is another good one for the user, if you like things better optimi…

This was super-interesting for me to read. I developed in Meteor for about two years. I started out a major fan, but was quite disappointed in the framework by the end. I'm now excited about Elixir/Phoenix/LiveView/BEAM and am about to spend a few months getting myself up to speed with that whole ecosystem.

Same boat, I got into Meteor for a while years ago (even built a side project that ran in production and made real money for a couple of years).

For the last year I have been writing Elixir/Phoenix full-time at work on a greenfield project. We have gone "all in" on LiveView and our using it in a significant portion of our system. I have been very impressed with it so far. When pairing LiveView with Phoenix PubSub, one can achieve Meteor-like 'reactivity' with remarkable ease.

Re: If Not SPAs, What?

#140
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.

What makes you think so? I'm actually curious
Post reply on HN