3 ms·

What makes you say that better tools don't make better apps? A screwdriver changes removing a screw task from "extremely hard" to "extremely easy". Same way, a

What makes you say that better tools don't make better apps? A screwdriver changes removing a screw task from "extremely hard" to "extremely easy". Same way, a web framework makes writing a secure web server substantially easier than starting from scratch.

xwolfi 4y ago
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.
- claytongulick 4y ago
  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.
  - prox 4y ago
    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.
- ratww 4y ago
  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.
croes 4y ago
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.
- gfody 4y ago
  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)
  - croes 4y ago
    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.
    - gfody 4y ago
      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
- moring 4y ago
  > 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.
pclmulqdq 4y ago
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.
- Fire-Dragon-DoL 4y ago
  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.
  - pclmulqdq 4y ago
    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.

xwolfi 4y ago

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.

claytongulick 4y ago
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.
- prox 4y ago
  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.
ratww 4y ago
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.

croes 4y ago

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.

gfody 4y ago
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)
- croes 4y ago
  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.
  - gfody 4y ago
    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
moring 4y ago
> 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.

pclmulqdq 4y ago

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.

Fire-Dragon-DoL 4y ago
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.
- pclmulqdq 4y ago
  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.