Back in the 90s I wrote my high school's first website. We even got a scan of a picture of the school done in way too high resolution. It was a massive pain to get running, given my buddy and I were in our mid teens and the web was moving fast. Everything was a bunch of different hand crafted pages of tags, served from a machine sitting in the school. But basically we figured out how to do it by reading one or two pages about it.
I left school and eventually did a lot of financial coding, which was mainly backend stuff plus a small amount of desktop GUIs, or very very basic web pages.
Not until a few years ago did I have another look at the web, and it had of course changed enormously. It seems nowadays everything is a tool that compiles into something else. There's a zillion frameworks in js, there's webassembly, there's a bunch of things that you use to build the CSS. The page itself seems to be a load of divs, many tags from the old days are archaic now, only seen on old university sites. Sites themselves are served from a datacenter, and not from one machine. Static content doesn't even need to come from the same place. Security and privacy is a thing. There's no one place to learn the whole thing, which I suppose is expected.
> There's no one place to learn the whole thing, which I suppose is expected.
Mozilla Developer Network is what I highly recommend. It covers so much of the web they even have Django web development guides / tutorials. Ages back Microsoft contributed their own docs to MDN as well (not to be confused with MSDN, which is Microsoft specific and possibly where that spec came from).
You still can write static HTML/CSS and host it on your machine (if you have accessible IP) or some cheap VPN. It'll work just fine. It's possible to write a very complex websites nowadays with those technologies. But not every website have to be complex.
Not a lot of people had computers with Internet back then. So sure, you can’t captivate the same percentage of the entire World Wide Web - but why would you expect that to be a reasonable assumption?
Sure, in a world where the web was a couple million nerds you’d expect your content to be a bit more visible.
But the web is measured in billions of users now.
I would also suggest that writing content just to ensure that people read it is looking at it the wrong way. That’s a shallow popularity contest. If the production of that content doesn’t bring you satisfaction on its own then it doesn’t matter whether you have 1 view or a million, it’s not making you happy.
Humans seek social interaction, whether that's in person or online, or by doing good or bad things to get attention. I would not call that a popularity contest because it happens with everything. A popularity contest would be one extreme end of a range of behavior.
If you are producing content for yourself and it makes you happy then you don't need to put it in public view. The whole point of the internet is to interact, share your work and see others' work.
That is the point I was refuting. In the current web, communication is still the overarching motivator. Content still matters, and the usability of your site is a factor in communicability. So, if someone's site is easier to navigate and more frequently updated due to the use of updated technology, that may be a factor when people decide where to spend their time.
Which doesn't mean you HAVE to do it this way. The new generation of devs is, well, young, and they have yet to learn that complexity will come back after their asses with no mercy.
Us old farts, we learned that complexity is our biggest enemy.
That assumes that all of this complexity was done for complexity’s sake.
There’s a big difference between a web developer who has to serve a few thousand people 10 webpages with someone who has to serve millions of customers in hundreds of countries with dozens of languages.
I suspect that a lot of the “old farts” you reference in this way aren’t old farts at all, but are just folks who haven’t been full time web developers in years, or have never done web development for a large web-based SaaS company.
And how many developers do you think out there have to "serve millions of customers in hundreds of countries with dozens of languages"?
Most of them solve problems they don't have.
Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
Because this Hello World is going to be BIG, it has to be webscale.
> Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
I don't think the mentality that drives this is "is has to be web scale" or "it will be BIG". The justifications I've heard are more along the lines of "now I don't have to manage a server". Except... you either have to learn/know how to configure something else and tell it how to manage a server, or just copy/paste/trust that you're telling service X how to configure/manage the server that you eventually need.
Or... lambda - because somehow every single problem people think of can just be broken down to chaining AWS lambdas together. I've run in to that mindset a couple of times, and it's just so foreign to me. I can't say it's "wrong" as I've not done it 'for real' (beyond playing with hello world stuff), but it typically ignores a lot of stuff I've come to embrace (like testing).
> Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
I think you're just exaggerating to make a point of outrage. I don't think anyone would write a Hello World that way.
Also, how many companies do you think decided to go serverless and then discovered after the fact that they can't serve a live website because of Lambda's spin-up delay, coming up with a patchwork of cache bandaid that made things just worse?
But it's new, and it's cool, and in the language of us Mandalorians - THIS IS THE WAY.
> And how many developers do you think out there have to "serve millions of customers in hundreds of countries with dozens of languages"?
I actually think the answer to that question is most. Most web developers are working for mid-size to large companies, especially when you consider the wider variety of non-SV companies like financial firms that might not be "tech companies."
I think the people that would have written simple web pages that don't require that complexity essentially don't exist in the business world, and probably not so much in the hobbyist world, either. Smaller companies would be better off using code-less website builders and such. And if all these web developers wanted to spend so time making simple blogs and web pages I wonder why they choose services like Medium to do it for them.
As far as small companies that actually write web software as their primary form of business, I would venture a guess that in terms of quantity, compared to FAANG, Chase, Bank of America, Nationwide, State Farm, Progressive, etc, there probably aren't that many.
I would argue this about your point on Lambdas:
A business outgrowing abstractions is okay. That means the business has grown to the point where it can hire enough developers to maintain a more sophisticated infrastructure. The fact that AWS has so many abstractions is a reason why so many startups have been able to exist in the first place.
I've never used Lambdas for a web application, and I do see that Amazon advertises that as a use case, but it's also the second to last one on their list. I think it's far better suited to doing things like responding to AWS CloudWatch Events or triggering other asynchronous actions.
Things aren't done for complexity's sake, but yet most of the web (and software generally) is way more complex than it needs to be. See the 30 million line problem for a good deep dive: https://www.youtube.com/watch?v=kZRE7HIO3vk
It tends to be related to physical age because the problems of complexity manifest with the passing of time. The more projects you work on from start through long term maintenance, the more you personally experience the issues inherent in complexity. Over time your appreciation for simplicity increases and you get a better sense of tradeoffs and long term costs.
Back in the 90s I wrote my high school's first website. We even got a scan of a picture of the school done in way too high resolution. It was a massive pain to get running, given my buddy and I were in our mid teens and the web was moving fast. Everything was a bunch of different hand crafted pages of tags, served from a machine sitting in the school. But basically we figured out how to do it by reading one or two pages about it.
I left school and eventually did a lot of financial coding, which was mainly backend stuff plus a small amount of desktop GUIs, or very very basic web pages.
Not until a few years ago did I have another look at the web, and it had of course changed enormously. It seems nowadays everything is a tool that compiles into something else. There's a zillion frameworks in js, there's webassembly, there's a bunch of things that you use to build the CSS. The page itself seems to be a load of divs, many tags from the old days are archaic now, only seen on old university sites. Sites themselves are served from a datacenter, and not from one machine. Static content doesn't even need to come from the same place. Security and privacy is a thing. There's no one place to learn the whole thing, which I suppose is expected.