Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

301–309 of 309 posts

Re: Second-guessing the modern web (2020)

#301

Earlier quoted context omitted.

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it. But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on…

Here's things that are super simple to do with Javascript but extraordinarily difficult in react: * a function your code can access * data your code can access * a dom node you can access The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show. I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bul…

Here's another example. Say in javascript I want to navigate to a page 'login', here's a way to do it.

    window.location = 'login';
And there I go!

In react, well it really depends on what version. If I'm doing pre-hook (pre 16.18 or so) classes, first I need to make sure my constructor brings in props that I call a super on.

Huh?

No no stay with me. Then I have a this.props.history object and I push a new entry on to the stack like so

this.props.history.push('login');

Remember to make sure you use the fat-arrow to pass the this reference downward and that you export your class using withRouter. Effectively here's the replacement code:

    import React from 'react';
    import {withRouter} from 'react-router';
    Class A extends React.Component {
      constructor(props) {
       super(props);  
      }  

      fn() {
       this.props.history.push('login');
      }
    }

    export default withRouter(A);
And even then you may still have to "debug" this because it may "break" for inexplicable reasons. Because "In order to make use of history in the App component use it with withRouter. You need to make use of withRouter only when your component is not receiving the Router props,

This may happen in cases when your component is a nested child of a component rendered by the Router or you haven't passed the Router props to it or when the component is not linked to the Router at all and is rendered as a separate component from the Routes."

Again, we are replacing:

    window.location = 'login';
That is our only goal here

How is this easier then the first one? It isn't.

What problem has been solved? None.

Does it take less time? No.

Is this less typing? Less code? No.

Less complexity? No.

Are difficult things less difficult? No.

Fragile things more robust? No.

No none of this. It runs away from more reusable, self-contained, portable code as fast as possible. It gets in a rocket car and fires up the engines to go Mach 1 in the wrong direction. It's a giant tangled spaghetti dish of the worst anti-patterns in software engineering as a requirement for it to work.

Re: Second-guessing the modern web (2020)

#302

Earlier quoted context omitted.

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it. But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on…

Glad to hear that RTK is working well for you! Out of curiosity, what sort of "tinkering" did you find yourself doing, and what sort of patterns did you end up with?

High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally).

If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers, since they're in-lined. I can't remember if we ended up popping the reducers out into their own functions so they could be next to the createAsyncThunk call, or if that created too much of a typing headache and we just dealt with having async action creators declared at the top. (We also tried just using createReducer directly, but iirc the typing was just extra work compared with createSlice.)

**

Only partially-related to RTK, but the other thing we had to tinker with a bunch was performance. RTKs default use of immer helped a lot, and I believe we also ended up using createSelector (or perhaps the Reselect API directly) in a few places. We also had to learn to make extensive use React.memo and React.PureComponent. Redux dev tools were incredibly helpful for figuring all of this out.

*

Anyway, hope that's useful/interesting! RTK made a big impact in my day-to-day React/Redux development, from "ugh so much boilerplate I feel stuck" to "I can make changes reasonably quickly." Hope to see it continue to improve!

Re: Second-guessing the modern web (2020)

#303

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…

Yes there is a framework gravity. More directly it is Invented Here Syndrome: https://en.m.wikipedia.org/wiki/Invented_here Due to missing leadership and absent mentorship many developers are hoping tools provide the guidance they need.

> Due to missing leadership and absent mentorship many developers are hoping tools provide the guidance they need.

A non-trivial number of technical solutions turn out to be half-measures for unsolved social problems.

Re: Second-guessing the modern web (2020)

#304

Earlier quoted context omitted.

Glad to hear that RTK is working well for you! Out of curiosity, what sort of "tinkering" did you find yourself doing, and what sort of patterns did you end up with?

High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally). If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers…

You should be able to write thunks in the same file as `createSlice`, usually in front of the `createSlice` call, and then use the `extraReducers` "builder callback" syntax inside the slice to handle the various actions dispatched by the thunk. See the example here:

- https://redux-toolkit.js.org/usage/usage-with-typescript#typ...

And yeah, `createSelector` _is_ the Reselect API, just re-exported.

You might want to also take a look at our upcoming "RTK Query" API that will be in Redux Toolkit 1.6, which should be out in the next couple days. It's a data fetching and caching layer built specifically for Redux usage. The preview docs are here:

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

Re: Second-guessing the modern web (2020)

#305

Earlier quoted context omitted.

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it. But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on…

Here's things that are super simple to do with Javascript but extraordinarily difficult in react: * a function your code can access * data your code can access * a dom node you can access The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show. I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bul…

Poor child. Wait until you have to build a sufficiently complex web app. Global variables are never the answer

Re: Second-guessing the modern web (2020)

#306

Earlier quoted context omitted.

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it. But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on…

Here's things that are super simple to do with Javascript but extraordinarily difficult in react: * a function your code can access * data your code can access * a dom node you can access The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show. I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bul…

Amen! Have been waiting for a react replacement for ages. Hate using it for all these same reasons. Use preact, but mostly same issues.

The fact that they change the seemingly every few months, and have the entire framework scattered around 3-4 different libraries that are always changing is annoying enough.

Oh you want to set the class of the html element? We're gonna rename that to className cause it's easier to read and and we can.

Functional components and hooks become a ridiculous mess too, in any more than basic scenario.

Re: Second-guessing the modern web (2020)

#307

This is the money quote for me: > Frameworks should lure people into the pit of success, where following the normal rules and using normal techniques is the winning approach. > I don’t think that React, in this context, really is that pit of success. A naïvely implemented React SPA isn’t stable, or efficient, and it doesn’t naturally scale to significant complexity.

I would say the popular server-focused frameworks that came before suffered from complementing problems which also did not lead to a pit of success.

Namely view code (HTML/CSS/JS) was harder to compose in a scalable fashion, Rails'/Django's template composition feels vastly inferior to proper componentization. Namely limited type checking, globals sharing, ... These things do make it harder to refactor and get rid of unused code, which also has real impact on users.

Another biggie was that there is no great gradual path from server-code to client-code, with potentially additional data. Now React SSR does make you work more for the server use case, in that you tend to write code which should also work on the client-side (which might change with React Server Components) but at least you don't have to face lots of decisions when expanding the interactivity of your app.

All that said, I also agree with the blog that there is still lots of refinements to be done on the React side of the world, I just view the world we came from as far less rosy.

Re: Second-guessing the modern web (2020)

#308

Earlier quoted context omitted.

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it. But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on…

Here's things that are super simple to do with Javascript but extraordinarily difficult in react: * a function your code can access * data your code can access * a dom node you can access The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show. I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bul…

For future readers, a flagged dead sibling comment said this

> Poor child. Wait until you have to build a sufficiently complex web app. Global variables are never the answer

"never the answer" is a Fundamentalist Orthodoxy.

Look at those words, "fundamentalist" and "orthodoxy".

When they are the answer and are needed then instead of a basic global thing some bizarre fundamentalist mind palaces get built. There's say "a singleton object that expose shared properties through a getter/setter pattern" or some other word salad to avoid using the word "global" and avoid making the code look like a global.

So weird rules get piled on, maybe some ornate calling convention.

These people dress up a global and disguise it in a sufficiently large enough costume so their fundamentalism doesn't get offended.

It's simply blind dogmatism and utterly indistinguishable from any other cult-driven purity test.

The ceremony is a necessary delusion so they can maintain some imaginary tribal membership to some fiction of "senior developer" they have constructed out of bad advice and empty platitudes by other misdirected self-assessed experts.

It's like the anti-climate-change or anti-vaccine people who think they are smarter than everyone; ignorance breeds a confidence that only progresses the pursuit of greater ignorance. Like astrology, these imagined worlds are far richer and more complicated because they have to construct something that follows arbitrary rules and disagrees at a fundamental level with basic realities to prop up mythical narratives holding their tribes together.

What a way to build things.

Re: Second-guessing the modern web (2020)

#309

Earlier quoted context omitted.

High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally). If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers…

You should be able to write thunks in the same file as `createSlice`, usually in front of the `createSlice` call, and then use the `extraReducers` "builder callback" syntax inside the slice to handle the various actions dispatched by the thunk. See the example here: - https://redux-toolkit.js.org/usage/usage-with-typescript#typ... And yeah, `createSelector` _is_ the Reselect API, just re-exported. You might want to a…

Ah yes. We did end up using extraReducers, but didn’t love that the thunks and their corresponding reducers had to live in separate parts of the file. (For me at least, mentally simpler to have an action and it’s reducer close together.)

This looks cool, thanks for passing along! I’m actually starting a new project now, and deciding what my state management / caching layer should be, so great to know this is an option.

Post reply on HN