4 ms·

I think at this point it really depends on the type of app, the browsers supported, and exactly what you mean by "without a framework." The sentiment you're exp

I think at this point it really depends on the type of app, the browsers supported, and exactly what you mean by "without a framework." The sentiment you're expressing, although true to an extent, sounds like something I would have said 10 years ago. 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.

acdha 9y ago
Another factor is that we’re seeing the continued rise of massive front end frameworks at the same time that the native JavaScript environment is becoming faster and easier to use. There’s a non-trivial number of sites where the easiest thing to maintain will be standard JS/CSS rather than whatever was in vogue a few years before. 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.

acdha 9y ago

Another factor is that we’re seeing the continued rise of massive front end frameworks at the same time that the native JavaScript environment is becoming faster and easier to use. There’s a non-trivial number of sites where the easiest thing to maintain will be standard JS/CSS rather than whatever was in vogue a few years before. 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.