10 ms·

The simple page you could make 20 years ago is the simple page you can make today. With a few minor tweaks, it will work as well as it did 20 years ago. If you

by kgin 5y ago

The simple page you could make 20 years ago is the simple page you can make today. With a few minor tweaks, it will work as well as it did 20 years ago. If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. If for some reason you decide to use the tools meant for complex web apps to make your simple page, you're going to feel like everything has gone horribly wrong. But why are you doing that?

rossdavidh 5y ago
Amen. If a static web page does what you need, one should not be unwilling to just make a static web page.
- amelius 5y ago
  One tiny little extra requirement from the client could make you regret that. Clients don't care about what tools you use. They care more about flexibility.
taeric 5y ago
I don't know if I really agree. I want to. But flash was supported by much better tooling than what I see in most spots today. Dreamweaver, for all the hate we have it, seems laughable simple compared to common frameworks today.
- danShumway 5y ago
  You can still use your old copy of Dreamweaver if you really want to. I think Adobe still sells new versions too. I wouldn't advise using website builders in general (Dreamweaver was always kind of sketch), and I certainly wouldn't advise using Adobe software in general (they're an awful company with overpriced products), but I can't imagine modern Dreamweaver has gotten particularly worse than it was before. You can't use Flash, that's fair. But my goodness, you wouldn't want to. The small amount of incidental complexity we've gained from forcing pizza shops to stop laying out their interface in Flash is worth it. And outside of the plugins that were absolutely the correct decision to remove, everything else you want to use is still available. What we're getting at is that with a few exceptions (HTTPS, Java plugins, Flash), virtually all of the old APIs that you used to use on the web are still supported and are the exact same to use, if not better. This is not the case everywhere with every language and platform. But the web has done a reasonably good job at being backwards compatible. You're worried about deploy processes, and you want to deploy a free site on Netlify? You don't need to learn Git, you can hand-code your site in static HTML or generate it using any program you want and just upload it as a zipped folder. Your Dreamweaver builds will still run today. Font faces? Still work, you don't need to worry about FOUT. You miss table layouts? Hackernews is using that crud right now. The complexity around build tools, processes, and frameworks is all optional. The browser doesn't care. If you're missing the old experience of building websites, then just do that. I maintain https://anewdigitalmanifesto.com https://anewdigitalmanifesto.com. It is hand-coded HTML that I wrote in a text editor. It has no Javascript, no build process, no minification, nothing. And it works fine; no one has ever complained about it to me. If you're adding complexity to your engineering process and it's making your job harder instead of easier, then take a step back and ask yourself why you're adding that complexity in the first place. Is it solving a problem? Or do you just feel like you need to do things "properly" based on the current development style? Because again, the browser doesn't care.
  - watwut 5y ago
    Oh, you would want to use it. The games and similar mini software just don't have anything comparable to it. The loss of flash is very unfortunate.
    - galangalalgol 5y ago
      The Ruffle project is trying to make a flash player with wasm. Mayne that at least can return.
    - danShumway 5y ago
      I loved Flash, deeply, I learned to program in Flash. But I am slowly in the process of doing a 180 on this, where before I felt like we had lost something with Flash that nobody had ever replicated. People have different things they liked about Flash. I liked the animation-centered workflow (and I still think there's room for innovation in this space with modern tools). I miss the ability to export vector animations. There's a technical hole that I still think could be filled by other programs today. But often, I hear people lamenting the loss of community and the loss of universal publishing. And on that note, aside from the animation-centered workflow, I'm less certain that the rest of that stuff is actually gone. Unity publishes to websites just as well as Flash did, if not better. Unity even lets you publish to Linux, which Flash never really supported well. And honestly, I'm not sure the community is dead either, it's just moved on to platforms like Scratch, Pico 8, Itch.io, and Roblox. I see very similar energies when I interact with people on those platforms. It's a different community, it's younger kids with different norms, the old generation isn't as welcome anymore. But I'm not sure the reason for that is because Flash died. Sometimes generations grow up and younger generations go act creative in different spaces. So yes, there is a very specific workflow for a very specific type of game that no longer works on the web. I've used Unity, and I don't really like Unity, I hate it's resource management, I hate that we're still using proprietary software after so many years. But I think more people are making games with Unity today than were making them back then on Flash. It's more accessible. I'm very, very slowly changing my opinion on this. Part of it is that Flash is still available today under Animate, and while it is still chained to Adobe I've still never heard a really good breakdown of how it's worse or what features it doesn't support anymore. As far as I can tell, you can still use Actionscript 3.0 with Animate. It is proprietary and expensive, but so was Flash -- so if it's purely a technical problem, then I'm not 100% sure that you couldn't still make a Flash website/game today. I still think there's a hole here that could be better served by Open Source toolchains, but I'm becoming less convinced that it is as big of a deal as I previously thought. If you're trying to make games, now is a really good time to be alive. It could be better, but if you give me the option of making games in 1999 or making games today, I'm not going back to 1999. And aside from that, even if Flash is a hole, it's still very specifically a hole for games. Even during its heyday, building static websites in Flash was a sin. Almost everything else you want to use to build a static website is still available. Just not that specific sinful part :)
Jaygles 5y ago
Because sometimes you want to learn the fancy tools but only need to make something simple. When the time comes to make the complex web app, you are now more prepared.
- astrowilliam 5y ago
  Learning fancy tools is outside the scope of building a simple website. Simple site is usually HTML/CSS/JS.
  - tomc1985 5y ago
    But... so are the complicated sites, once you've reduced it to its essence. Everything else are (excessive, complicated, arguably unnecessary) abstractions on top of that
- runawaybottle 5y ago
  This attitude doesn’t have a ceiling. The same person compelled by that impulse also manages to use an unnecessary data structure that introduces complexity. I’ve seen todo-app-like functionality done with serious data structures that made the code needlessly complex. Why am I here bitching all the time? Because I don’t have it in me to fight someone at work. The underlying tension can be reduced to me saying ‘you know this is crazy right?’, followed with ‘you don’t get it because you are not a real programmer’, and alas, those are both fighting words from both sides.
tigershark 5y ago
20 years ago we were criticising the syntax in JSP and ASP pages that allowed to embed code inside an html template. Today it seems that you are crazy if you are not writing a JSX SPA embedding JavaScript inside a JSX template. We are doing “There and back again” for I don’t know how many times.. And believe me I kind of like React and JSX, but I liked also embedding my dirty code in HTML ages ago.
midrus 5y ago
I agree with you, but the problem, the big problem, is that you're looked down if you propose to use simpler tools. It is horribly difficult to not use these advanced tools for simpler problems. At work my team does just f**ng CRUD forms, and for doing this we have the most overcomplicated stack I've seen in my life. Go backend with React, Redux, Rxjs,custom.webpack craziness, and 32 tons of internal weird libraries no one would willingly use ever even if pointed with a gun. If I propose to just use Rails for this and be done with it, I'd be declared and heretic and expulsed from the frontend team.
- thirdlamp 5y ago
  Without knowing your situation, that sounds like job security to me. "If we go the simple route I'm obsolete"
  - runawaybottle 5y ago
    It’s not job security. It’s insecurity and peer pressure and identity validation usually with a sprinkling of adhd medication (surprise, we all know what that kind of code looks like) powering people through intense coding sessions where they over engineer things obsessively. I’m getting pretty sick of it myself.
  - midrus 5y ago
    I think it is just the opposite. In my particular situation at work, if we go the simple route (it's just a 2 step CRUD wizard, so that'd be Rails/django/etc) other 5 people might be redundant. We need a team of 5 people to mantain this project (and a few smaller ones) because of the architecture (SPA + Go microservices) and the tools (React, rxjs, redux, data loaders, graphql, typescript safe actions whatever, an in-house-built crazy i18n system, custom webpack, some 10s of other open source libraries, and some other 10s of internal custom libraries). It's crazy. Really crazy.
- gher-shyu3i 5y ago
  I echo this. Currently working on CRUD app in golang. What an absolute mess and much slower than using established technologies.
jrockway 5y ago
I'm not sure this is quite true. 99% of early 2000s websites can be made by an unskilled operator automatically, by using something like Squarespace or Wordpress. The other 1% are the hard projects -- desktop quality applications that need to run on 5 platforms and 3 Javascript engines. Most people that do frontend engineering are being paid to work on those hard problems, so the job is going to feel harder than it did 20 years ago. There is no money in the easy things; it's all been automated away. To some extent, the tooling does make things harder than it needs to be; it's converged to a very strange local maximum that's very far away from the global maximum. The problem, I think, is a complete lack of integration along the entire stack. You write your code in a programming language whose source code is sent to the user to compile, and there are hundreds of minor variants on how the user will interpret that code. You have to defensively handle it all. But, developers want to reuse code, and those runtimes don't really support code reuse, so you have to bolt it on with a fake "compile" stage, where you concatenate all your dependencies together and split it up into chunks to be served to the end user's compiler at just the right time. The language that is used for these tools is a little on the outdated side, so this compile stage takes 30 seconds on one CPU core, leaving your commodity-grade 32 core workstation 96% idle while you sit around waiting. And, people don't even like this language for writing their code, so they write it in a different language that is compiled to that first language. After all that, you have code that can run on users' machines, but that's only like 30% of the problem. You have to serve that code to them, preferably from a datacenter that's physically close to their terminal. You have to serve them ancillary assets, like instructions for how to format the data your app interacts with, and images. Like the author mentions, there are a million different image formats, and you have to pick the right one for the end user, relying on a single line of text like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36". That's hard, so there is some service you can buy to do that for you, completely unrelated to that aforementioned "build process". The TL;DR is that there are hacks on top of hacks, and moving parts on top of moving parts, that it's a wonder it works at all. But we're in this state where we can't even fix it, because there is no one party responsible for the end-to-end experience. All you can do is bolt on more and more components and hope that you get closer to a local maximum. The takeaway is that in a distributed system of glued-together components, no one entity is responsible for the success of your users. And, those that manage to build success for their users will do it all through very careful glue, that can come apart and blow up at any time. That means they have a never-ending job that consists only of unnecessary toil. At some point, the person that decides "FUCK IT" and throws this all away and builds some sort of integrated experience is going to make a lot of money. But there are many lifetimes of work ahead to achieve this goal, and you'll be dead before you finish, so why even try? That's where we are. Good luck.
1vuio0pswjnm7 5y ago
As an end user, I use "tools" from 20 or more years ago to retrieve and extract the needed information from today's "complex web apps". Networks and server software are so much faster today, "yesterday's" (smaller, simpler) software seems to work even better today.
austincheney 5y ago
> If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. That’s true if the web app is a SPA and uses React and doesn’t require much accessibility and uses Redux or doesn’t manage state and, and, and... Most web developers are limited to those conditions and most currently posted front end jobs are limited to those requirements. Technically what you said is subjectively correct but it depends on a lot of factors and constraints for the average developer.
- grishka 5y ago
  I'm able to make what people call a "web app", yet I honestly have no idea what React and Redux are, besides buzzwords, and what they are supposed to solve. But then there's also the problem of people relying on JavaScript at all for websites that would've been fine as a bunch of fully static HTML pages. It's as if these days you can't do software development without overengineering everything into oblivion.
  - pdimitar 5y ago
    You haven't at all responded to your parent comment whose premise was that many frontend devs cannot utilize the freedom that you are apparently enjoying. IMO it's not the topic here if JS should at all be used. You won't catch me arguing with that -- my answer is almost always "NO!". The topic was: "but can you make web pages like 20 years ago in the current frontend dev jobs market?" -- the answer that is "no" as well IMO.
  - austincheney 5y ago
    Yes, many things are deliberately over engineered and that is largely due to limited capabilities of a specific tool or technique.
  - ZephyrBlu 5y ago
    What do you classify as a web app? React and other frameworks help you manage the state of your UI without having to worry (As much) about efficiently re-rendering the UI. Redux and other state libraries help you manage the global state of your JS app so your entire app can easily access and update common data.
Jiejeing 5y ago
The difference is that now everybody wants complex web apps, a split backend/frontend, a SPA, PWA, done usingthe javascript framework of the week, etc… Yes, doing complex things has gotten easier, mostly due to the improved tooling, but the number of things developers are asked to solve (for no real reason other that "it is now doable") have skyrocketed.
HWR_14 5y ago
> If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. 20 years ago, you could make a complex web app in Java, ActiveX or Flash. (There were also more obscure options.) People would install a plugin for your app. Now, it all uses Javascript. There are a lot of advantages, but it's difficult for me to say the tooling there is infinitely better. I think a reasonable case could be made that the tooling is worse than any of the three I mentioned.
coldtea 5y ago
>The simple page you could make 20 years ago is the simple page you can make today. With a few minor tweaks, it will work as well as it did 20 years ago. Which doesn't address the concerns of the author though, because the key is not that you can make the same page in 2021 (sure you can), but that nobody will pay your for making it in 2021. Whereas if you knew how to make a pair of shoes in 1999, or to use a CS example, how to write good C in 1999, people would still pay you for the same knowledge... >If for some reason you decide to use the tools meant for complex web apps to make your simple page, you're going to feel like everything has gone horribly wrong. But why are you doing that? That's not the author's concern. His concern is that the fundamental technologies and best practices get thrown out every 5-8 years, and people in web frontend have to relearn tons of stuff and throw out hard-earned knowledge, plus add all kinds of stuff that was never a thing to stay afloat the current practices... One could chalk it up to "well, of course you need to read to stay ahead", but the complain goes beyond that, to the volatility of front-end concepts and practices that makes this far more demanding that most areas of development (see also the related "js fatigue").

by kgin 5y ago

rossdavidh 5y ago

Amen. If a static web page does what you need, one should not be unwilling to just make a static web page.

amelius 5y ago
One tiny little extra requirement from the client could make you regret that. Clients don't care about what tools you use. They care more about flexibility.

taeric 5y ago

I don't know if I really agree. I want to. But flash was supported by much better tooling than what I see in most spots today. Dreamweaver, for all the hate we have it, seems laughable simple compared to common frameworks today.

danShumway 5y ago
You can still use your old copy of Dreamweaver if you really want to. I think Adobe still sells new versions too. I wouldn't advise using website builders in general (Dreamweaver was always kind of sketch), and I certainly wouldn't advise using Adobe software in general (they're an awful company with overpriced products), but I can't imagine modern Dreamweaver has gotten particularly worse than it was before. You can't use Flash, that's fair. But my goodness, you wouldn't want to. The small amount of incidental complexity we've gained from forcing pizza shops to stop laying out their interface in Flash is worth it. And outside of the plugins that were absolutely the correct decision to remove, everything else you want to use is still available. What we're getting at is that with a few exceptions (HTTPS, Java plugins, Flash), virtually all of the old APIs that you used to use on the web are still supported and are the exact same to use, if not better. This is not the case everywhere with every language and platform. But the web has done a reasonably good job at being backwards compatible. You're worried about deploy processes, and you want to deploy a free site on Netlify? You don't need to learn Git, you can hand-code your site in static HTML or generate it using any program you want and just upload it as a zipped folder. Your Dreamweaver builds will still run today. Font faces? Still work, you don't need to worry about FOUT. You miss table layouts? Hackernews is using that crud right now. The complexity around build tools, processes, and frameworks is all optional. The browser doesn't care. If you're missing the old experience of building websites, then just do that. I maintain https://anewdigitalmanifesto.com https://anewdigitalmanifesto.com. It is hand-coded HTML that I wrote in a text editor. It has no Javascript, no build process, no minification, nothing. And it works fine; no one has ever complained about it to me. If you're adding complexity to your engineering process and it's making your job harder instead of easier, then take a step back and ask yourself why you're adding that complexity in the first place. Is it solving a problem? Or do you just feel like you need to do things "properly" based on the current development style? Because again, the browser doesn't care.
- watwut 5y ago
  Oh, you would want to use it. The games and similar mini software just don't have anything comparable to it. The loss of flash is very unfortunate.
  - galangalalgol 5y ago
    The Ruffle project is trying to make a flash player with wasm. Mayne that at least can return.
  - danShumway 5y ago
    I loved Flash, deeply, I learned to program in Flash. But I am slowly in the process of doing a 180 on this, where before I felt like we had lost something with Flash that nobody had ever replicated. People have different things they liked about Flash. I liked the animation-centered workflow (and I still think there's room for innovation in this space with modern tools). I miss the ability to export vector animations. There's a technical hole that I still think could be filled by other programs today. But often, I hear people lamenting the loss of community and the loss of universal publishing. And on that note, aside from the animation-centered workflow, I'm less certain that the rest of that stuff is actually gone. Unity publishes to websites just as well as Flash did, if not better. Unity even lets you publish to Linux, which Flash never really supported well. And honestly, I'm not sure the community is dead either, it's just moved on to platforms like Scratch, Pico 8, Itch.io, and Roblox. I see very similar energies when I interact with people on those platforms. It's a different community, it's younger kids with different norms, the old generation isn't as welcome anymore. But I'm not sure the reason for that is because Flash died. Sometimes generations grow up and younger generations go act creative in different spaces. So yes, there is a very specific workflow for a very specific type of game that no longer works on the web. I've used Unity, and I don't really like Unity, I hate it's resource management, I hate that we're still using proprietary software after so many years. But I think more people are making games with Unity today than were making them back then on Flash. It's more accessible. I'm very, very slowly changing my opinion on this. Part of it is that Flash is still available today under Animate, and while it is still chained to Adobe I've still never heard a really good breakdown of how it's worse or what features it doesn't support anymore. As far as I can tell, you can still use Actionscript 3.0 with Animate. It is proprietary and expensive, but so was Flash -- so if it's purely a technical problem, then I'm not 100% sure that you couldn't still make a Flash website/game today. I still think there's a hole here that could be better served by Open Source toolchains, but I'm becoming less convinced that it is as big of a deal as I previously thought. If you're trying to make games, now is a really good time to be alive. It could be better, but if you give me the option of making games in 1999 or making games today, I'm not going back to 1999. And aside from that, even if Flash is a hole, it's still very specifically a hole for games. Even during its heyday, building static websites in Flash was a sin. Almost everything else you want to use to build a static website is still available. Just not that specific sinful part :)

Jaygles 5y ago

Because sometimes you want to learn the fancy tools but only need to make something simple. When the time comes to make the complex web app, you are now more prepared.

astrowilliam 5y ago
Learning fancy tools is outside the scope of building a simple website. Simple site is usually HTML/CSS/JS.
- tomc1985 5y ago
  But... so are the complicated sites, once you've reduced it to its essence. Everything else are (excessive, complicated, arguably unnecessary) abstractions on top of that
runawaybottle 5y ago
This attitude doesn’t have a ceiling. The same person compelled by that impulse also manages to use an unnecessary data structure that introduces complexity. I’ve seen todo-app-like functionality done with serious data structures that made the code needlessly complex. Why am I here bitching all the time? Because I don’t have it in me to fight someone at work. The underlying tension can be reduced to me saying ‘you know this is crazy right?’, followed with ‘you don’t get it because you are not a real programmer’, and alas, those are both fighting words from both sides.

tigershark 5y ago

20 years ago we were criticising the syntax in JSP and ASP pages that allowed to embed code inside an html template. Today it seems that you are crazy if you are not writing a JSX SPA embedding JavaScript inside a JSX template. We are doing “There and back again” for I don’t know how many times.. And believe me I kind of like React and JSX, but I liked also embedding my dirty code in HTML ages ago.

midrus 5y ago

I agree with you, but the problem, the big problem, is that you're looked down if you propose to use simpler tools. It is horribly difficult to not use these advanced tools for simpler problems. At work my team does just f**ng CRUD forms, and for doing this we have the most overcomplicated stack I've seen in my life. Go backend with React, Redux, Rxjs,custom.webpack craziness, and 32 tons of internal weird libraries no one would willingly use ever even if pointed with a gun. If I propose to just use Rails for this and be done with it, I'd be declared and heretic and expulsed from the frontend team.

thirdlamp 5y ago
Without knowing your situation, that sounds like job security to me. "If we go the simple route I'm obsolete"
- runawaybottle 5y ago
  It’s not job security. It’s insecurity and peer pressure and identity validation usually with a sprinkling of adhd medication (surprise, we all know what that kind of code looks like) powering people through intense coding sessions where they over engineer things obsessively. I’m getting pretty sick of it myself.
- midrus 5y ago
  I think it is just the opposite. In my particular situation at work, if we go the simple route (it's just a 2 step CRUD wizard, so that'd be Rails/django/etc) other 5 people might be redundant. We need a team of 5 people to mantain this project (and a few smaller ones) because of the architecture (SPA + Go microservices) and the tools (React, rxjs, redux, data loaders, graphql, typescript safe actions whatever, an in-house-built crazy i18n system, custom webpack, some 10s of other open source libraries, and some other 10s of internal custom libraries). It's crazy. Really crazy.
gher-shyu3i 5y ago
I echo this. Currently working on CRUD app in golang. What an absolute mess and much slower than using established technologies.

jrockway 5y ago

I'm not sure this is quite true. 99% of early 2000s websites can be made by an unskilled operator automatically, by using something like Squarespace or Wordpress. The other 1% are the hard projects -- desktop quality applications that need to run on 5 platforms and 3 Javascript engines. Most people that do frontend engineering are being paid to work on those hard problems, so the job is going to feel harder than it did 20 years ago. There is no money in the easy things; it's all been automated away. To some extent, the tooling does make things harder than it needs to be; it's converged to a very strange local maximum that's very far away from the global maximum. The problem, I think, is a complete lack of integration along the entire stack. You write your code in a programming language whose source code is sent to the user to compile, and there are hundreds of minor variants on how the user will interpret that code. You have to defensively handle it all. But, developers want to reuse code, and those runtimes don't really support code reuse, so you have to bolt it on with a fake "compile" stage, where you concatenate all your dependencies together and split it up into chunks to be served to the end user's compiler at just the right time. The language that is used for these tools is a little on the outdated side, so this compile stage takes 30 seconds on one CPU core, leaving your commodity-grade 32 core workstation 96% idle while you sit around waiting. And, people don't even like this language for writing their code, so they write it in a different language that is compiled to that first language. After all that, you have code that can run on users' machines, but that's only like 30% of the problem. You have to serve that code to them, preferably from a datacenter that's physically close to their terminal. You have to serve them ancillary assets, like instructions for how to format the data your app interacts with, and images. Like the author mentions, there are a million different image formats, and you have to pick the right one for the end user, relying on a single line of text like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36". That's hard, so there is some service you can buy to do that for you, completely unrelated to that aforementioned "build process". The TL;DR is that there are hacks on top of hacks, and moving parts on top of moving parts, that it's a wonder it works at all. But we're in this state where we can't even fix it, because there is no one party responsible for the end-to-end experience. All you can do is bolt on more and more components and hope that you get closer to a local maximum. The takeaway is that in a distributed system of glued-together components, no one entity is responsible for the success of your users. And, those that manage to build success for their users will do it all through very careful glue, that can come apart and blow up at any time. That means they have a never-ending job that consists only of unnecessary toil. At some point, the person that decides "FUCK IT" and throws this all away and builds some sort of integrated experience is going to make a lot of money. But there are many lifetimes of work ahead to achieve this goal, and you'll be dead before you finish, so why even try? That's where we are. Good luck.

1vuio0pswjnm7 5y ago

As an end user, I use "tools" from 20 or more years ago to retrieve and extract the needed information from today's "complex web apps". Networks and server software are so much faster today, "yesterday's" (smaller, simpler) software seems to work even better today.

austincheney 5y ago

> If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. That’s true if the web app is a SPA and uses React and doesn’t require much accessibility and uses Redux or doesn’t manage state and, and, and... Most web developers are limited to those conditions and most currently posted front end jobs are limited to those requirements. Technically what you said is subjectively correct but it depends on a lot of factors and constraints for the average developer.

grishka 5y ago
I'm able to make what people call a "web app", yet I honestly have no idea what React and Redux are, besides buzzwords, and what they are supposed to solve. But then there's also the problem of people relying on JavaScript at all for websites that would've been fine as a bunch of fully static HTML pages. It's as if these days you can't do software development without overengineering everything into oblivion.
- pdimitar 5y ago
  You haven't at all responded to your parent comment whose premise was that many frontend devs cannot utilize the freedom that you are apparently enjoying. IMO it's not the topic here if JS should at all be used. You won't catch me arguing with that -- my answer is almost always "NO!". The topic was: "but can you make web pages like 20 years ago in the current frontend dev jobs market?" -- the answer that is "no" as well IMO.
- austincheney 5y ago
  Yes, many things are deliberately over engineered and that is largely due to limited capabilities of a specific tool or technique.
- ZephyrBlu 5y ago
  What do you classify as a web app? React and other frameworks help you manage the state of your UI without having to worry (As much) about efficiently re-rendering the UI. Redux and other state libraries help you manage the global state of your JS app so your entire app can easily access and update common data.

Jiejeing 5y ago

The difference is that now everybody wants complex web apps, a split backend/frontend, a SPA, PWA, done usingthe javascript framework of the week, etc… Yes, doing complex things has gotten easier, mostly due to the improved tooling, but the number of things developers are asked to solve (for no real reason other that "it is now doable") have skyrocketed.

HWR_14 5y ago

> If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. 20 years ago, you could make a complex web app in Java, ActiveX or Flash. (There were also more obscure options.) People would install a plugin for your app. Now, it all uses Javascript. There are a lot of advantages, but it's difficult for me to say the tooling there is infinitely better. I think a reasonable case could be made that the tooling is worse than any of the three I mentioned.

coldtea 5y ago

>The simple page you could make 20 years ago is the simple page you can make today. With a few minor tweaks, it will work as well as it did 20 years ago. Which doesn't address the concerns of the author though, because the key is not that you can make the same page in 2021 (sure you can), but that nobody will pay your for making it in 2021. Whereas if you knew how to make a pair of shoes in 1999, or to use a CS example, how to write good C in 1999, people would still pay you for the same knowledge... >If for some reason you decide to use the tools meant for complex web apps to make your simple page, you're going to feel like everything has gone horribly wrong. But why are you doing that? That's not the author's concern. His concern is that the fundamental technologies and best practices get thrown out every 5-8 years, and people in web frontend have to relearn tons of stuff and throw out hard-earned knowledge, plus add all kinds of stuff that was never a thing to stay afloat the current practices... One could chalk it up to "well, of course you need to read to stay ahead", but the complain goes beyond that, to the volatility of front-end concepts and practices that makes this far more demanding that most areas of development (see also the related "js fatigue").