buchanaf

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.

The caveat is that this is in reference to a _landing page_ only. If you try to write an advanced application with vanilla.js and you aren't some Javascript guru, then you are going to really hate yourself later on -- I guarantee it.

Also, that 50% is only measuring the time to interactive on what I imagine is the first page visit. After everything becomes cached, I would think that the the benefit is dramatically lower.

Well create an index.html, inline a style tag in said file, write some CSS, npm init, npm install http-server -g, update package.json to with this script "start": "http-server", and profit.

Fear not, we have the technology.

Again, I have no anecdotal experience, but I have a hard time believing that the new hires for those 3 companies are anything but students from top-tier colleges with near perfect grades. To be fair, I'm sure a couple of years of work experience and they probably don't care as much.

Yes, people like George W. Bush, who are in the top .00000001% of privilege, don't need to do well before college, in college, after college, or even as a state or country's highest elected official.

However, for most of the mere mortals at Yale and Harvard, they still have to compete with the every other college graduate, and some of those other college graduates are pretty smart themselves.

While I didn't go to an Ivy, that's clearly not true. Do you honestly think Google, Facebook, Microsoft, Goldman, law schools, medical schools, etc., are going to accept you if you have poor grades? Not everyone can count on "daddy".

I feel like a broken record, but definitely take a look at create-react-app if you haven't already. Its extremely well documented and takes care of managing the 20+ dev dependencies that are typically associated with a project.

This was the comment that initially made me kind of shrug the article. It's like Javascript can't win. It is either moving to fast or moving to slow. Anyone who has been working with Javascript for the past couple of years (JS exclusively, not the ecosystem) would never say that the language itself is moving slowly.

As much as these features might "bloat" the language, they provide some much needed and much desired elegance.

Who writes JS like this?

It's somewhat refreshing to see an objective description of Vue and how it compares to React instead of simply "why it is better" -- from the Vue creator no less.

This doesn't really make sense to me. You have to pick a version for literally every single library you use. And those different versions have different interfaces, which is why they have different versions...