4 ms·

I'm not quite in the same boat, but everything I do these days is related to webdev, and pretty much all of the sites I work on are not technically difficult (d

by Osmose 13y ago

I'm not quite in the same boat, but everything I do these days is related to webdev, and pretty much all of the sites I work on are not technically difficult (data is in the hundreds of thousands of database rows, tasks are straightforward "take data from here, do very basic aggregation, and put it there"), so I can relate to the sense that lots (not all) of web development is not on the same level of complexity. The thing that makes it seem that way is that webdev has a low barrier to entry. A person can get a website doing pretty impressive things from a user's perspective without understanding a lot of the fundamental pieces that are helping them along. What I've noticed is that webdev can be very complex, but in not-so-obvious ways. For example (and none of these are exclusive to webdev): - Web development brings together a stupid amount of different components. The number of acronyms between a string of text on your server and a rendered webpage on your user's computer is absurd, and learning the ins and outs of all of them is daunting. There's server software that actually runs your web app, the layers of networking that get the output to the user, the mini-Operating-System that is the web browser to render your output, and more. - Websites are very often meant to be seen by tons of people at the same time. Everyone wants to make a popular website, but that brings with it concurrency and scaling problems. - Most websites don't get to choose who their users are. They come with many different types of software, and have many different types of hardware, from many different places around the world. This has performance issues, localization issues, and UX issues. - The web technology stack evolves quickly for a bunch of reasons. You may have a strong opinion of trying out new tech vs. keeping a stable stack over the long term (what does long term mean for you, anyway? 5 years? 10? 50?), but there's benefits and disadvantages to either side, and generally it means you have to keep tabs on the latest developments so that you don't fall behind. If I had to shorten this, I'd say that the complexity in web development lies not in depth, but in breadth. An effective web developer is a jack of all trades.

Retric 13y ago
IMO, developers underestimate the actual costs of adding a new tech/layer/interface to their design which is why they use "a stupid amount of different components". I suspect that's also why new architectures/langues can catch on so fast. They don't really have to be much better just avoiding the cruft is a huge leg up until the next wave of small 3rd party library's show up and tracing a bug can once again involve tracing though 50+ files.
- Osmose 13y ago
  Just to clarify, by "stupid amount of different components" I meant more that a typical visit to website can involve tons of different, standalone components: Database, application server, cache, load balancer, CDN, browser, etc. Your comment seems more focused on libraries, frameworks, and languages, but I may be reading it wrong.
  - Retric 13y ago
    As a counter example. This website does not use a CDN, cache, load balancer, or from what I understand even a Database yet it's ranked ~1,515 in the US by alexa. Which is probably why it's also fairly low maintenance.
    - Osmose 13y ago
      That's a fair point, although there's a few caveats (HN uses CloudFlare I think, and replace "database" with "filesystem" and it's still another component to deal with). My counter-argument would be that HN is able to avoid a lot of the complexity due to the nature of what it does. Oftentimes the value in adding a new component is maintainability vs doing it the simple way, which is one of the tradeoffs I was referring to earlier. Imagine scaling Google Analytics.

by Osmose 13y ago

Retric 13y ago

IMO, developers underestimate the actual costs of adding a new tech/layer/interface to their design which is why they use "a stupid amount of different components". I suspect that's also why new architectures/langues can catch on so fast. They don't really have to be much better just avoiding the cruft is a huge leg up until the next wave of small 3rd party library's show up and tracing a bug can once again involve tracing though 50+ files.

Osmose 13y ago
Just to clarify, by "stupid amount of different components" I meant more that a typical visit to website can involve tons of different, standalone components: Database, application server, cache, load balancer, CDN, browser, etc. Your comment seems more focused on libraries, frameworks, and languages, but I may be reading it wrong.
- Retric 13y ago
  As a counter example. This website does not use a CDN, cache, load balancer, or from what I understand even a Database yet it's ranked ~1,515 in the US by alexa. Which is probably why it's also fairly low maintenance.
  - Osmose 13y ago
    That's a fair point, although there's a few caveats (HN uses CloudFlare I think, and replace "database" with "filesystem" and it's still another component to deal with). My counter-argument would be that HN is able to avoid a lot of the complexity due to the nature of what it does. Oftentimes the value in adding a new component is maintainability vs doing it the simple way, which is one of the tradeoffs I was referring to earlier. Imagine scaling Google Analytics.