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

191–200 of 456 posts

Re: If Not SPAs, What?

#191

Post by WillPostForFood »

zmmmmm wrote: 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

Yes, but you often pay a huge penalty on the first page load, which for many use cases is the most important. I'd be so happy with a turbolinks version of GMail.

Re: If Not SPAs, What?

#192

Post by catlifeonmars »

Nextgrid wrote: post #178
switz wrote: post #134

Earlier quoted context omitted.

> 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 l…

> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with…

I hear you. I find myself needing to reinvent the wheel far too often to traverse the boundary between the client and server. I also feel that it shouldn’t be this hard. Apollo client and relay solve this problem for GraphQL APIs (quite nicely IMO). What’s missing is an Apollo client for non-GraphQL APIs.

Re: If Not SPAs, What?

#193

Post by irrational »

I have a theory. In the old days web development was looked down upon by "real" programmers. But then the WWW really took off and people started moving over from the C/Java world into the world of JavaScript. These are the people that insanely complicated web development when they tried to make it as complicated as the development world they came out of.

Re: If Not SPAs, What?

#194

Post by CameronNemo »

irrational wrote: post #193

I have a theory. In the old days web development was looked down upon by "real" programmers. But then the WWW really took off and people started moving over from the C/Java world into the world of JavaScript. These are the people that insanely complicated web development when they tried to make it as complicated as the development world they came out of.

Do you have evidence?

Vue and Svelte, IIRC, were authored by designers. Not C or Java programmers. Perhaps React has a different history.

Re: If Not SPAs, What?

#195

Post by ChicagoDave »

throw_m239339 wrote: post #73
ChicagoDave wrote: post #64

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.

I'm definitely not a mindless CTO. ;)

Micro front-ends is the concept of breaking apart a front-end monolith. SPA's are usually built in one framework like Angular or React. Over time, this can get very convoluted and turn into a bad monolith (there are good ones).

The second part is that instead of building screens, you design features (like invoices or customers or catalog) and develop the set of views that encapsulate the targeted domain. This is all built in a separate project with a well-defined set of meta data. You deploy the feature-set into your integrated environment and the managing app is constantly on the lookout for new features-sets.

Then in some admin portion of your umbrella app, you provide access to API's to other feature-sets, and to users.

One of the key elements is to keep front-end dependencies separate. So the manager app might be Angular 9, the customer feature-set might be in Angular 10 with its own dependencies. Nothing is shared between the manager app and each feature-set and nothing is shared between feature-sets.

This provides a front-end that is malleable and reduces dependency creep.

This can also benefit from Domain-Driven Design, where you've segregated your domains and their API's, Events, and Data Storage.

So you should be able to "publish" a feature-set without any dependency on a central database, API mesh, or Event manager.

The key is to define your boundaries well and that is no small thing.

Re: If Not SPAs, What?

#197

Post by muzani »

irrational wrote: post #193

I have a theory. In the old days web development was looked down upon by "real" programmers. But then the WWW really took off and people started moving over from the C/Java world into the world of JavaScript. These are the people that insanely complicated web development when they tried to make it as complicated as the development world they came out of.

JS is quite a hacky language. Trying to turn it into Java neuters some of the benefits of being hacky (I'm looking at you, Typescript).

But at some point, it's neither a hacky Lisp like language, nor is it stable like Java or C++. It's just a middle ground that does these things poorly.

It would be nice to have a new programming language from scratch built to handle all the async/reactive mess. But until then JS is our best bet.

Re: If Not SPAs, What?

#198

Post by dchuk »

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…

If you’re going to use view components, maybe check this out: https://github.com/unabridged/motion

Re: If Not SPAs, What?

#200

Post by bgdkbtv »

yagodragon wrote: post #152
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.

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 nobo…

Exactly! FaunaDB was the recent topic of discussion and I was like oh here we go again...

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

Lol yeah, but PHP 8 is looking really nice

Post reply on HN