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

311–320 of 456 posts

Re: If Not SPAs, What?

#311

Post by ccmcarey »

TeMPOraL wrote: post #297
buzzerbetrayed wrote: post #219

Earlier quoted context omitted.

SPAs are like CGI.. you only notice it when it is bad. I can assure you, you use many SPAs that are not slow and clunky, you just don't realize they are SPAs

Name three. Because like other commenters that chimed in, I can notice most SPAs, and all SPAs I've used had annoying performance problems. By problems I don't mean a sudden request that takes half a second, but that every UI interaction feels subtly slow. I don't know where people get these performance targets of "below 100ms and users won't notice". I notice. I notice if UI responses take longer than two-three anim…

Any of the google office applications, fastmail, both are fantastic SPAs in my opinion.

Re: If Not SPAs, What?

#312

Post by davnicwil »

The article mentions using frameworks with React to get features like full stack data loading. If you're interested in doing this without going all-in on a framework, you should check out React Frontload [0]

It's still opinionated, but only on the data loading part! It's just a small library that will slot into any stack. I'm the author.

[0] https://github.com/davnicwil/react-frontload

Re: If Not SPAs, What?

#313

Post by brainbag »

tomhallett wrote: post #90

My goal is to write a demo app with: - Rails - StimilusReflex - view_component ( https://github.com/github/view_component ) - Web components With these 4, it divides responsibilities very cleanly/pragmatically: Rails is your app framework. view_component is how you divide your view into an organized/flexible structure. StimilusReflex is the "reflexive" bridge between the 2. What happens when you need just a sprinkle…

I've been thinking about this setup a lot but never have time to try it. Is there somewhere I can follow to be notified when you accomplish this?

Re: If Not SPAs, What?

#314

Post by esistgut »

stevebmark wrote: post #11

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

I am currently working on projects with Django (jinja2), Laravel (blade), Node (ejs) and Next. I can't possibly understand how so many people in this thread are preferring server rendering frameworks. As soon as you have a non hello world application (= complex state shared across multiple components / page) a SPA application is so much easier and productive. And Next brings this experience back to public facing frontends because it supports prerendering along other things.

Re: If Not SPAs, What?

#315

Post by austincheney »

sumedh wrote: post #289
austincheney wrote: post #277

Earlier quoted context omitted.

Not at all. It would only be a bold statement if it weren't so immediately validated in practice. A developer can write code or they can't.

> A developer can write code or they can't. Uhh that is not how it works. I can write code but if you tell me go and write in assembly or C, I cant because I think its outside my circle of competence. Maybe you find SPA's easy others dont.

I have been writing software for 20 years. It's exactly how it works. You can, after a necessary onboarding period, accomplish the task you were hired to accomplish or you can't.

Re: If Not SPAs, What?

#316

Post by lmm »

yoz-y wrote: post #292
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…

> You certainly wouldn’t use a language like JS, I disagree with this. You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. > you certainly would want to provide visual design tools as far as possible, I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of change…

> You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts.

When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it still has a lot of JavaScript baggage you'd want to strip out.

> I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future.

All the big UI libraries end up offering some kind of markup/constraint-based interface - which is ultimately data rather than code. And for editing that, a visual form designer makes a lot of sense. I like Qt's approach - you visually edit a markup form that's compiled into a class you can subclass, so you don't have to deal with the problems of code generation, and the markup is relatively version-control-friendly.

> Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP.

I'm not the person you replied to, but thrift/gRPC are a lot nicer to work with than REST APIs. Standardised protocol definitions that let you understand what kind of changes are or aren't forward/backward compatible, and no need to write a bunch of boilerplate by hand.

> I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.

It's the same story as "no-code" tools: IT departments won't let anyone install an application runtime, but they're happy to install a "document browser" and let it run arbitrary code. It's understandable, but depressing.

Re: If Not SPAs, What?

#317

Post by ratww »

bartread wrote: post #303
ratww wrote: post #290

Earlier quoted context omitted.

My impression is that the design of Java the language, plus its runtime, are appreciated even by the harshest critics. However the culture around complex frameworks and over-engineering is what most people really dislike about it. IMO pretty much all the advantages touted by Java proponents (such as: good language design, easy of use by heterogenous teams, speed, etc) are correct, but are negated by a large part of t…

> However the culture around complex frameworks and over-engineering is what most people really dislike about it. I think this is it. I remember back in the day being absolutely floored when I started learning J2EE by the, it seemed, unnecessary complexity (for most use cases) of EJB. It was incredibly offputting: if you were starting a project from scratch it felt like you had to do a ridiculous amount of work just…

That's true. I also used to be a .NET guy in the past, but I started doing more games (and then frontend) when the movement from Rails-ish to Java-ish MVC started.

The thing about the multiple "layers" that don't do anything really bothers me too, because they are a misconception of how those complex architectures (Clean/Hexagonal/Onion) really work...

Instead of having mandatory layers, those should be pluggable. Just having a layer calling the next one is unnecessary, and some people implement it by having the next layer as a transitive dependency, which makes testing harder and has zero benefits!

Re: If Not SPAs, What?

#318

Post by arcturus17 »

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.

Re: If Not SPAs, What?

#319

Post by brainbag »

aledalgrande wrote: post #74
swanson wrote: post #50

I've had great success with the Turbolinks + Stimulus approach. There are a couple of common patterns that you'll reach for, namely, lazy loading content (basically a with a URL attribute that you have Stimulus load via AJAX) and really leaning into Rails remote-link / server javascript responses for modals and little page updates. It's so great to still be super productive and be able to crank out several pages of a…

curious how you would implement refresh of a single row in a table after a job has completed? have enjoyed this combination too, but I feel like you'd have to subscribe to multiple ActionCable channels to do this?

StimulusReflex can do something like this quite easily. It re-renders the entire page (suggesting that you do a lot of fragment caching so this is fast) and then diffs it on client side with morphdom (IRC). I believe you can do partial rendering now, but I haven't tried it.

Re: If Not SPAs, What?

#320

Post by TeMPOraL »

ccmcarey wrote: post #311
TeMPOraL wrote: post #297

Earlier quoted context omitted.

Name three. Because like other commenters that chimed in, I can notice most SPAs, and all SPAs I've used had annoying performance problems. By problems I don't mean a sudden request that takes half a second, but that every UI interaction feels subtly slow. I don't know where people get these performance targets of "below 100ms and users won't notice". I notice. I notice if UI responses take longer than two-three anim…

Any of the google office applications, fastmail, both are fantastic SPAs in my opinion.

Fastmail is laggy in places, but mostly OK. But I'm surprised at you choosing Google Office as an example. Google's office suite is a poster child of slow, clunky SPAs.
Post reply on HN