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

231–240 of 456 posts

Re: If Not SPAs, What?

#231

Post by laichzeit0 »

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…

I also wonder how much of the SPA trend by mega corps was about shifting compute “client side” to save money on infrastructure. It’s kinda like modern data warehouses where storage/compute is now so cheap you do ELT and not ETL anymore. I probably wouldn’t do an SPA today unless I really had to.

Re: If Not SPAs, What?

#232

Post by place1 »

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…

For what it's worth GRPC-Web is a pretty nice solution here.

My team generates backend stubs from our GRPC spec which allows us to jump right to implementing our business logic.

Frontend projects make use of the GRPC-Web client codegen to make calling the API simple and type safe (we use typescript).

We mostly use all the official GRPC tooling for this. We write backends in golang and dotnet core so GRPC-Web is supported quite well out of the box.

I wrote a slightly modified Typescript codegenerator to make client code simpler as well: https://github.com/Place1/protoc-gen-grpc-ts-web

Re: If Not SPAs, What?

#233

Post by Hasu »

Nextgrid wrote: post #187
MattGaiser wrote: post #121

Earlier quoted context omitted.

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.

> nobody knows whether something will become the next Google Docs How many times has it actually happened that some scrappy startup has 1) became the next big thing and 2) not being at the edge of over-engineering actually killed it or significantly impacted its revenue? This just feels like wishful thinking. Also keep in mind that even if you were on track to become the next Google Docs, this means your current prod…

I'm not sure that using React or another JS framework counts as 'being at the edge of over-engineering'.

I agree with the rest of your point - the value of the product to end-users has little to no correlation with the underlying technology choices, which is a pretty controversial statement, but one that I think is true. A customer doesn't care if you built it in React, in one Perl file, or if you're sacrificing goats to retain the minimum requisite levels of dark magic to keep the system running. If it solves their problem they'll keep giving you money for goats.

Re: If Not SPAs, What?

#234

Post by tofuahdude »

brendanmc6 wrote: post #222
muzani wrote: post #197

Earlier quoted context omitted.

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

I hear this so often, so as an exclusively js/ts dev I have to ask... what about this is “done poorly”? ``` try { return await fetch(url); } catch (e) { handleError(e) } ``` Because that (metaphorically speaking) is 90% of what I write. Throw in the occasional closure, `map()` or `reduce()` My day to day headaches are never from TS, and always from unpredictable DOM api/layout/style behavior. I guess I just don’t hav…

Fyi return await is redundant and is just creating one additional callback you didn't need (b/c you will have to call this function with an await anyways)

Re: If Not SPAs, What?

#235

Post by sdepablos »

Maybe the main issue here is that while SPAs make life so much better - proper testing, immutability, one way data bindings, speed of development... - for frontenders, they make it worse for absolutely everyone else: backenders that were able to hack a passable frontend or modify a proper one; final users that deal with bigger and slower webpages; devices struggling to render websites; backends that now need way more CPU to do SRR then they ever needed with traditional websites; beginners that were able to look at the HTML & CSS of a page...

Re: If Not SPAs, What?

#236

Post by tartoran »

will_pseudonym wrote: post #215
mrh0057 wrote: post #212

Earlier quoted context omitted.

Redux is not idiomatic JavaScript though. It’s trying to make JavaScript immutable and have adt which it doesn’t. If you use elm, reasonml, rescript, etc this pattern is a lot easier to implement than with JavaScript.

I wasn't readily familiar with the acronym ADT. It's "Algebraic Data Types" for anyone else in the same boat. https://en.wikipedia.org/wiki/Algebraic_data_type

In CS it also refers to Abstract Data Types

Re: If Not SPAs, What?

#237

Post by hnick »

erklik wrote: post #224
hnick wrote: post #172

It's interesting to me that in video games we talk less about frameworks than we do engines. Doing a few tutorials, I was shocked at how little code I had to write these days with something like Unity or Godot. Breakout indie success stories are often lead by artistic types, since it seems harder to teach a typical programmer to draw than to teach an artist enough code to get by. And I think the scene is richer for i…

A case of maintainability? Most games (although its changing these days with loot boxes, and micro-transactions) don't really change ultimately in large ways after the initial development. A website, often these days, is an ever evolving beast forever changing and adding features to it is (apparently) imperative to ensure that the gravy train keeps flowing. Its one of the reasons why I think there's an increased focu…

> A case of maintainability?

A good point. I hadn't considered it. Though games are more frequently masquerading as services now too.

Re: If Not SPAs, What?

#238

Post by cercatrova »

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.

The problem is then you'd have to use PHP or Ruby. Much as people say they've improved, they're not better than TypeScript. I wish someone made something like Laravel for TS. Sometimes I look at Laravel and think, sure it's great that they did all of that and are even making a bunch of money, but why did it have to be PHP of all languages?

Re: If Not SPAs, What?

#239

Post by cercatrova »

WillPostForFood wrote: post #191
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.

Use the basic HTML version of Gmail, you can set it to be default.

Re: If Not SPAs, What?

#240

Post by rawoke083600 »

switz wrote: post #134
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…

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

I definitely agree you, F.E Tools has gotten a lot more mature and we have a lot further to go as well.

I'm primarily a backend developer and I think in general backend developers makes for "poor fronted devs". I'm talking about those "occasional" times the backend-dev needs to do some f.e dev work. Just because they don't know the tech as well, best practises and spend as much time with it as a dedicated F.E Dev. jQuery code written by the "occasional front-end dev" is kinda horrific in many cases.

Now please internet hear me. I'm not saying you can't write bad code in a JS-Framework. I'm saying it's usually less often and less bad - especially for non-dedicated f.e devs

Like crossing a street, just looking left and right won't guarantee you to be safe in your crossing, but it damn near makes it less probable.

If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework.

*Svelte is always good start very small and bare bones.

Post reply on HN