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

151–160 of 456 posts

Re: If Not SPAs, What?

#151

Post by pier25 »

The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap.

OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/Vue/etc in a multipage application. The problem is that to hydrate (make interactive) the server rendered HTML you now need to duplicate your markup between your server language and front end framework. The solution is to use the same framework in the backend and the front and write the components just once.

Re: If Not SPAs, What?

#152

Post by yagodragon »

bgdkbtv wrote: post #104
yagodragon wrote: post #96

Earlier quoted context omitted.

Seriously, after all these years of JavaScript,SPA,react,redux craze, we're back at PHP, css and minimal js all over again. None of those new js frameworks allow you to build custom web apps faster than Laravel or Rails. I'm really curious about what kind of side projects all these people are building with e.g. next.js alone. Is there any kind of web app that doesn't need authentication, authorization and database ac…

Regarding auth and db, the ones I've spoken with that prefer JS way of doing things like to combine a bunch of existing offerings into one, eg Auth0 for Auth, Prisma for DB and so on. The more potential points of failure, the more attractive it seems to them. When saying that Laravel/RoR gives you all that by running one simple command , I get blank stares. Hard to believe, I know.

We've come to the point that being able to run code and render html on a server is considered a new feature (aka SSR and serverless functions). I recently watched the Next.js conf and i couldn't help but giggle.

-Do you want functions?

Use our proprietary platform

-Do you want to store content?

Use cloudinary, aws

- Authentication?

Auth0,firebase

- Database?

Use FaunaDb and our super cool new query language that nobody knows and cares about.

> Congratulations. You've built your new webapp on Jamstack. Now you have to manage large bills across hundreds of 3rd party services, vendor lock-ins. Also good luck trying to reproduce all that on a development machine or organize your code.

On the other hand you can just: laravel new project-name --jet and deploy on a single linux machine or heroku and you get:

-Robust and customizable Auth, password reset, 2fa

-A serious db like PostgreSQL and an orm

-SSR by default with 0kb bundle size!

-Any css tool you need

-Easy APIs, tokens and permissions

-Truly open source.You have full control of your code and data

So yeah it's just a command but yikes, who uses PHP in 2020, right?

Re: If Not SPAs, What?

#153

Post by JMTQp8lwXL »

dsiegel2275 wrote: post #132
rajeev-k wrote: post #129

> 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

This hasn't been my experience. 10 to 15 minutes of looking at React Router's documentation was enough to get started with it. The major version bumps, however, have been a little taxing. If it takes six major releases to get the paradigm right, you should've done more research before moving onto the implementation phase.

Re: If Not SPAs, What?

#154

Post by postpawl »

pier25 wrote: post #151

The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap. OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/…

This discussion has happened a million times on HN and this is the most succinct explanation I’ve seen so far. Bravo

Re: If Not SPAs, What?

#156

Post by kumarvvr »

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/

Yup. Been using it for a very complex data app. Its awesome.

You can choose Wasm for LOB apps or on fast connections.

You can choose Server hosting for apps that have about 100,000 users at a time. Mind you, that is 100,000 users concurrently. Which should be more than enough for most apps.

There are plans to reduce bundle size and server side resources, coming in .NET 5.

As per Microsoft Benchmarks[1], it should cost about 100 USD per month (3 years, reserved instances, paid upfront) to handle 20,000 concurrent users. (This price is not including database, storage, etc). That comes to about 0.18 USD per user, for 3 years. (cost of serving app to 1 user for 3 years in total). Which seems pretty reasonable, especially if you have a decent, paid app. The cost comes down even more, if only a %age of your users are online concurrently.

On Digital Ocean, a similar machine, would cost about 40 USD a month. For 3 years, total cost for 1 users will be 0.072 USD

[1] - https://devblogs.microsoft.com/aspnet/blazor-server-in-net-c...

Re: If Not SPAs, What?

#157

Post by kumarvvr »

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?

Inherent in any framework that uses a connection to transmit diffed DOM nodes.

Re: If Not SPAs, What?

#158

Post by jolux »

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.

Admittedly I don't have a lot of experience with enterprise web development in Java but I love working with ASP.NET Core and I think it's come a long way since the mess of Web Forms and classic ASP.

Re: If Not SPAs, What?

#159

Post by jolux »

kumarvvr wrote: post #157
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?

Inherent in any framework that uses a connection to transmit diffed DOM nodes.

yeah, that's what I thought. it's certainly the achilles heel of this technique.

Re: If Not SPAs, What?

#160

Post by mst »

jlokier wrote: 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…

The basic issue was that the coroutine package was segfaulty and maintained by a man so lovely to interact with that the node.js core team eventually invented libuv (to replace his ev library) primarily so they never had to talk to him again.

Perl now has http://p3rl.org/Future::AsyncAwait which is (like any async/await system) a bit more restricted than a full coroutine but works beautifully.

If you threw a github repo up somewhere I can think of a few people who might be interested in trying to update it to more recent+reliable perl tech.

Post reply on HN