This is surprisingly not true, have you tried ? When you start from scratch you realize you have a tiny minuscule surface and securing that very small hole is much easier than say... fixing the log4j 20th level transitive dependency of your giant Spring Framework that was secretly able to interpret random input from logs or someth.

Especially if all you wanted was to show a quick html output. It's incredibly common to see giant dynamic web stuff used for tiny static output that could have done without.

I've done both in large volume websites and I find now that using as little "framework" as possible and a limited number of "libraries" works better in terms of cost, bugs, dev attrition, business desire implementation and user speed of render.

Picture a giant mess of node dependencies surrounding a central giant quirky framework like VueJS. 5 years of dev, all devs left. You need to maintain that, is that going to be easy ? Wasn't for me.

I'm living this right now.

It's why when I have greenfield I do vanilla web components, with a little lit-html sprinkled in for fast rendering.

I've seen so many developers complain about how complex vanilla web components are, and they'll turn around and do React / Vue / Angular and Redux or (shudder) rxjs, etc...

I just don't get it.

Like, if you need reactivity... Stick a render call into the setter of a plain old property.

If you don't, use a variable.

The whole computed() thing with Vue makes things so complex... I have to deal with a huge rabbit hole of that stuff all the time.

I think to myself... I could just use a property, and I wouldn't need a whole painful build step, type definitions, framework version specific DSLs, massive complex source maps that don't work, Rube Goldberg state machines, crazy pseudo DOM elements that aren't really DOM elements, unless they are, or a ref to something magic that might end up being a DOM element someday, obscure dependency injection cruft that's done way better by just using dynamic imports...

I remember when I couldn't wait for Proxy to be widely supported by browsers.

Now I'd do anything to be able to shove that toothpaste back into the tube.

I don't know.

I don't see any of this providing any value.

I feel like the emperor has no clothes, but everyone else thinks he's wearing Armani.

I am in front end webdev, and a lot of time I have had design colleagues that came up with crazy paid solutions for something as simple as a pop up. When I overheard and mentioned I could implement that in 2 hours tops it was a bit of a no brainer. The pure design folks often don’t know the tools or what’s possible.

To this day I just do mysql/php/js and simple ajax calls for a lot of solutions. Most clients are in the 100k-500k of hits and it works fine.

Yep, same experience.

A large "ecosystem" is touted as a great advantage of some frameworks, but the reality is that it's mostly unmaintained low-quality libraries that could be replaced by a few lines of easier to understand code. "The Ecosystem" is about quantity over quality, all the way down. And when those unmaintained libraries break, you're also in the hook for fixing them, but it takes way more time and coordination than fixing it if it were your own code.

So just because you can remove screws more easily you build better shelves?

You can build bad apps with good tools and good apps with bad tools. Just because it gets easier for the web dev doesn't makes it easier for the user and vice versa.

> So just because you can remove screws more easily you build better shelves?

Yes, with a high probability. Try to put all your screwdrivers away and then try to build a shelf without them. Not only will you need lots of time just for fastening the parts that you cannot spend on thinking on a more optimal layout of the shelf, making the result worse -- you will also judge every layout idea on how hard it will be to build without a screwdriver, instead of judging it on whether it is useful as part of the final shelf.

> You can build bad apps with good tools and good apps with bad tools.

This is a (probably unintentional) strawman. The argument was that tools make the task substantially easier and therefore improve the quality of the end result, not that they make it possible at all.

> Just because it gets easier for the web dev doesn't makes it easier for the user and vice versa.

Again, the argument was that tools make it easier to build a good product, not that tools themselves guarantee a good product. Of course with good tools you can build a bad product, and you can even build it easier than without good tools.

The argument "tools make the task substantially easier" was already a strawmen because the article is about bad UX with existing apps. And web devs already have "screwdrivers" but the apps don't get better.

Maybe it isn't the tools because there are great apps on the web,s some of them even without many tools. Maybe it's time to stop blaiming the tooling and focus on the developers and their environment.

I'm not a bad painter because of the wrong brushes, I'm just not good at it (yet).

I don't think the argument was "screwdriver" vs "no screwdriver". It was about some tools being better than others.

Everyone in web dev uses tools of some sort. The argument might be that some tools are so advanced, it's like using a robot arm for tightening a few screws. Some devs will embrace robot arms, others will use a screwdriver.

Thank you for describing my thoughts way better than I did

>So just because you can remove screws more easily you build better shelves?

probably you build the same quality shelves slightly faster, being able to build things faster allows you to learn faster, by not focusing mental and physical energy on the relatively stupid task of removing screws you have more mental and physical energy to focus on things that maybe actually help you build better shelves.

A lot of the badness of the apps however is somewhat business driven, dark patterns etc.

you're making a point here and the counterpoint is that building good apps with bad tools requires extra effort that costs money that the business owners don't have because the market won't support it (ie nobody is willing to pay more for higher quality stuff - you need to figure out how to make high quality easier)

But the whole point of the article is that the apps are bad no matter the tools. One should first know how to produce high quality in the first place before thinking about how to produce it more easily. All the brushes in the world won't let me paint like Leonardo da Vinci.

I don't disagree but quality tools are about raising the floor, I haven't had to worry about a ceiling falling on me my whole life because fastener technology is very good

Have you even tried building a shelf without a screw driver? It literally falls apart after one day of usage

You do realizes stable shelves existed before screws?

Ever heard about dowels and glue and whatnot?

I specifically mentioned screws to highlight the fact that it's a shelf with holes for screws already there. Either way, using glue would remove the possibility of disassembling the shelf for moving, which is a downgrade from my perspective

Nails?

In the history of construction, better tools have not improved quality of output. People in the ancient era made amazingly fine furniture. The finest furniture made today still uses techniques similar to the ones used 300 years ago.

Similarly, I doubt that better web development tools improve the quality of apps. It likely just makes them cheaper.

There are good tools and bad tools, we just tend to forget the ones we depend on the most. Let's try to write a web page with concurrent access without a database, or let's try to write a web server using C or Assembly and no libraries, because we don't want to rely on tools.

Our industry is built on layers and layers, every layer is a tool to the next layer, how can we claim better tools don't make better applications?

Sure, it does not guarantee it, because what the tool does is raising the baseline, however raising the baseline gives you time to push the top higher.

Let's take the web server example: The most commonly used web server is nginx. Written in C (possibly C++ now?), with no libraries except Linux headers.

The layers are there to make developers more productive, not to make code quality better. In fact, layering is probably the most expensive thing that computers do today.