Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

Post reply on HN
Print view View original

251–260 of 309 posts

Re: Second-guessing the modern web (2020)

#251

Post by darkhorse13 »

phist_mcgee wrote: post #216
Toutouxc wrote: post #160

> unloved, unpopular, uncool things like Django, Rails, Laravel Oh they're loved all right, it's just that they're (all three) very mature, packed with features, easy to pick up and people who work with them don't have a reason to sit around and discuss the tools. I work for a smaller Rails shop and the atmosphere is just so nice there. We work on small (think $20k) projects for different niche customers, we absolute…

Good you have found your niche, and it's great that you haven't overextended yourself when it comes to delivering value to customers. I would say though that your work is a subset of web dev, and while totally valid in that area, I don't think it applies as concretely to other domains, particularly those with larger audiences, or those with needs for greater reactivity.

Sorry, but this is just plain bollocks. Some of the most popular websites run on Rails/PHP/Django, and they are not "reactive" SPAs.

Re: Second-guessing the modern web (2020)

#252

Post by hackerfromthefu »

dntrkv wrote: post #118
epistasis wrote: post #113

Earlier quoted context omitted.

Sure, there's lot of code to write, but is the end goal writing code, or making a web app that's great for users?

Not sure I get what your comment is saying, but: > making a web app that's great for users That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever trie…

Oh la ..

>> You can't build a modern web app without it being a SPA.

Lots of people can

>> I don't understand how there is even a discussion around this.

This is the difference that makes the difference

Re: Second-guessing the modern web (2020)

#253

Post by hackerfromthefu »

burlesona wrote: post #47
paxys wrote: post #18

Earlier quoted context omitted.

It is a pointless generalization. Not every React SPA is the same. Some scale, some don't. Some use server rendering, some don't. React may be a perfect fit for your app, or it may not. It's not like a "naively implemented" app using vanilla JS or server templating or any other framework will be automatically fast and scalable. Quality of input = quality of output, regardless of what abstractions you decide to use in…

I thought the original article had a lot of nuance, actually, and did a good job describing where React reasonably fits in the scheme of things. I would argue your statement that “every React app is different” is part of the problem. There are so many react apps that are essentially the same but each one is implemented with some bespoke cocktail of parts because React isn’t really a framework, and it doesn’t solve th…

Yup, and then you try to upgrade them over the years. Oh the joy. Keeps you in a job anyway. Maybe that's the real reason for react fervour!

Re: Second-guessing the modern web (2020)

#254

Post by acemarke »

girvo wrote: post #175
acemarke wrote: post #143

Earlier quoted context omitted.

Fortunately, you no longer need to "install a bunch of middleware" yourself - Redux Toolkit's `configureStore` gives you a good default setup out of the box [0], and we have TypeScript usage guidelines that infer all the needed state and dispatch types automatically [1] It's also worth noting that there are some significant difference between `useReducer+useContext` and Redux. Not saying those are bad and that you sh…

You bet there’s a big difference! In my experience, too many teams misunderstood what Redux is excellent at, and made a mess of things due to that misunderstanding. In those teams, useReducer alone gets us 80% of the way there, useContext combined with a well constructed reducer solves another 10-15% — and for most of the projects I’ve worked on across different teams with differing skill sets, often 100%. I’m glad t…

Yep, my recurring theme is "take the time to understand the use cases and tradeoffs of the tools you're looking at, and pick whatever actually solves _your_ problems".

Btw, it is actually possible to use Redux Toolkit's `createSlice` API to create reducers just for passing to `useReducer`, even if you don't have a Redux store in your app - after all, reducers are _just_ functions. I've done this several times myself for cases where I wanted a well-TS-typed reducer with some complex logic in a plain React app.

And yeah, my co-maintainer Lenz Weber is a TS genius, and has done an amazing amount of work over the last couple years to improve our TS handling in a lot of cases.

Re: Second-guessing the modern web (2020)

#255

Post by h0l0cube »

h0l0cube wrote: post #165
scrollaway wrote: post #125

Earlier quoted context omitted.

A lot of assumptions you're making about a hypothetical there.

Not really. If you have to make database queries in order to display the page, there's no way of getting around it. Even if your webserver isn't in a cluster with your API and database, while you might be sharing the load between your servers, it's still server load that needs to be accounted for. And if it is in the same cluster, probably cheaper to make those fetches from your webserver than to have multiple connec…

Whoever downvoted me want to clarify where I'm wrong on this?

Re: Second-guessing the modern web (2020)

#256

Post by scrollaway »

h0l0cube wrote: post #165
scrollaway wrote: post #125

Earlier quoted context omitted.

A lot of assumptions you're making about a hypothetical there.

Not really. If you have to make database queries in order to display the page, there's no way of getting around it. Even if your webserver isn't in a cluster with your API and database, while you might be sharing the load between your servers, it's still server load that needs to be accounted for. And if it is in the same cluster, probably cheaper to make those fetches from your webserver than to have multiple connec…

You're still making assumptions. Some stuff is harder to calculate server-side, period.

For a very simple example, I'm currently replacing a SSR feature that takes a list of items and renders a "screenshot" of them. The screenshot has to go through PDF rendering, conversion to JPG, it's insanely expensive.

I'm replacing it with a client-side generation of an SVG, and in-browser conversion to PNG. It's very clean, very fast, simple to do, cheap for the client, takes less time than it would to even download the original.

(Keyword: Currently. This isn't a hypothetical scenario, this is a real-world instance of replacing SSR with CSR)

Re: Second-guessing the modern web (2020)

#257

Post by hackerfromthefu »

danappelxx wrote: post #25
frosted-flakes wrote: post #19

Earlier quoted context omitted.

Which ways are those?

React forces you to write code a certain way. jQuery does not force you to write your code a certain way. In my experience, that’s the single biggest difference between a library and a framework.

If only there was just one way to write react code!

Re: Second-guessing the modern web (2020)

#258

Post by kristopolous »

jkaplan wrote: post #64

I agree with a lot of these points, but differ slightly in two regards: 1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns. 2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product land…

oh sorry, one other thing, jkaplan, are you THE Jerry Kaplan of Go? The writer of the fantastic 1994 book "Startup" that I have on my shelf?

Re: Second-guessing the modern web (2020)

#259

Post by dntrkv »

hackerfromthefu wrote: post #252
dntrkv wrote: post #118

Earlier quoted context omitted.

Not sure I get what your comment is saying, but: > making a web app that's great for users That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever trie…

Oh la .. >> You can't build a modern web app without it being a SPA. Lots of people can >> I don't understand how there is even a discussion around this. This is the difference that makes the difference

> lots of people can

Let’s see some links.

Re: Second-guessing the modern web (2020)

#260

Post by dntrkv »

timw4mail wrote: post #242
dntrkv wrote: post #122

Earlier quoted context omitted.

No. That's not it at all. If your page takes 3 seconds to show anything at all, your bounce rate will be stupid high. If your page loads nearly instantaneously with placeholders, and then the content loads in over the span of 4 seconds. Your bounce rate will be significantly better. Even though your page loads slower, it will be perceived as faster resulting in less users navigating away before your page starts rende…

I've never had the second scenario feel faster.

Cool, well the metrics tell a different story.
Post reply on HN