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

331–340 of 456 posts

Re: If Not SPAs, What?

#331

Post by brainbag »

obiefernandez wrote: post #196

This recent hype piece I wrote about ReactiveRails is at around 30k views and counting. In the right hands (experienced full-stack dev like yours truly) the productivity gains are off the charts. https://medium.com/@obie/react-is-dead-long-live-reactive-ra...

This stack is very appealing though I'm not sure it's quite fully ready for primary use. Has StimulusReflex-CableReady figured out pushing new data to the client outside of the request cycle? Last I looked there was no way to trigger a client page update from a background job for example.

Re: If Not SPAs, What?

#332

Post by mercer »

arcturus17 wrote: post #318
randomsearch wrote: post #261

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…

> Experienced programmers know that JS is an awful language BS blanket statement. Some - many, maybe - programmers that in all likelihood multiply your experience and talent by orders of magnitude believe it's a great language. Not everyone working with JS is doing so with a gun to their heads.

I don't know any polyglot programmers who would consider javascript better than at least one of the other languages they use, and would ditch js for those if they had the option.

TypesScript, maybe.

Re: If Not SPAs, What?

#333

Post by black3r »

cutler wrote: post #122
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…

Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kub…

Kubernetes is overkill for most applications that's true, but Docker is awesome because it solves almost all of the "it works on my machine, doesn't work in prod" and "it worked yesterday, doesn't work today" issues and isn't that hard to adopt.

Re: If Not SPAs, What?

#334

Post by mercer »

dugmartin wrote: post #92
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've been playing with LiveView myself for personal projects and it is very nice. One interesting thing is that it makes you consider memory issues again since all your rendered data structures are held in memory in the LiveView process unless they are explicitly cleared after the render with "temporary_assigns". For apps that would have to hold and transfer a lot of data up and down the channel I've ended up using a…

I'd say that's the main (potential) 'problem' with LiveView, alongside latency issues.

In practice, I've usually found that the advantages outweigh the disadvantages when it comes to the former. Beefing up my servers seems like a worthwhile trade-off.

When it comes to latency, or related issues, I find that I'm still so much better off using LV as a basis and 'dropping down' into plain JS or (p)react when I need it.

We recently delivered a project that involved a whole bunch of stuff that LV was a perfect solution for, but also a core bit of functionality that required various kinds of animations. We ended up using LV wherever we could, and piggy-backed on the LV channel (websockets) to handle synchronizing the animation stuff. The actual code to animate things was just plain old JS. Worked like a charm!

Re: If Not SPAs, What?

#335

Post by twic »

grandinj wrote: post #280
rytill wrote: post #278

Earlier quoted context omitted.

For me, Java’s ties with Oracle and the nightmare stories about complicated `MetaAbstractBaseClassFactoryClassFactory` are why I seek alternatives, or would be dismissive.

Just noting that the abstraction stuff is mostly a consequence of the CORBA-derived, over-engineered "Enterprise Java" space, and provided you stay out of that tar-pit, and choose your libraries/dependencies wisely, Java is really nice to work with. Even if you need to implement some kind of "Enterprise Java" app, you can do so with much better libraries and tools than back then, that do not suffer from the excessive…

Hey you leave CORBA out of this!

My first programming job was a pilot study for porting a platform from old and busted CORBA to the new hotness, J2EE. It was embarrassing how much worse than CORBA J2EE was.

Re: If Not SPAs, What?

#336

Post by nickjj »

mercer wrote: post #328
nickjj wrote: post #323

Earlier quoted context omitted.

It's still not a silver bullet. There's lots of things in a LV driven app where you're still wondering what front-end library to use with it. Typically you wouldn't use LV to handle: Menu dropdowns, tooltips, popovers, modals (in some cases), tabs (when you don't want to load the content from the server) or things that change the client side state of something but don't adjust server state. That could be things like…

> It's still not a silver bullet. There's lots of things in a LV driven app where you're still wondering what front-end library to use with it. > Typically you wouldn't use LV to handle: > Menu drop dropdowns, tooltips, popovers, modals (in some cases), tabs (when you don't want to load the content from the server) or things that change the client side state of something but don't adjust server state. My experience i…

> My experience is that LiveView is fine for all but the last use case.

I wouldn't want to impose a 50-500ms+ delay on someone to show a menu drop down or a tooltip or most of the other things listed out.

With LV everything involves a server round trip. That's great for when you need to make a round trip no matter what (which is often the case, such as updating your database based on a user interaction), but it creates for very unnaturally sluggish feeling UIs when you use LV for things that you expect to be instant.

Even a 100ms delay on a menu feels off and with a good internet connection if you have a server in NY, you'll get 80-100ms ping times to the west coast of the US or the west coast of Europe.

LV feels amazing on localhost but the internet is global. I still think it's worth minimizing round trips to the server when you can, not because Phoenix and LV can't handle it but because I want my users to have a good experience using the sites I develop.

Re: If Not SPAs, What?

#337

Post by adamnew123456 »

glaucon wrote: post #305
randomsearch wrote: post #261

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…

What is a "blub issue". I tried a slang dictionary but couldn't find anything. Thanks.

https://wiki.c2.com/?BlubParadox

The basic idea being that you know a tool that's obviously superior to a lot of alternatives, but you're blind to how different alternatives are superior to it because you can't grok the power beyond their initial "weirdness".

Re: If Not SPAs, What?

#338

Post by fendy3002 »

MattGaiser wrote: post #121
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…

The problem that nobody knows whether something will become the next Google Docs. Transitioning to an SPA from something like jQuery is basically a complete rewrite. To be willing to not use an SPA, you need to be willing to exclude certain options from day 1. Find me a product manager willing to do that.

Another view of this problem, evolving a SPA of CRUD app into Google Docs may also be a complete rewrite.

IMO when the time comes and your product is used well, you may be ready financially and technically to do a complete rewrite. Otherwise maybe the current functioning application is better if the rewrite isn't justified.

Re: If Not SPAs, What?

#339

Post by black3r »

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…

separation of concerns, easier testability, easier mocking..., the thing is especially in more complex applications the code that generates/validates the data and the code that displays them are usually written by two different people.

nowadays once the json schema design is settled, they can work in parallel, each of them can test their parts without needing the other and the merges can be simpler, because the parts do work more or less stand-alone.

Re: If Not SPAs, What?

#340

Post by mercer »

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…

My experience with LiveView has been similar. I can highly recommend looking into Tailwind (and Tailwind UI). For me, it solved some of the pain of still having to deal with CSS and various preprocessors for it.

I can now create entire working apps using just Elixir code and the utility-style Tailwind classes within my server-side templates. I still need to write some js and css, but where LiveView reduced the need for custom js to a minimum, Tailwind did the same for css.

Post reply on HN