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?
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.
I’m getting pretty sick of it myself.
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.
Look, I love node and javascript. But I can't deny it is is total mistake to use it in a business context for web dev when you have django, rails or Laravel. Same for Go and many other trendy tools.... Reinventing the well is not a good business unless you're in the wheels business.
I blame the industry who fell for golang's marketing and started shoving golang into places where it doesn't belong.
But people learn it, get hyped, and want to use it for everything.
So now we're spending months doing things that already exist in popular frameworks.
Go is not for web development.You're not Google.
CLI app perhaps, and some simple use case here and there. Databases and infrastructure services need more expressive languages.
I agree with you otherwise.
By infrastructure services I mean things as DNS servers, network queues, etc.
Yes I understand :) golang is still a terrible language for them though. Rust, Java, and C# are strictly superior alternatives.
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").
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. 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.
The loss of flash is very unfortunate.
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 :)
The ease of creating something is just not there in general. The current tools are harder to use for beginner and beginner achieves less with more effort.
And open source have bad track record in terms of creating user beginner friendly tools.
And you can validly complain about the technical quality of tools like Scratch, but as much I personally hate to admit it, Scratch is more user friendly than Flash was. I personally know kids who are making stuff in Scratch that would not be able to handle Flash. It's extremely crude stuff, Scratch is ridiculously limited. But they're still making stuff and sharing it, and getting their friends involved in the process, and sharing hacks with each other to get around its limitations, and finding other projects that impress them and reading their source code.
I do get what you mean about Flash's technical side that made it interesting. I miss an animation-first workflow, I wish someone else would build a tool that experimented with that. There is definitely a hole in my game-dev process that Flash left behind. But in theory, you could still be using Animate today and exporting your games to HTML5. Nobody has explained to me what's broken about it.
But if everyone in the old Newgrounds scene moved to Animate, or if it was magically released for free tomorrow, would that bring back the community? I'm not sure it's that simple.
I don't think that kids stopped being creative when Flash went away. I think that people (myself included) who grew up on Flash got older, and the spaces are different now and we're not being invited to them. Which... I don't know if that's really a technological thing, or even necessarily a problem that needs to be solved. Were there really a ton of 35-40 year olds making stuff on Newgrounds back in the day? I am increasingly learning about community spaces from the kids I know that I would never stumble on by myself on the Internet. And they seem to be pretty vibrant, they're just not my spaces anymore.
This is more than just games. Basic form based workflows peaked with vba and access. Early 2000's dream of components that you could drag in and then wire up to the side seem to be gone.
Now, in fairness, I lauded their death, to an extent. Jsx is a step up when you don't have a designer you are working with. Css, as a concept, is basically void of you aren't collaborating with users on how to style things.
And I agree that the devops has improved. Within reason. Some things are easier, but that ease brought in a sort of Jevon's paradox where, since it became easier to ship more and more, we now ship way more and more. But, are we delivering more?
And I think that is hard to answer. I think the truth is we are hitting more and more of the tail. Which is good. But individually, nobody takes up now and more of the tail, so it is hard to see.
(Granted, I suspect accessibility is losing to this race. :( Basic affordances that you got with fieldsets, labels, and basic html are commonly a second thought on so many custom components.)
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.
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.
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.
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.
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.
Clients don't care about what tools you use. They care more about flexibility.
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.
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.
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.