Hey, OP here! I think I could've worded that better. It does sound a bit anti-framework when it wasn't meant to be at all. I was thinking more in broader terms where you'll inevitably be using Browser APIs even within a framework like React.

I specifically tried to avoid talking too much about stuff like React, Next, Tailwind, etc.

I’m not sure I agree with your takes on frameworks. It definitely depends on what you’re building, but in React to have composition and reuse for free immediately sets it apart from any bespoke solutions. I’m also struggling to imagine how you propose to out-scale the React framework with early & tough design decisions... these are Facebook engineers that made those same decisions, and they managed to scale the framework to Facebook levels. You understand that they may be the UI leaders of the world, yes?

Facebook, the product, did not use React until very very recently.

Do you use FB? If Facebook’s interface represents the “UI leaders of the world” we’re in troubled waters!

Can you say more about why we'd be in troubled waters for such a thing?

Facebook and its non-titular products are probably used by the most people in the world. The org is 50k people, and I imagine their engineering staff is proportionally quite large - they rarely introduce bugs and seem to have quite a good update cycle. There is a huge featureset and the website performs very well.

> the website performs very well

IME you could measure page transitions in seconds, it is an extremely slow website

If composition is your first concern you lack vision. Instead start from a good idea, form a vision on how you want to execute that idea, determine what you need, and then build those pieces in isolation. You get separation of concerns for free and composition becomes the last step. If you spend all your energy over concerns on how to build something you are spending creative energy thinking about what cool things to build.

What kind of design decisions are you talking about, any examples?

What would you suggest for interactivity and JS; e.g. in a dashboard application with crud records/posts?

The benefit of a dashboard is real time status updates. My recommendation is don’t think about the JS at all. None.

Instead focus on services. Get the content you need. I recommend web sockets so that the updates come to the browser asynchronously without polling the server.

Once you have what you need you will figure out the most ideal user interactions.

Yeah one major benefit of a framework is the ability for new-to-the-team devs to get up to speed quickly and in general for people to understand what’s going on without having to pickup your domain specific stuff.

Similar to reasons Java became so popular in the enterprise

This is pretty drab. I can be up and started in about two minutes with React, typescript and parcel.

He didn’t say “started”, but up and running. I interpret that as having a basic working site.

By the time you build your solution in native DOM, you've missed the market.

This is why we don't write applications in assembler.

If performance is your only metric, write Rust and target WASM. But that's probably not the right solution for 95% of cases.

VS Code must have been lucky then.

VS Code requires more careful engineering than a CRUD web app. It also has a lot more dedicated talent with eyes on the problem.

These technologies aren’t limited to CRUD apps.

I built a Windows like GUI, including basic file system display and population, using native DOM for the front end of a node app. It took me, one person, two weeks. It includes state management.

If you think that’s the same as writing assembly you probably aren’t the right guy to drive the success of a startup.

> you probably aren’t the right guy to drive the success of a startup.

Since when did giving honest opinions about speed and practicality merit personal insults?

It’s not an insult. If you took that as an insult you probably aren’t as open to honesty as you imagine.

I'm probably not a lot of the things you call me. :)