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

111–120 of 456 posts

Re: If Not SPAs, What?

#111

Post by rglover »

edouard-harris wrote: post #88
dfabulich wrote: post #21

IMO, TurboLinks + service workers are the way to go. Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.) The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support.…

Is this the same model meteor.js uses? I seem to recall their system maintains a mini-database on the client side and syncs it with the main server through a pub-sub model.

Not quite. It's just a client-side cache of query results matching a MongoDB query on the server (pub/sub).

Re: If Not SPAs, What?

#112

Post by AlchemistCamp »

sixhobbits wrote: post #41
xiaomai wrote: post #8

I think Phoenix Live View is maybe the most compelling story around this ( https://github.com/phoenixframework/phoenix_live_view ). I'm moving a side-project from React/SPA to Phoenix live view and it's kind of amazing to get the dev ergonomics of a server-rendered page with the UX benefits of a SPA. This course is a pretty great intro: https://pragmaticstudio.com/phoenix-liveview

I started this course and the animations/presentation are amazing. some really clear explanations. But the fake cute-sy dialogue and the extra fluff that says how wonderful and amazing and great and FUN liveview is means I didn't get past the first video

I liked their Tetris videos, which I watched the first several of.

That said, if you want a different approach then check out my series at https://alchemist.camp/tagged/Reactor

I covered the whole process of building the site for my podcast https://reactor.am in the series.

Note that LiveView still isn't at v1.0 and breaking updates have been common. You'll have a much better with my LV tutorial or anyone else's if you use the exact same library versions we do and upgrade at the same point the tutorial does.

Re: If Not SPAs, What?

#113

Post by jononomo »

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…

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.

Re: If Not SPAs, What?

#114

Post by AlchemistCamp »

PopeDotNinja wrote: post #89
xiaomai wrote: post #8

I think Phoenix Live View is maybe the most compelling story around this ( https://github.com/phoenixframework/phoenix_live_view ). I'm moving a side-project from React/SPA to Phoenix live view and it's kind of amazing to get the dev ergonomics of a server-rendered page with the UX benefits of a SPA. This course is a pretty great intro: https://pragmaticstudio.com/phoenix-liveview

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.

Re: If Not SPAs, What?

#116

Post by Nextgrid »

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

> Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error.

This is a major problem with our industry. Unfortunately, the people with the power to curb this trend have their paycheck depend on it continuing.

As a company, you are incentivised to have a large tech team to appear credible and raise funding, so you hire a CTO and maybe some engineering managers. Their career in turn benefits from managing large amounts of people and solving complex technical problems (even if self-inflicted), so they’ll hire 10x the amount of engineers the task at hands truly requires, organise them in separate teams and build an engineering playground that guarantees their employment and gives them talking points (for conferences or the seemingly-mandatory engineering blog or in interviews for their next role) about how they solve complex problems (self-inflicted, as a side-effect of an extremely complex stack with lots of moving parts). Developers themselves need to constantly keep up to date, so they won’t usually push back on having to use the latest frontend framework, and even if they do, that decision is out of their hands and they’ll just get replaced or not hired to begin with.

In the end, AWS and the cloud providers are laughing all the way to the bank to collect their (already generous) profits, now even more inflated by having their clients use 10x the amount of compute power that the business problem would normally require.

Maybe the issue is the seemingly-infinite amounts of money being invested into tech companies of dubious value, and the solution would be to get back to Earth as to have some financial pressure coming from up top that incentivises using the simplest solution to the problem at hand?

Re: If Not SPAs, What?

#117

Post by martinmunk »

edouard-harris wrote: post #88
dfabulich wrote: post #21

IMO, TurboLinks + service workers are the way to go. Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.) The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support.…

Is this the same model meteor.js uses? I seem to recall their system maintains a mini-database on the client side and syncs it with the main server through a pub-sub model.

Yes. At least it can use service workers. Meteor uses MongoDB on the backend, and minimongo client side. Those two are synced over their DDP protocol IIRC.

I miss meteor. It was such a great framework and promise. Not for big sites really, but for mock-ups, internal sites ect. A while ago I started to look at it again. The drivers behind the project was essentially asking for input on what was preventing people from using the framework. The current state of the project is/was OK, except for the fact that it was hold down by all the guides and howtos referring to previous versions. It was not well documented what current best practices to follow, what to use as replacements for deprecated dependencies ect.

Re: If Not SPAs, What?

#118

Post by throw_m239339 »

knubie wrote: post #53
treis wrote: post #40

Earlier quoted context omitted.

Yes, like we had with WebSQL until it was deprecated. Basically a SQLite db per site.

I think the idea is that IndexedDB acts as a more lower level store that you can build higher level abstractions over, for example PouchDB.

> I think the idea is that IndexedDB acts as a more lower level store that you can build higher level abstractions over, for example PouchDB.

AFAIK, the problem was that vendors couldn't agree on which version of SQL/Sqlite they would have to support and nobody wanted to write a SQL spec. MS wanted to use SQL Compact, but it's mainly Mozilla's fault if the spec was dropped. The same Mozilla that dragged its feet for years when it comes to implementing some aspects of web components...

But it was a terrible decision IMHO because indexedDB doesn't do what a relational database does and it considerably hurt the development of complex mobile web apps, and now Safari on IOS AFAIK removed support for WebSQL. WebSQL was a fantastic tool for web apps that could be entirely cached on a mobile device (SQL can do a lot).

There is no realistic replacement. Even using Sqlite compiled to WASM has a lot of issues (mainly performances and data persistence).

To this day I don't know a single efficient and performance RDBMS equivalent to Sqlite built on top of IndexedDB. Mozilla certainly didn't build one.

Re: If Not SPAs, What?

#119

Post by IggleSniggle »

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…

To be fair, they only said writing an API should be easier than writing a server-rendered HTML form (1:1).

Re: If Not SPAs, What?

#120

Post by bgdkbtv »

Scarbutt wrote: post #109
bgdkbtv wrote: post #104

Earlier quoted context omitted.

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.

Rails doesn't give you auth* though.

Ah, sorry. I don't have much experience with RoR. Laravel, mostly, and Laravel auth is one command away. I assume RoR won't be too far away from that, too.
Post reply on HN