9 ms·

The author complains that developers argue about their tools and methods, insist on their favorite techniques, but produce (more) worse apps. Particularly for t

The author complains that developers argue about their tools and methods, insist on their favorite techniques, but produce (more) worse apps. Particularly for the amount of time and effort expended on developing the apps. The thing is: the debates aren’t naive. They’re exactly trying to workout the details. When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory … Well they’re trying to solve the problem of (more) better apps with their limited resources. That’s essentially the problem of development. Asking people to solve development without discussing the tools and methods is to misunderstand the nature of the discussion. It’s like telling authors to get on and write better novels and not waste time with their opinions on character and plot.

sidlls 4y ago
The problem of which DB to use is one that can be figured out ahead of time with even modest attention to more rigorous engineering practice. But that’s not what webdevs the subject of this article do. They play guess-and-check games like they are 15th century engineers building a bridge, because they have hacker mentalities instead of engineer mentalities. Not to mention the cult of celebrity and fad following in the industry.
- dasil003 4y ago
  The analogies to civil engineering are strained. Sure there is some truth to what you are saying, but also requirements for civil engineering projects tend to be more easily stated at a high level and are depending on the unchanging and unforgiving laws of physics plus some slowly growing list of available materials and construction processes. Everyone understands intuitively that bridges are expensive and you can't just change requirements on a whim without potentially blowing up the whole project and starting over. Software on the other hand can be made to do anything, we can change it any time, and the technical requirements for scale and functionality are hard to predict ahead of time. Trying to apply civil engineering mentality to software results in a process that is too slow and gets beaten by hacker mentality every time.
  - cyber_kinetist 4y ago
    Software is also limited by the laws of physics, which is the actual hardware (silicon) it’s running on. Things like CPU clock speed, IPC, memory latency and throughput are all constrained by things like the speed of light, capacitor physics, current status of silicon technology and manufacturing, etc. So when a web app performs sluggish on commodity devices, it’s because the devs haven’t put thought into the actual physical constraints of CPU and memory. It’s just plain bad engineering. (You might say that the whole browser DOM/JS model is at fault, but then that’s bad engineering for the Web spec designers. To be fair though, things like the DOM and JS were invented about 3 decades ago at the time when computer performance was increasing so fast that people really didn’t think about these constraints seriously. Nowadays things are different, and these initial design decisions are biting us…)
- deleted 4y ago
  [deleted]
cyanydeez 4y ago
YAGNI is what you're talking about, and it's easy to choose tech that makes you worse
rektide 4y ago
We can tackle so-called "essential" problems forever & make no progress actually making the web better though. This post impacted me & resonated strongly: it's a great notice to be more alert as to whether we're talking about details or something core & significant. Devs can have these discussions deep in the weeds, but it's kind of a farce & disservice when the petty implementation details flood & overrun the topics of what we're making & how we've enriched the media-form.
croes 4y ago
I disagree. Web devs aren't discussing characters and plots but instead argue which typewriter to use. Better tools don't make better apps just like word processors don't make better books. The best web dev tools are worthless if the UX is bad.
- xwdv 4y ago
  Frameworks are not tools. You select technologies based on their fit for the requirements of the web app.
  - na85 4y ago
    Frameworks have a direct impact on UX though. How many React monstrosities are snappy and responsive? Certainly none that I've used.
    - belenos46 4y ago
      I can't tell you how many snappy, easy-to-use React sites I've used (I was busy using them, not reviewing their code), but every single time I've said "What the hell is going on, I'm just trying to [simple operation which is the only purpose of the website I'm on]" in the last five or so years, it's some React/Angular/SPAFrankenstein monstrosity.
    - moring 4y ago
      I could say the same about almost every web app that gets rendered on the server because every tiny step of interaction needs a network round-trip.
  - croes 4y ago
    Frameworks are tools
    - berkes 4y ago
      No. They aren't. Frameworks are the scaffolding, the skeleton. They dictate the shape. It's literally in the name. > : a skeletal, openwork, or structural frame Tools are the things you use to build within that skeleton. More pragmatic: Rails is a framework that dictates an MVC shape, with an RDS, that produces server side rendered HTML or data in a RESTfull manner. The tools you use for Rails development are your IDE, a CI, revision control, a terminal, maybe even the IAAS provider.
onion2k 4y ago
When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory … This is a good example of how devs get things wrong. The argument between which database to use because you might hit the row limit has zero benefit to the user. It's devs wanting to avoid future work to migrate from one database to another; a problem most apps will never actually see. There's even an aphorism about this exact thing in dev: YAGNI https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it Solve the problem you have, not thr problem you want.
- adrianN 4y ago
  Maybe most apps never see the problem of hitting the row limit because the devs spend time beforehand thinking about which limitations they're likely to hit.
  - onion2k 4y ago
    It's definitely possible, but the limit is 18,446,744,073,709,551,616 rows, or 281 terabytes, whichever the database hits first, so you probably could put the discussion off until year 2 or 3 if you really had to. Kind of like maybe the 'Send your friends money, divide the restaurant bill easily!' app founders first think will change the world could get really popular if it gets on the frontpage of HN..
    - christkv 4y ago
      I have a feeling you will long before experience other problems that makes likely you have to migrate to a different storage system before you hit that limit.
      - noir_lord 4y ago
        Given it's ~2 billion rows for every person the planet I reckon so. Other than Facebook who has 2 billion rows for every person the planet (tongue in cheek).
strken 4y ago
I think the argument is different. Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on cheap bare metal ARM servers, and therefore your website is simple, usable, never goes down, and costs $20/month to run. I have no idea if this is actually good, but let's agree that there's some idealised system out there that would be a lot better than what we have now, even if it doesn't look like this one. Let's also say I use React and Redux backed by a CQRS Express app running on MongoDB and Kafka, all hosted on AWS, and (for the sake of the argument) let's say this causes my website to be broken in bizarre ways, down all the time, and costs $2000/month to run. This is definitely an exaggeration and some of these technologies are great, but let's agree that there are some hellishly over-engineered systems out there, even if they don't look like this one. I think the argument is that what matters here is having an example of a $20/month uncomplicated beautiful system to point to. Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool means everyone will use the broken $2000/month system as an exemplar in your field, because they have nothing better to point to.
- hdjjhhvvhga 4y ago
  > because they have nothing better to point to. Well - they do. For example, HN is running on a simple bare metal machine, with another one waiting for emergency.
  - strken 4y ago
    Yep! Good example.
  - dist1ll 4y ago
    Do you have a source for that?
    - hdjjhhvvhga 4y ago
      https://news.ycombinator.com/item?id=31821904 https://news.ycombinator.com/item?id=31821904
mattbrewsbytes 4y ago
Everyone is going to miss the point here and go down rabbit holes about various technical bits and that is exactly the point: developers spend lots of time debating everything The limited resources really doesn't matter. The tech choices really don't matter. Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. Lean towards picking stuff the team has experience using. Then if the web app gets heavier traffic, horizontally scale the web tier and vertically scale the DB to your companies budget. If that amount of scaling doesn't suffice - do the research as you approach that level of traffic not when you have zero users. When it comes down to standard web apps there are known patterns and known solutions out there to solve the majority of the problems. Reaching for a new/shiny thing to use is fun, learning new development techniques is fun but its rare either of those is going to cause a fundamental shift in solving problems with web apps. We have been using (abusing?) HTTP/HTML/JS/CSS for 25+ years. For small web apps I bet people could solve things with simple PERL/PHP cgi-bin types of scripts today with current versions of HTML/JS/CSS, albeit more securely than in 1999. To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house, one uses less nails, one is faster, one is a nail with wood glue that will expand at the joint and provide less squeaky floors (I made that up). None of it really matters, you're being paid to frame a house, not do research - just build the thing.
- julianlam 4y ago
  > To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house The way I see it, modern web development isn't about debating which wood screws to use or which lengths of wood... it's arguing about which pre-fab construction to use (a framework), and whether it's acceptable that if you want to build a KitchenObject, you have to start off with a RoomObject and add PlumbingFixtures, but you end up with a ClosetChild in the kitchen because it was inherited with the RoomObject. Meanwhile I'm just here building with 2x4s and wood screws, watching the debate rage on :)
- tinalumfoil 4y ago
  > Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. It's really not that easy. At very least the framework you use needs to be well thought-out so you don't run into roadblocks later, and your application may very well lend itself to certain technologies that won't be obvious if you don't spend some time thinking things through and understanding tradeoffs. When constructing a building you don't just choose a material, a layout, etc and get to work. There's significant effort in understanding the environment you're building in so you can inform your choices. Buildings have collapsed because the soil conditions weren't well enough understood.

sidlls 4y ago

The problem of which DB to use is one that can be figured out ahead of time with even modest attention to more rigorous engineering practice. But that’s not what webdevs the subject of this article do. They play guess-and-check games like they are 15th century engineers building a bridge, because they have hacker mentalities instead of engineer mentalities. Not to mention the cult of celebrity and fad following in the industry.

dasil003 4y ago
The analogies to civil engineering are strained. Sure there is some truth to what you are saying, but also requirements for civil engineering projects tend to be more easily stated at a high level and are depending on the unchanging and unforgiving laws of physics plus some slowly growing list of available materials and construction processes. Everyone understands intuitively that bridges are expensive and you can't just change requirements on a whim without potentially blowing up the whole project and starting over. Software on the other hand can be made to do anything, we can change it any time, and the technical requirements for scale and functionality are hard to predict ahead of time. Trying to apply civil engineering mentality to software results in a process that is too slow and gets beaten by hacker mentality every time.
- cyber_kinetist 4y ago
  Software is also limited by the laws of physics, which is the actual hardware (silicon) it’s running on. Things like CPU clock speed, IPC, memory latency and throughput are all constrained by things like the speed of light, capacitor physics, current status of silicon technology and manufacturing, etc. So when a web app performs sluggish on commodity devices, it’s because the devs haven’t put thought into the actual physical constraints of CPU and memory. It’s just plain bad engineering. (You might say that the whole browser DOM/JS model is at fault, but then that’s bad engineering for the Web spec designers. To be fair though, things like the DOM and JS were invented about 3 decades ago at the time when computer performance was increasing so fast that people really didn’t think about these constraints seriously. Nowadays things are different, and these initial design decisions are biting us…)
deleted 4y ago
[deleted]

cyanydeez 4y ago

YAGNI is what you're talking about, and it's easy to choose tech that makes you worse

rektide 4y ago

We can tackle so-called "essential" problems forever & make no progress actually making the web better though. This post impacted me & resonated strongly: it's a great notice to be more alert as to whether we're talking about details or something core & significant. Devs can have these discussions deep in the weeds, but it's kind of a farce & disservice when the petty implementation details flood & overrun the topics of what we're making & how we've enriched the media-form.

croes 4y ago

I disagree. Web devs aren't discussing characters and plots but instead argue which typewriter to use. Better tools don't make better apps just like word processors don't make better books. The best web dev tools are worthless if the UX is bad.

xwdv 4y ago
Frameworks are not tools. You select technologies based on their fit for the requirements of the web app.
- na85 4y ago
  Frameworks have a direct impact on UX though. How many React monstrosities are snappy and responsive? Certainly none that I've used.
  - belenos46 4y ago
    I can't tell you how many snappy, easy-to-use React sites I've used (I was busy using them, not reviewing their code), but every single time I've said "What the hell is going on, I'm just trying to [simple operation which is the only purpose of the website I'm on]" in the last five or so years, it's some React/Angular/SPAFrankenstein monstrosity.
  - moring 4y ago
    I could say the same about almost every web app that gets rendered on the server because every tiny step of interaction needs a network round-trip.
- croes 4y ago
  Frameworks are tools
  - berkes 4y ago
    No. They aren't. Frameworks are the scaffolding, the skeleton. They dictate the shape. It's literally in the name. > : a skeletal, openwork, or structural frame Tools are the things you use to build within that skeleton. More pragmatic: Rails is a framework that dictates an MVC shape, with an RDS, that produces server side rendered HTML or data in a RESTfull manner. The tools you use for Rails development are your IDE, a CI, revision control, a terminal, maybe even the IAAS provider.

onion2k 4y ago

When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory … This is a good example of how devs get things wrong. The argument between which database to use because you might hit the row limit has zero benefit to the user. It's devs wanting to avoid future work to migrate from one database to another; a problem most apps will never actually see. There's even an aphorism about this exact thing in dev: YAGNI https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it Solve the problem you have, not thr problem you want.

adrianN 4y ago
Maybe most apps never see the problem of hitting the row limit because the devs spend time beforehand thinking about which limitations they're likely to hit.
- onion2k 4y ago
  It's definitely possible, but the limit is 18,446,744,073,709,551,616 rows, or 281 terabytes, whichever the database hits first, so you probably could put the discussion off until year 2 or 3 if you really had to. Kind of like maybe the 'Send your friends money, divide the restaurant bill easily!' app founders first think will change the world could get really popular if it gets on the frontpage of HN..
  - christkv 4y ago
    I have a feeling you will long before experience other problems that makes likely you have to migrate to a different storage system before you hit that limit.
    - noir_lord 4y ago
      Given it's ~2 billion rows for every person the planet I reckon so. Other than Facebook who has 2 billion rows for every person the planet (tongue in cheek).

strken 4y ago

I think the argument is different. Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on cheap bare metal ARM servers, and therefore your website is simple, usable, never goes down, and costs $20/month to run. I have no idea if this is actually good, but let's agree that there's some idealised system out there that would be a lot better than what we have now, even if it doesn't look like this one. Let's also say I use React and Redux backed by a CQRS Express app running on MongoDB and Kafka, all hosted on AWS, and (for the sake of the argument) let's say this causes my website to be broken in bizarre ways, down all the time, and costs $2000/month to run. This is definitely an exaggeration and some of these technologies are great, but let's agree that there are some hellishly over-engineered systems out there, even if they don't look like this one. I think the argument is that what matters here is having an example of a $20/month uncomplicated beautiful system to point to. Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool means everyone will use the broken $2000/month system as an exemplar in your field, because they have nothing better to point to.

hdjjhhvvhga 4y ago
> because they have nothing better to point to. Well - they do. For example, HN is running on a simple bare metal machine, with another one waiting for emergency.
- strken 4y ago
  Yep! Good example.
- dist1ll 4y ago
  Do you have a source for that?
  - hdjjhhvvhga 4y ago
    https://news.ycombinator.com/item?id=31821904 https://news.ycombinator.com/item?id=31821904

mattbrewsbytes 4y ago

Everyone is going to miss the point here and go down rabbit holes about various technical bits and that is exactly the point: developers spend lots of time debating everything The limited resources really doesn't matter. The tech choices really don't matter. Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. Lean towards picking stuff the team has experience using. Then if the web app gets heavier traffic, horizontally scale the web tier and vertically scale the DB to your companies budget. If that amount of scaling doesn't suffice - do the research as you approach that level of traffic not when you have zero users. When it comes down to standard web apps there are known patterns and known solutions out there to solve the majority of the problems. Reaching for a new/shiny thing to use is fun, learning new development techniques is fun but its rare either of those is going to cause a fundamental shift in solving problems with web apps. We have been using (abusing?) HTTP/HTML/JS/CSS for 25+ years. For small web apps I bet people could solve things with simple PERL/PHP cgi-bin types of scripts today with current versions of HTML/JS/CSS, albeit more securely than in 1999. To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house, one uses less nails, one is faster, one is a nail with wood glue that will expand at the joint and provide less squeaky floors (I made that up). None of it really matters, you're being paid to frame a house, not do research - just build the thing.

julianlam 4y ago
> To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house The way I see it, modern web development isn't about debating which wood screws to use or which lengths of wood... it's arguing about which pre-fab construction to use (a framework), and whether it's acceptable that if you want to build a KitchenObject, you have to start off with a RoomObject and add PlumbingFixtures, but you end up with a ClosetChild in the kitchen because it was inherited with the RoomObject. Meanwhile I'm just here building with 2x4s and wood screws, watching the debate rage on :)
tinalumfoil 4y ago
> Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. It's really not that easy. At very least the framework you use needs to be well thought-out so you don't run into roadblocks later, and your application may very well lend itself to certain technologies that won't be obvious if you don't spend some time thinking things through and understanding tradeoffs. When constructing a building you don't just choose a material, a layout, etc and get to work. There's significant effort in understanding the environment you're building in so you can inform your choices. Buildings have collapsed because the soil conditions weren't well enough understood.