buchanaf's comments

Can't tell if this is serious or not.

RTKQ is terrific. Between things like that and MUI, the level of productivity you can achieve really is amazing.

Also, thanks for your work -- really, really appreciate it.

Ya, I tend to agree with webmaven. None of the offers jump out in terms of being worth it. Take a break, work on your interview weaknesses, and try again in a bit. Enjoy the summer and keep things chill at work.

This sounds made up.

Use other forms of electricity generation?

This plus the fact that accepting crypto payments is relatively trivial compared to processing and handling the VAT and sales tax for a billion jurisdictions that also happen to change all the time.

Really the trick is to use react-spring or react-transition-group and leverage powerful community tools that have solved these complex use cases.

I don't know. I'm not as familiar with Vue, but React's ecosystem is in such a good spot right now. Between things like RTKQ (or react-query), Material-UI, and react-hook-form, the abstractions over common web use-cases are just so terrific to work with nowadays.

And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.

It's a monorepo, so the only package you are really interested in is 'packages/react-dom', which I'm guessing is less than 3 million.

Compatibility isn't really a consideration nowadays.

I'd take a look at https://cushionapp.com/blog and https://cushionapp.com/running-costs/. He's posted on here a couple of times and has a setup that is very similar to what I'd roll with if I was going to bootstrap an app: React, Rails, and Heroku. People on here like to hate on the React ecosystem, but it's pretty straightforward if you stay on the paved path of create-react-app, react-router, redux-toolkit, and material-ui.

Very unlikely. You'll see more of a merger where client-side solutions are leveraged in very specific ways to address web requirements -- similar to next.js and gatsby.js.

Well there's one way to slow down China's economy. Nothing says first-world country like crippling student-loan debt.

All of that and more.

- Performance: most major frameworks use a virtual DOM to minimize the number of repaints. Off the top of my head, Vue has computed properties that cache calculations and React has aysnc/priority rendering. I imagine there's a good deal of other stuff.

- Cross-browser consistency: React has a synthetic event system that normalizes events between all of the different browsers. There's certainly less "gotchas" between browsers than there used to be, but its nice relying on a web framework with a huge testing suite to ensure those "gotchas" are taken care of.

- Community plugins: I was more alluding to the number of UI components that are available for use. Have you ever tried to make an accessible, styled dropdown menu? How about one with search capabilities or multiple selections? There's a lot of tricky UI components that have been created by the community at large that you can just drop into your application without having to spend a day or two developing and another month or two debugging.

- Maintainability: front-end frameworks generally come with conventions. They encourage modular, reusable components. This is much more difficult to achieve with vanilla, and if it is achieved, you have in essence created your own "custom" framework.

- Easier developer ob-boarding: Like I mentioned above -- framework conventions. In addition, framework documentation and examples by the community. You can't run through a bunch of tutorials if Joe Schmoo "winged" the entire front-end code base with vanilla.js.

- Framework updates: React just released Fiber, a huge update that dramatically lowered the size of the library, increased the perceived rendering performance, and added additional APIs. There is a huge group of open source contributors continuing to perfect that library. That's pretty sweet.

Short answer: maintainability, performance, cross-browser consistency, community plugins, easier developer on-boarding, and framework updates and maintenance (which amplifies most of the previous).

Obviously a lot depends on the complexity of the website, but for the most part, any web _application_ will be better served by a framework. Heck, most static sites can now be amplified by layering on frameworks if done correctly (ie GatsbyJs).

Could you elaborate on their aloofness? What exactly do you hope to achieve by regulating them?

They seem to take the privacy of their users far more seriously than other competitors as well as the government (US - net neutrality).

Not the most compelling list of pros/cons that I have ever seen.

In terms of raw performance for content sites, I found hybrid implementations like Gatsby.js to beat most things. Most of the cons of SPAs can be significantly diminished with SSR, proper chunking, and a variety of other modern techniques -- it just gets complicated in a hurry.

Heck, I would simply be worried about a 1x drop.

A pyramid scheme involves some form of active (fraudulent) recruitment to help increase the price of the asset. Bitcoin doesn't have this.

From what you described above, every single speculative/overinflated asset would be a pyramid scheme. That's not the case.