Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

141–150 of 309 posts

Re: Second-guessing the modern web (2020)

#141

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

I've been happily using MySQL for over 10 years and have never seen a reason to switch. Happy to have avoided the NoSQL craze. There's been like 1 or 2 queries where SQL has been suboptimal but nothing insurmountable :-)

Re: Second-guessing the modern web (2020)

#142
post #50

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…

Hi, I'm a Redux maintainer. Note that we have considerably changed the Redux patterns that we teach over the last couple years to make it easier for folks to learn and use Redux. We now teach using our Redux Toolkit package as the default way to write Redux logic [0], and the React-Redux hooks API [1] as the standard way to work with Redux in React components.

We recently rewrote our tutorials from scratch [2], and offer an opinionated set of guidelines on how to write Redux code effectively [3], such as "put all Redux logic for one feature in a single file", "use feature folders", and "prefer putting logic in reducers".

We also now recommend some TypeScript usage patterns [4] that simplify the amount of types you have to write.

Finally, we are about to release a new "RTK Query" data fetching layer that will be in the upcoming RTK 1.6 release [5]. It's in beta now [6], and we're just polishing the docs before it goes live.

Hopefully this will help you and anyone else who's using Redux!

[0] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[1] https://react-redux.js.org/api/hooks

[2] https://redux.js.org/tutorials/index

[3] https://redux.js.org/style-guide/style-guide

[4] https://redux.js.org/recipes/usage-with-typescript

[5] https://deploy-preview-1016--redux-starter-kit-docs.netlify....

[6] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.6.0...

Re: Second-guessing the modern web (2020)

#143
post #75
post #50

Earlier quoted context omitted.

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…

Tbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team. For the parts it doesn't match, truly global stuff or tonnes of mutation, MobX is nicer out of the box than Redux. Redux can be just as nice and in some ways more powerful, but thats only after installing and configuring X amount of middlewares, with all the type…

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 should avoid them : ) just that it's important to understand the intended use cases and technical behavior differences [2].

[0] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

[1] https://redux.js.org/recipes/usage-with-typescript

[2] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

Re: Second-guessing the modern web (2020)

#144
post #49

Earlier quoted context omitted.

Sorry, what's a "SPA" - can't seem to find it by Googling.

firefox "https://en.wikipedia.org/w/index.php?limit=500&profile=all&search=spa" At the top is the link to the Disambiguation. https://en.wikipedia.org/wiki/Spa_(disambiguation) A more specific search, e.g., "single page", will not redirect. In some ways, for discovery, Wikipedia's search engine is better than Google's. For one, it is non-commercial and does serve ads based on past surveillance of the user's activity.…

http://www.google.com/search?q=spa+web

Re: Second-guessing the modern web (2020)

#145
I always have cognitive dissonance about this kind of stuff. I read this article and “In defense of the modern web” and I feel like I agree with both of them.

I think new things don’t necessarily make older things obsolete. We have printers, for example, but it’s not like pens, pencils, and even chalk aren’t useful.

Whenever I start a new project (admittedly, these are personal projects so not the same kind of scale—but in my job where the where the scale is bigger I’ve noticed a similar sentiment), I like to think about everything I have available to me. I could make a Vue SPA, a generated static site with 11ty, a backend CRUD app with PHP (I like Fat-Free Framework), WordPress (haters gonna hate), a site with no JavaScript, a site with only vanilla JavaScript, or anything in between.

I at once feel like a wide-eyed optimist ready to plow into the future and a curmudgeonly get-off-my-lawn skeptic who’s been burned too many times.

It's a good thing I consider building websites/apps good fun or else I would be really stressed out. :-)

Re: Second-guessing the modern web (2020)

#146
post #62
post #28

Earlier quoted context omitted.

I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditional SPA, a good part of your code runs on the client, which is server costs you don't have to pay. I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. If your…

I think this is a good assumption, but it breaks down when you look at bandwidth costs. A large reason why these apps take so long to load is because of the kb of dependencies and bundles they have to download. That adds up quickly with many visitors, and there's practically no way you would be accruing the same amount of bandwidth costs with a bland PHP or direct HTML response.

You think heavy HTML responses are cheaper than one extra-heavy initial JS request?

I'd like to see some analysis on that. I'm assuming if you're building an SPA or any kind of app, many of your visitors and clicks are repeat visitors and won't have to download that bundle... probably once a day, M-Th assuming daily release schedule w/ lets-not-break-it-before-the-weekend policy.

I think all that client-side caching would outweigh the cost of the initial bloated bundle.

Re: Second-guessing the modern web (2020)

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

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years.

It's made me want to leave the industry completely and I honestly think I will after this project.

It has single handedly slaughtered and destroyed my quarter century love affair with programming.

It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy that's fluid and always changing. So you get a pile of inherently unmaintainable, unavoidably messy code that is deprecated the day you write it.

It's sheer insanity. Trying to get horizontal communication between components.

I'm slapped and told "no don't do it that way" and then I'm given half a dozen extraordinarily convoluted ways to do it instead.

They say "you aren't thinking in react". There is no thinking in react because there's a bunch of different ways to go about it and each one fights against the limitations voluntarily imposed by the framework.

Each one is a hack to get around the needless artificial barriers that exist there for no damn reason other than to make life harder.

Pass a parameter with an onclick handler. Again, I get slapped around as no that's not how it's done.

Why isn't it easier? Why is the Framework requiring me to do more work, to set up an indirection? Why am I working more with it then without it? Why does it give me less, do less, and require more from me?

It's literally the most complicated convoluted and elaborately complex way to do what should be simple and direct things. Every task gets a layer or 4 of complexity slapped on top of it.

It's like they replaced Galileo's chart with epicycles because they have to appease some invisible theory gods.

It's theory that has literally zero hard evidence as to why doing something directly is bad but doing the same thing with a bunch of weird generators callbacks and hooks is good.

In my 5 years of working with it, it's always without failure been the worst catastrophic mistake on every project, blowing through budgets and deadlines like nothing else.

Productivity is slaughtered. Otherwise 10x engineers become 1/10x. It's remarkable how much it stagnates and destroys everything.

This is pure Jim Jones cult magic stuff. It literally only exists to make people feel special and elite while doing what should be simple stuff.

I'm quitting engineering after this thing ships. I simply do not have the words for how much I despise react. It's the most despicable creation I've ever laid eyes on.

I honestly want to have absolutely nothing to do with programming now. After React it makes me physically nauseous.

Re: Second-guessing the modern web (2020)

#148

Earlier quoted context omitted.

> The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks This is not true. SSR React still returns HTML. You can set hrefs on a tags. They all work fine.

Aha, thanks. So when the author writes: > So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive. Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand…

[deleted]

Re: Second-guessing the modern web (2020)

#149

Earlier quoted context omitted.

> The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks This is not true. SSR React still returns HTML. You can set hrefs on a tags. They all work fine.

Aha, thanks. So when the author writes: > So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive. Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand…

What they mean is that, with a normal React SPA, the html content sent to the client will be little more than something like ``. After the JavaScript loads, react hooks into this div and starts filling it with the html it generates for your app. With SSR, that div will be populated with html when it’s downloaded - this is the html that was rendered by the server. When the page is first rendered it will look like your app, but it’s totally static html. The JavaScript has to load and react has to take over managing the html within that div before any of the interactive content (think: button click handlers on so on) will be functional.

Re: Second-guessing the modern web (2020)

#150
post #40

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no sm…

> Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible.

Whaaat. Async/await/promises is trivial. JS is still single-threaded so you don't have any of those annoying threading issues.

Where it gets a bit wonky is when you apply it to the UI because you have this extra state you need to worry about. After the user clicks something, but before you get the results back from your server. You have a loading or saving state to deal with. But React mostly makes that trivial too.

SPAs get hard because of all the reasons listed in that blog post. They're incredibly hard to optimize properly.

And for that reason, I don't disagree with your first sentence. If all you're doing is worrying about 1 page at a time and shipping some HTML, you're golden.

Post reply on HN