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…
Second-guessing the modern web (2020)
141–150 of 309 posts
Re: Second-guessing the modern web (2020)
#142One 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…
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)
#143Earlier 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…
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)
#144Earlier 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.…
Re: Second-guessing the modern web (2020)
#145I 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)
#146Earlier 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.
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)
#147I 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…
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)
#148Earlier 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…
Re: Second-guessing the modern web (2020)
#149Earlier 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…
Re: Second-guessing the modern web (2020)
#150The 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…
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.