and on the other hand you have engineers who stopped caring about the technologies and started prioritizing performance, reliability, resilience, etc.

It took me 5 years to realize that "bleeding edge" != "best practice".

Gatsby uses GraphQL and React to generate a static website. I muttered angrily at it everytime some data was not available in the page because I forgot to update the GraphQL query.

It is just a static website for crying out loud.

But once I got around it, it gave me a score of 100 in performance and 80 in SEO just out of the box. Images are resized and inlined if need be; critical CSS is rendered first; the plugins added niceties like default anchor link in Github. And I could use React components to organize everything, which is a much more ergonomic way of doing reusable markup compared to server-side things like Rails partials.

I would've needed to spend weeks if I had to get here from scratch. Gatsby is bleeding edge and it does best practices - including performance better than most other static site generators. I think the web is only moving forward - there is cambrian explosion of new untested and often ill-thought ideas, but the good ones will survive in the long run.

Gatsby shines when you combine multiple sources - Twitter, Instagram, YouTube feeds along with blog articles as a simplistic example. With GraphQL you have ultimate control over all of it and can organize automate it sensibly without writing custom plugins.

Hmmm... interesting. We are using something similar (https://nextjs.org/) on our marketing site and our performance is a single digits on lighthouse.

By default Next.js scores 100/100 on performance and best practices eg https://nextjs-3q3i4heaj.now.sh/ (SEO / Accessibility are not 100 as I didn't add meta tags in this example, but are very trivial to add.)

In case of Invision it seems like images / render blocking css that was added outside of Next.js are the main culprit. I've reached out to Jon Wheeler who works on the marketing site to make him aware.

I know it’s trandy to disqualify jQuery, but I’ve yet to see a rational argument that justifies it.

Most small to medium sized projects don’t need MVC, build systems, preprocessors, docker, etc. It's just a collective fascination for shinny overly complex things.

Even if you decide MVC is not needed, it's just as likely you won't need jQuery either. Vanilla JS is pretty powerful and cross browser complaint these days.

Jquery is messy on a large scale, but on a small scale it allows you type far less code than pure JS. On small to medium size projects, it's entirely reasonable to remain the best tool.