I think this is a bit short-sighted. While building a framework from scratch is certainly not for everyone, there's definitely value in building one. You say things like `you have to maintain your poorly cobbled-together "framework"` but when you think about it, this was true of authors of major frameworks at some point as well.
Remember when React added id's to every single DOM element? Or when Ember was dog slow? Framework authors and maintainers learn lessons over time and with each project iteration they become more valuable due to their skillsets.
> If someone DOES pick it up after you, (the poor bastards), they are going to be bothering you day and night, or go insane after 2 weeks
Again going back to skillsets: this is part of what makes large OSS project developers desirable: they've been through the process of passing-the-baton and they know the importance of things like documentation, maintainability, etc and can take concrete steps to further goals in those areas.
It really just works - drop it into a project and you instantly have a SPA. Its far from a framework - its API has less surface area than even React. The above comment couldn't apply less to Turbolinks.
The only true caveat necessary is that it's written in CoffeeScript. :P
If you decide to put your effort into customizing the framework, you increase your risk of building
> [...] your poorly cobbled-together "framework" for the next 2, 3, or more years. If anything changes and pages stop working "right", you get to pick up the pieces. Yes, "you", because since your framework is something that you pieced together, there are no "tutorials" nor stack overflow questions nor manuals to refer to.
Their new Polaris components are using React though: https://github.com/shopify/polaris
An anecdote is not data.
https://github.com/turbolinks/turbolinks#turbolinksclearcach...
This is a nightmare. You will eventually miss a cache invalidation and break browser navigation or invalidate the cache so aggressively that TurboLinks is serving no purpose.
You don't need lots of negative testimonials to see that managing your own client side cache with JavaScript is a bad idea.
It's VERY rare, almost unheard-of, to find any front-ends these days that are just HTML, CSS, and Javascript. That wasn't the case 10 years ago. IMO we don't know what a modern app would be like without a framework because it's just not done anymore. Even this post here uses Turbolinks, a framework.
It's also rare these days (in my experience anyway) that clients will ask for things that are simply not possible with HTML, CSS, and JS. Website design has started to get very same-y, and both HTML and CSS have gone through huge upgrades. Depending on the requirements you might be able to pull off a modern-looking design with just the basics.
Browser compatibility remains a problem, but most JS tools called "frameworks" don't exist to solve that one, but mostly to help structure large amounts of JS code. These tools simply did not exist at all back then, because people just didn't write that much front-end code. On SPAs, a lot of the code is only there to reinvent things the browser and the back-end could be doing.
If I was starting a new project I would probably go very light on the tooling.
This is also of interest from the performance angle: frameworks take on a lot of expense maintaining certain levels of magic, convenience, and general applicability which has its benefits but also makes it easier to miss or fix problems. The first time I tried React on a serious project, the coworker who’d been hyperventilating about how fast the virtual DOM would be was surprised to learn that it was something like 40,000 times slower and that there was no easy way to fix it (innerHTML updates on rows in a large table when textContent was sufficient).
The last time I did a fresh project I ended up using just ES6 + SCSS and found it to be quite pleasantly rewarding. So many of the old tedious points have gone away with flexbox / grids, ES6 classes and arrow functions, querySelectorAll and the newer array methods, fetch vs. xhr, etc.
It actually isn't THAT hard, but what will happen is that you'll end up reinventing the wheel badly, and you'll be chasing bugs and fixing platform inconsistencies for months.
It won't be optimized and it won't work in some random obscure browser, or under some random platform (and there's always THAT user that just happens to have that browser/platform combo... Murphy's Law spares no one).
Also remember: YOU have to maintain your poorly cobbled-together "framework" for the next 2, 3, or more years. If anything changes and pages stop working "right", you get to pick up the pieces. Yes, "you", because since your framework is something that you pieced together, there are no "tutorials" nor stack overflow questions nor manuals to refer to.
If someone DOES pick it up after you, (the poor bastards), they are going to be bothering you day and night, or go insane after 2 weeks.
In conclusion, just grab something that works for you and is reasonably well supported (and looks like it will REMAIN supported in the future) and use that. Don't fall into the "NIH syndrome" trap.