Ask HN: Getting tired of complexity in web development
286 comments
I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for.
The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you try mobile app development, let me know, I've never tried but I doubt it's exempt.
Why does this happen? No idea, but it's not lost on me that a lot of these things are backed by huge companies with giant piles of money who are using them as marketing.
The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity. What are we going to build? What tools make sense for it?
The problem I'm running into is a lot of people expect to use React in the same way many of us once relied on jquery. So if that's the case and we must use some React, what can I do to use it in the simplest and clearest way possible?
The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you try mobile app development, let me know, I've never tried but I doubt it's exempt.
Why does this happen? No idea, but it's not lost on me that a lot of these things are backed by huge companies with giant piles of money who are using them as marketing.
The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity. What are we going to build? What tools make sense for it?
The problem I'm running into is a lot of people expect to use React in the same way many of us once relied on jquery. So if that's the case and we must use some React, what can I do to use it in the simplest and clearest way possible?
Speaking of ops.
What is the simplest reproducible way to accomplish this task.
- create vm instance ( setup firewall, users, network dna, stuff) - install : apache, runtime - install app.
- create vm instance ( setup firewall, users, network dna, stuff) - install : apache, runtime - install app.
Set it up once. Snapshot an image (called an AMI on AWS, but applies on all cloud services). Use the image to make new identical instances.
You can also script the process with (for example) Terraform.
You can also script the process with (for example) Terraform.
Nearly every company I've ever worked for could get away with only using:
- packer for images
- terraform for prod infra
- vagrant for local dev
- pssh for ci/cd and config management
And in some cases I would say they'd be far more efficient with this setup.
- packer for images
- terraform for prod infra
- vagrant for local dev
- pssh for ci/cd and config management
And in some cases I would say they'd be far more efficient with this setup.
Heroku or alternatives
create - terraform,
install / manage - cfengine / ansible / chef
A single ansible yaml
All the responses you got so far suggest exactly what this "Ask HN" actually wants to avoid: Terraform, AMI, Packer, Ansible, Chef ..., the list goes on
Here is my suggestion for keeping it simple, by solely relying on skills you will need anyways: git and shell scripting.
- Write a shell script that executes all those commands you would run manually to set up your system.
- Put up a git repository in the `/` directory, `.gitignore` everything by default, and explicitly git-notignore all those configuration files and user files/maintenance scripts which are relevant for your environment. Use githooks to also track/restore file permissions and ownerships of these tracked files.
Here is my suggestion for keeping it simple, by solely relying on skills you will need anyways: git and shell scripting.
- Write a shell script that executes all those commands you would run manually to set up your system.
- Put up a git repository in the `/` directory, `.gitignore` everything by default, and explicitly git-notignore all those configuration files and user files/maintenance scripts which are relevant for your environment. Use githooks to also track/restore file permissions and ownerships of these tracked files.
Either the snapshot route to have a base image you can then run a single script to install the app. Or use something like Ansible to have reproducible configuration.
Honestly I use bash for this. I keep a local repo of .deb/.tar.gz files and scp them onto a machine which makes them reproducible. I use uvt-kvm for VMs, config files to cover basic settings, and that's basically it. I run a fairly decent sized test lab with multiple servers that have to be reproducible, quick to edit, and install fairly complex toolchains.
You launch the instance with "aws" CLI, passing it a user-data script (cloud config) that does all the things you describe with simple shell scripts. You install the app by copying it from an S3 location (build output), which is also defined in the script.
If you later want to port this into terraform, you can.
If you later want to port this into terraform, you can.
There is already many answers to your question and not to be rude, but I think it perfectly shows part of the problem OP is talking about.
Every single answer goes straight to name dropping various specific techs/tools and I don’t doubt it really is the most simple way for each poster. But I think a much better answer, would be a bunch of questions that dig into what kind of problem you are trying to solve, what are the circumstances, skillset, limitations, budget, is it 1 tiny private app for fun or a couple of apps your team or even company depends on etc.
Because it depends on the specifics in _your_ situation and jumping straight to _a_ solution, without understanding _your_ problem, is imho part of the over-complexity-problem in our industry.
Every single answer goes straight to name dropping various specific techs/tools and I don’t doubt it really is the most simple way for each poster. But I think a much better answer, would be a bunch of questions that dig into what kind of problem you are trying to solve, what are the circumstances, skillset, limitations, budget, is it 1 tiny private app for fun or a couple of apps your team or even company depends on etc.
Because it depends on the specifics in _your_ situation and jumping straight to _a_ solution, without understanding _your_ problem, is imho part of the over-complexity-problem in our industry.
> Why does this happen?
We humans are creative creatures. When we are doing the same thing for a long time, we tend to get bored and make change happen. We 'improve' things, we move things about. We 'make things better'. So we are not bored anymore.
We humans are creative creatures. When we are doing the same thing for a long time, we tend to get bored and make change happen. We 'improve' things, we move things about. We 'make things better'. So we are not bored anymore.
except nothing was improved. Just changed.
| Why does this happen?
Because nobody wants to hear "that feature isn't viable given our architecture."
So we build systems that can accommodate any possible future feature. No matter how unlikely. And no matter how much extraneous complexity it adds now.
In order to maintain simplicity you have to enforce simplicity. And tech business culture doesn't like that.
Because nobody wants to hear "that feature isn't viable given our architecture."
So we build systems that can accommodate any possible future feature. No matter how unlikely. And no matter how much extraneous complexity it adds now.
In order to maintain simplicity you have to enforce simplicity. And tech business culture doesn't like that.
> Why does this happen?
It happens because these technologies solve real problem for some subset of their users. Usually when people are saying that technology has become too complicated, it's because they happen to be looking from a perspective where the problems that the technology solves are invisible to them. That doesn't mean that the problem isn't important - it just means the problem isn't important for them. The easiest way to motivate this is to imagine the kinds of problems that need solving at large companies with thousands of employees. They look vastly different than the problems of someone like me working on a side project by myself.
e.g., TypeScript might not be useful for some single-person teams of developers. It's quite useful for teams of around 5, and it's unthinkable to work without it in teams of 100+. Does this mean that the single-developer team is wrong?
(I'd actually say the same thing about React. If you're a one-man team, go ahead, do whatever you want. But if you're working with 100 other engineers, god help you if you're all directly manipulating the DOM with vanilla JS.)
Most "complex" technology is solving many problems for many different smallish subsets of its users at the same time. To the average bystander, it can look like the technology has gained huge amounts of unnecessary complexity, but it hasn't, not really - it's just complexity which isn't directly relevant to you.
(OK, and yes, some other technology is just needlessly stupid, but...)
It happens because these technologies solve real problem for some subset of their users. Usually when people are saying that technology has become too complicated, it's because they happen to be looking from a perspective where the problems that the technology solves are invisible to them. That doesn't mean that the problem isn't important - it just means the problem isn't important for them. The easiest way to motivate this is to imagine the kinds of problems that need solving at large companies with thousands of employees. They look vastly different than the problems of someone like me working on a side project by myself.
e.g., TypeScript might not be useful for some single-person teams of developers. It's quite useful for teams of around 5, and it's unthinkable to work without it in teams of 100+. Does this mean that the single-developer team is wrong?
(I'd actually say the same thing about React. If you're a one-man team, go ahead, do whatever you want. But if you're working with 100 other engineers, god help you if you're all directly manipulating the DOM with vanilla JS.)
Most "complex" technology is solving many problems for many different smallish subsets of its users at the same time. To the average bystander, it can look like the technology has gained huge amounts of unnecessary complexity, but it hasn't, not really - it's just complexity which isn't directly relevant to you.
(OK, and yes, some other technology is just needlessly stupid, but...)
My sense is that is wrong. Case in point, I deal with a group that has a relatively elaborate set of excel workbooks to manage their process. None of the workbooks are great, all of them created and maintained by different teams, and there is persistent discussion of needing to accrue tools or some guy even threw together his own MS Access db to substitute for the workbooks. What they do is not at all beyond what Excel could handle, but it is the lack of fundamental process and methods to design a proper system that is the code and fundamentally problem.
I feel that is frequently the issue, fragmentation and derivation caused by a lack of fundamental first principles thinking, willingness to tackle the issue from the ground up. The outcome is then talk of bolting on yet another tool or some fix that really only ads debt.
I feel that is frequently the issue, fragmentation and derivation caused by a lack of fundamental first principles thinking, willingness to tackle the issue from the ground up. The outcome is then talk of bolting on yet another tool or some fix that really only ads debt.
Right. React can be the correct tool for some problems, but if your problem is your team is not thinking big-picture enough to address maintainability, React is not going to magically make that better.
Honestly, I don't think it's even that bad for basic development (they literally have a CLI command that generates a very basic webapp immediately.)
Honestly, I don't think it's even that bad for basic development (they literally have a CLI command that generates a very basic webapp immediately.)
Typescript is basically required to keep you from shooting yourself in the foot with Javascript.
Type annotation also serves as a form of 'hard' documentation. If it's wrong or no longer correct, it will make things turn orange in your IDE and make your type linting tool go bonkers. Even as a single developer this has tremendous benefits. It's much easier to come back to something you wrote months/years ago and get back into it rather than having to go through each function to see what it returns under every situation.
Type annotation also serves as a form of 'hard' documentation. If it's wrong or no longer correct, it will make things turn orange in your IDE and make your type linting tool go bonkers. Even as a single developer this has tremendous benefits. It's much easier to come back to something you wrote months/years ago and get back into it rather than having to go through each function to see what it returns under every situation.
I agree with the sentiment so this comment is more of a nitpick than anything constructive, but I do feel you may have missed the mark with the typescript example.
Even if you don't want to use TS in it's full glory, you can just rename your files with a `.ts`, turn strict mode off, run everything through the compilation step, and weed out a category of simple mistakes from that alone. Add in that you can slowly add in certain rules to reach a level of strictness as you need and I see no reason how a JS dev would be better off writing vanilla JS than at least using TS and only running the compile step. Of course, I think taking the time to learn and fully utilize typescript the best path forward, even those with absolutely no desire to learn it can utilize some of it's strengths by reading the docs for 15 minutes.
Far from an unnecessary complexity, it's because an incredibly helpful tool at all levels.
Even if you don't want to use TS in it's full glory, you can just rename your files with a `.ts`, turn strict mode off, run everything through the compilation step, and weed out a category of simple mistakes from that alone. Add in that you can slowly add in certain rules to reach a level of strictness as you need and I see no reason how a JS dev would be better off writing vanilla JS than at least using TS and only running the compile step. Of course, I think taking the time to learn and fully utilize typescript the best path forward, even those with absolutely no desire to learn it can utilize some of it's strengths by reading the docs for 15 minutes.
Far from an unnecessary complexity, it's because an incredibly helpful tool at all levels.
I’m an enormous typescript proponent - I use it every day, even for the smallest, most trivial things :) in OP I was intending to steelman the anti-TS argument, but maybe I took it too far!
I'm a big TS fan, but for that type of person I feel like JSDoc + checkjs would suit them better. That way they don't have to deal with the hassle of making TS work with the rest of their tolling and build process.
Basically, it's the problem with vaccines and the rise of antivaxxers.
Because vaccines were so successful in their harm reduction to even elimination, there h
created a perverse belief that vaccines
were not effective, and then that they were actually harmful. Being ubiquitous and their effects the same, and the absence of their necessary disease.
Tools that solve problems experience a lifecycle that eventually if successful get weilded by people who never had firsthand experience of the problem.
Really a very large fractal problem space.
We envision a similar problem in autopilot system with 'safety' fall backs. For now, autopilots can disengage and let a pilot take control, but soon, we will run out of qualified pilots to disengage to, and no secure safety procedure.
Because vaccines were so successful in their harm reduction to even elimination, there h
created a perverse belief that vaccines
were not effective, and then that they were actually harmful. Being ubiquitous and their effects the same, and the absence of their necessary disease.
Tools that solve problems experience a lifecycle that eventually if successful get weilded by people who never had firsthand experience of the problem.
Really a very large fractal problem space.
We envision a similar problem in autopilot system with 'safety' fall backs. For now, autopilots can disengage and let a pilot take control, but soon, we will run out of qualified pilots to disengage to, and no secure safety procedure.
Same goes for the Y2K problem: prodigious efforts went into solving the problem, which was mostly averted. But since "nothing happened", people started asking if the whole thing was overblown.
More on topic, web frameworks solve the following problems for me, which I guess are things now taken for granted:
1. Provide a standard API across all popular browswes by papering over subtle differences in JS- or rendering-engines. This is kess of an issue now worh the homogenization of browser engines
2. Provide components with out-of-the-box accessibility. For me, this alone is worth the price of admissions. YMMV if yiu don't care about your (potential) users who use assistive tech like screen-readers
3. Design systems, CSS frameworks and iconsets makw my webapps look much better than if I were to be left to my own devices. I'm no designer, but the added complexity is worth it to me (think internal tools, not public products with a design budget).
4. Job mobility and the ability to transfer knowledge from one employer to the next. When I put down "react" on my resume, the reader will know exactly what I mean (as opposed to "CorpWebVu revision 5". I am also able to get up to speed on a React codebase because I know the conventions. This also is worth the price of admission by itself.
More on topic, web frameworks solve the following problems for me, which I guess are things now taken for granted:
1. Provide a standard API across all popular browswes by papering over subtle differences in JS- or rendering-engines. This is kess of an issue now worh the homogenization of browser engines
2. Provide components with out-of-the-box accessibility. For me, this alone is worth the price of admissions. YMMV if yiu don't care about your (potential) users who use assistive tech like screen-readers
3. Design systems, CSS frameworks and iconsets makw my webapps look much better than if I were to be left to my own devices. I'm no designer, but the added complexity is worth it to me (think internal tools, not public products with a design budget).
4. Job mobility and the ability to transfer knowledge from one employer to the next. When I put down "react" on my resume, the reader will know exactly what I mean (as opposed to "CorpWebVu revision 5". I am also able to get up to speed on a React codebase because I know the conventions. This also is worth the price of admission by itself.
I was coming here to say that the term for a problem which when solved makes people question whether it was necessary after all is a "Wicked Problem"[1], only to then discover that that's not it at all. So now I'm stumped - what is the word for that?
[1] https://en.wikipedia.org/wiki/Wicked_problem
[1] https://en.wikipedia.org/wiki/Wicked_problem
> The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity. What are we going to build? What tools make sense for it?
I tried to do this at several companies and ended up feeling like a pariah. At the end of the day, engineers, especially younger ones, like to follow trends, "learn new things", pad their resumes, and build bespoke solutions. Trying to fight against this will only make you look like a troglodyte or a party pooper.
I tried to do this at several companies and ended up feeling like a pariah. At the end of the day, engineers, especially younger ones, like to follow trends, "learn new things", pad their resumes, and build bespoke solutions. Trying to fight against this will only make you look like a troglodyte or a party pooper.
I worked at a company long enough to go from young dev who wants to use shiny new tech (and is told no by party pooper experienced devs); to the party pooper experienced dev for a new group of young devs.
I know I'm right, as I'm now sure the devs telling me no were right, but I'll be pushed out same as they were.
Young blood is naive and cheap and plentiful so they will always have the momentum advantage. They're the ones that promise the moon to other departments and then stay up all night covering their tracks when they were wrong.
I know I'm right, as I'm now sure the devs telling me no were right, but I'll be pushed out same as they were.
Young blood is naive and cheap and plentiful so they will always have the momentum advantage. They're the ones that promise the moon to other departments and then stay up all night covering their tracks when they were wrong.
As a younger dev I see the opposite in my corner of the world. The senior developers spend countless hours debating the best design, engineering large architectures to bounce a handful of kilobytes of information around in the just right way to achieve architectural purity. Then they do greenfield development with old tech that is simultaneously somehow both old and barely used, as if to generate their own job security.
>Why does this happen?
A lot of people value more enhancing their résumé than solving problems
A lot of people value more enhancing their résumé than solving problems
>Why does this happen?
I wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some...
Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are:
(1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them
The knowledge that things are actually easy and straightforward means we actually need to do the creative part of the work--many people are not ready to face that knowledge.
I wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some...
Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are:
(1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them
The knowledge that things are actually easy and straightforward means we actually need to do the creative part of the work--many people are not ready to face that knowledge.
> (1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them
I…I…I am triggered by this.
So it’s as if, people such as myself are on the hunt for artificial positive feedback loops that are functionally beautified masks of procrastination. Fueled by, perhaps a subconscious lack of confidence, or a sense of ignorance. Something to that effect.
So now imagine an entire department, teams, organizations all suffering from this? This can explain a lot.
I…I…I am triggered by this.
So it’s as if, people such as myself are on the hunt for artificial positive feedback loops that are functionally beautified masks of procrastination. Fueled by, perhaps a subconscious lack of confidence, or a sense of ignorance. Something to that effect.
So now imagine an entire department, teams, organizations all suffering from this? This can explain a lot.
I wouldn't write these off entirely. One of their positive outcomes is that you get to switch. Switching is important so you don't get bored or fed up. Just don't take these things too seriously, and don't stick your newfound hype into everything. Let things breathe, sleep on them. For like a few months or years.
I appreciate this piece of insight. It’s helping me find a balance.
I am certainly guilty of those, but I would point to larger pressures at the team and org levels - continuing to do things "the old way" (regardless of how old, just "the way we have been doing them") means no budget for big new projects to "modernize" apps and systems, no chance for managers to put their stamp on things with big new projects, etc.
Based on this description, I should vary my playing of games.
Anyway, I find the usage of the term "game" to be quite odd. Why not "strategy?" I'm not sure I agree with the overall point, but enjoy how you've operationalized/categorized behavior in this way. There is value in that.
Anyway, I find the usage of the term "game" to be quite odd. Why not "strategy?" I'm not sure I agree with the overall point, but enjoy how you've operationalized/categorized behavior in this way. There is value in that.
I used the word game because game implies a sort of "formal structure" or "submission" to a set of rules and constraints. This kind of structure relieves us of the anxiety of choice. It's so powerful it can be euphoric, that's why people pay for others to dominate them . I think it's also why we get into drug habits and a lot of other vices that add structure to our lives.
It's fine in moderation but tackling ambiguity regularly makes magic happen.
It's fine in moderation but tackling ambiguity regularly makes magic happen.
> (1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them
This is exactly what I have been doing for so long (~2 years), I get hyped about a new project, delve into the "best" way of solving the problem and encounter 4-5 shiny new things, spend an unreal amount of time scaffolding and using new tech to create a base framework for whatever I am doing, and then when I actually have to solve the problem my productivity stagnates and I procrastinate more.
Even now I am conflicted/lost on what to do, this response is tbh a cry for help from people who have encountered something like this. Any insight would be great.
This is exactly what I have been doing for so long (~2 years), I get hyped about a new project, delve into the "best" way of solving the problem and encounter 4-5 shiny new things, spend an unreal amount of time scaffolding and using new tech to create a base framework for whatever I am doing, and then when I actually have to solve the problem my productivity stagnates and I procrastinate more.
Even now I am conflicted/lost on what to do, this response is tbh a cry for help from people who have encountered something like this. Any insight would be great.
Isn't this literally just self-sabotaging? :)
> Why does this happen?
A few answers already but let me add one: Complex technologies favour seniors who are capable of understanding the complexity, over juniors who might struggle more. And it's seniors who make the decisions on what technology to use, so I think it's "rational" if they (even subconsciously) make choices which benefit them. They don't want to get replaced by cheaper juniors.
A few answers already but let me add one: Complex technologies favour seniors who are capable of understanding the complexity, over juniors who might struggle more. And it's seniors who make the decisions on what technology to use, so I think it's "rational" if they (even subconsciously) make choices which benefit them. They don't want to get replaced by cheaper juniors.
I’ve observed the opposite - less experienced devs tend to want to use more complicated and extensive/invasive tech, without understanding if it’s appropriate or what its limitations are.
I concur. The best people often produce the simplest solutions. Or perhaps more accurately, they often produce solutions that correctly implement the essential complexity but with little accidental complexity added.
> Why does this happen? No idea, but it's not lost on me that a lot of these things are backed by huge companies with giant piles of money who are using them as marketing.
Your whole post is spot-on :)
My two cents on the answer to this question:
- New tools / frameworks / libraries / etc often position themselves as “solving” some perceived deficiency of the prior generation of that thing. So it can be attractive to want to move over to something that solves a pain point. (Whether it actually does, or whether it just replaces it with a new pain point is another thing…) Monolith to microservices is an example.
- At least for me, if I’m starting a new project (especially if it’s in a space I’m not that experienced in), it’s tempting to choose what looks to be the simplest choice, which could be for example a niche database technology suited for my exact need (even if in reality a regular SQL db would be just fine).
- Engineers like to play with new toys!
Your whole post is spot-on :)
My two cents on the answer to this question:
- New tools / frameworks / libraries / etc often position themselves as “solving” some perceived deficiency of the prior generation of that thing. So it can be attractive to want to move over to something that solves a pain point. (Whether it actually does, or whether it just replaces it with a new pain point is another thing…) Monolith to microservices is an example.
- At least for me, if I’m starting a new project (especially if it’s in a space I’m not that experienced in), it’s tempting to choose what looks to be the simplest choice, which could be for example a niche database technology suited for my exact need (even if in reality a regular SQL db would be just fine).
- Engineers like to play with new toys!
> The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity.
You can also learn to leave work at work. Keep your side projects simple, if you have any. And rest easy knowing that at work the efforts of one person, you, create enough maintenance work for two people; enjoy that job security.
You can also learn to leave work at work. Keep your side projects simple, if you have any. And rest easy knowing that at work the efforts of one person, you, create enough maintenance work for two people; enjoy that job security.
>Why does this happen?
I highly disagree with everyone else. This is the answer why:
Because there's no clear or definitive answer to What's best the "best" architecture or system for building these things. The entire industry is full of people making up stuff without anyone truly knowing anything.
For the shortest distance between two points we can calculate an answer. there's a definitive optimum. The question of what's the best web service is infinitely more complex. The inputs are huge in number and even the definition of "best" is complex and hard to define... So in short we essentially have no mathematical theory for software design and technology that can help us define what is "best." It's the same problem they have in Art and Design.
So nobody actually knows what is better BUT they think they know so they build wrappers around bad technology or they build completely new frameworks NONE of which actually provably move the needle forward. In fact the needle can move backwards and nobody knows!
When something can't be calculated, it's "Designed." This is the difference between "design" and calculation. Anything that's designed is basically some human wandering around in an area almost aimlessly without ever truly knowing what is optimum. They just use their gut and find some sort of answer that somewhat works. This is the current and past state of the programming industry. That is why on some intuitive level we can see that a lot of the industry looks like it's moving backwards.
Let's say we do have an equation that can take all the components that go into web application development and give you a numerical rating on how good it is. If we had such a model, my best guess is that if we took a system from the past and compared it to a system now, the Modern system will actually have a LOWER numerical rating.
But that's just my guess. As of now, nobody can truly define what that numerical rating represents and nobody knows whether some new framework or design methodology actually increases the amount of points. We are doomed forever to exist in this endless design loop until someone finds a mathematical model that can prove and layout the big picture from a quantitative perspective.
I highly disagree with everyone else. This is the answer why:
Because there's no clear or definitive answer to What's best the "best" architecture or system for building these things. The entire industry is full of people making up stuff without anyone truly knowing anything.
For the shortest distance between two points we can calculate an answer. there's a definitive optimum. The question of what's the best web service is infinitely more complex. The inputs are huge in number and even the definition of "best" is complex and hard to define... So in short we essentially have no mathematical theory for software design and technology that can help us define what is "best." It's the same problem they have in Art and Design.
So nobody actually knows what is better BUT they think they know so they build wrappers around bad technology or they build completely new frameworks NONE of which actually provably move the needle forward. In fact the needle can move backwards and nobody knows!
When something can't be calculated, it's "Designed." This is the difference between "design" and calculation. Anything that's designed is basically some human wandering around in an area almost aimlessly without ever truly knowing what is optimum. They just use their gut and find some sort of answer that somewhat works. This is the current and past state of the programming industry. That is why on some intuitive level we can see that a lot of the industry looks like it's moving backwards.
Let's say we do have an equation that can take all the components that go into web application development and give you a numerical rating on how good it is. If we had such a model, my best guess is that if we took a system from the past and compared it to a system now, the Modern system will actually have a LOWER numerical rating.
But that's just my guess. As of now, nobody can truly define what that numerical rating represents and nobody knows whether some new framework or design methodology actually increases the amount of points. We are doomed forever to exist in this endless design loop until someone finds a mathematical model that can prove and layout the big picture from a quantitative perspective.
I just still use jQuery or vanilla typescript when building frontends. To me it's so much more readable, and I almost never have to worry about newer code not playing well with older code. No client has ever even asked me what framework was being used. If the software works and the code is well documented, the fewer frameworks you use the better.
In scientific/academic environments (the only type I can speak of)
I have sometimes wondered if my fellow computerists have complexity envy.
What we need to do is not that complicated but making it so distracts from understanding the harder problem at hand while appearing to be working furiously.
What we need to do is not that complicated but making it so distracts from understanding the harder problem at hand while appearing to be working furiously.
This is basically the technical equivalent of bikeshedding, which has been known for a while. https://en.wikipedia.org/wiki/Law_of_triviality
It happens because everyone wants to imagine they're smart and just happen to work for a no name company.
The intelligence is in the end result of the engineering, but no one wants their work to be so simple it could have been done by a junior.
The intelligence is in the end result of the engineering, but no one wants their work to be so simple it could have been done by a junior.
> Why does this happen
I wrote up my hypothesis here: https://hasen.substack.com/i/52275953/why-the-situation-pers...
Basically, programmers love complexity.
If they can't solve real problems, they will create fake problems so they can solve them.
They might not realize that's what they're doing.
Programmers love solving puzzles. It's why they program. The problem arises when they can't solve the real puzzle due to lack of experience (and lack of skill which comes from lack of practice), they solve secondary and tertiary puzzles that contribute nothing to the real problem at hand.
Instead of "How can I write 1000 lines of code to solve this problem?" they opt for "how can I configure these 20 libraries and glue them together so that a solution to the problem emerges from their interaction?"
I wrote up my hypothesis here: https://hasen.substack.com/i/52275953/why-the-situation-pers...
Basically, programmers love complexity.
If they can't solve real problems, they will create fake problems so they can solve them.
They might not realize that's what they're doing.
Programmers love solving puzzles. It's why they program. The problem arises when they can't solve the real puzzle due to lack of experience (and lack of skill which comes from lack of practice), they solve secondary and tertiary puzzles that contribute nothing to the real problem at hand.
Instead of "How can I write 1000 lines of code to solve this problem?" they opt for "how can I configure these 20 libraries and glue them together so that a solution to the problem emerges from their interaction?"
I'm guilty.
> "How can I write 1000 lines of code to solve this problem?"
I opt for "Why are these libraries so complicated? I'll research all 20 libraries and take the parts I like and build a newer, simpler framework."
> "How can I write 1000 lines of code to solve this problem?"
I opt for "Why are these libraries so complicated? I'll research all 20 libraries and take the parts I like and build a newer, simpler framework."
I should also add that people who advocate for simplicity primarily do so because they want to solve bigger / more complicated problems, but the complexity level gets in their way.
People who don't see the existing solutions as overly complex are content to stay at their current level and have no vision of solving bigger more difficult problems. They think they are already working at or near the peak of human possibility.
People who don't see the existing solutions as overly complex are content to stay at their current level and have no vision of solving bigger more difficult problems. They think they are already working at or near the peak of human possibility.
> The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity.
This can seriously limit your earning potential by limiting your career advancement. You are forced to create complexity monsters for promotions at the type companies I've worked at.
This can seriously limit your earning potential by limiting your career advancement. You are forced to create complexity monsters for promotions at the type companies I've worked at.
>Why does this happen? No idea, but it's not lost on me that a lot of these things are backed by huge companies with giant piles of money who are using them as marketing.
1. New Tools, in the modern era means Promotion, VCs, Money, Prestige. personal branding.
2. Creating complexity, in the name of needs for these Big Tech is a great way to create a moat for themselves.
3. Ideology, web development is possibly the 2nd worst places if it wasn't for Rust evangelism strike force. The idea that every single god damn thing should be in Javascript or SPA.
4. The Act of design before coding is gone. Especially in the era of Web Development. Lead by Google and Facebook which later spread across Silicon Valley and later across the world. An Act which is even seen as evil or forbidden.
1. New Tools, in the modern era means Promotion, VCs, Money, Prestige. personal branding.
2. Creating complexity, in the name of needs for these Big Tech is a great way to create a moat for themselves.
3. Ideology, web development is possibly the 2nd worst places if it wasn't for Rust evangelism strike force. The idea that every single god damn thing should be in Javascript or SPA.
4. The Act of design before coding is gone. Especially in the era of Web Development. Lead by Google and Facebook which later spread across Silicon Valley and later across the world. An Act which is even seen as evil or forbidden.
> If you try mobile app development, let me know, I've never tried but I doubt it's exempt
It's just as bad. Different, but bad.
It's just as bad. Different, but bad.
> Why does this happen?
These teams lack technical leadership that is based on professional experience. This is the sort of lesson that is acquired after at least 10 if not more years of professional work, however the industry tests for algorithmic performance art on whiteboards to select software engineers.
These teams lack technical leadership that is based on professional experience. This is the sort of lesson that is acquired after at least 10 if not more years of professional work, however the industry tests for algorithmic performance art on whiteboards to select software engineers.
In addition to what the other commenter says about wanting to postpone the 'creative' aspect of the work, I'd also say this happens because of:
1. Boredom. Everyone wants to be doing interesting work, and doing the same thing that's been done a million times before is probably pretty dull. Devs don't want to feel like code monkeys piecing things together assembly line style, even if that's exactly what's needed for many sites, apps, etc.
2. CV/Resume padding. Perhaps many people see every job as a stepping stone to the next one, and hope a complex solution will get them hired at a FAANG company or fast growing startup in future.
3. Expectations. Problems at large tech companies like Google are more likely to be documented online, since the folks working there tend to have more of an online/social media/blog presence than the folks doing 9-5s at more traditional companies. So people think "hey, if this is how others are doing it, this must be the proper way to do it", ignoring the fact that it's the proper way for a company expecting X billion users a year rather than a more reasonable number.
4. Ego/online reputation. Saying you used a fancy framework and hosting setup with microservices for your project gets a lot more votes on Reddit and Hacker News than saying you used say, basic HTML and CSS.
5. Lack of training/learning opportunities at work. Companies tend not to give workers much of a chance to learn new tech or work on interesting projects in work hours, which would provide them a place to experiment with these new technologies. So they try and integrate it into their normal work instead, even if it's completely the wrong solution for the problem at hand.
1. Boredom. Everyone wants to be doing interesting work, and doing the same thing that's been done a million times before is probably pretty dull. Devs don't want to feel like code monkeys piecing things together assembly line style, even if that's exactly what's needed for many sites, apps, etc.
2. CV/Resume padding. Perhaps many people see every job as a stepping stone to the next one, and hope a complex solution will get them hired at a FAANG company or fast growing startup in future.
3. Expectations. Problems at large tech companies like Google are more likely to be documented online, since the folks working there tend to have more of an online/social media/blog presence than the folks doing 9-5s at more traditional companies. So people think "hey, if this is how others are doing it, this must be the proper way to do it", ignoring the fact that it's the proper way for a company expecting X billion users a year rather than a more reasonable number.
4. Ego/online reputation. Saying you used a fancy framework and hosting setup with microservices for your project gets a lot more votes on Reddit and Hacker News than saying you used say, basic HTML and CSS.
5. Lack of training/learning opportunities at work. Companies tend not to give workers much of a chance to learn new tech or work on interesting projects in work hours, which would provide them a place to experiment with these new technologies. So they try and integrate it into their normal work instead, even if it's completely the wrong solution for the problem at hand.
> relied on jquery. So if that's the case and we must use some React, what can I do to use it in the simplest and clearest way possible?
The answer to that question has been the same as long as I've been using react. Represent most of your app logic in pure functions. This has been the React team's recommendation, pretty much since the beginning.
Once you get hit to the idea of making everything a function, it pays to learn some functional programming design patterns. This increases your vocabulary for abstracting your application logic into a function.
Once almost everything lives in functions, your react components should really only care about managing the view.
The answer to that question has been the same as long as I've been using react. Represent most of your app logic in pure functions. This has been the React team's recommendation, pretty much since the beginning.
Once you get hit to the idea of making everything a function, it pays to learn some functional programming design patterns. This increases your vocabulary for abstracting your application logic into a function.
Once almost everything lives in functions, your react components should really only care about managing the view.
I feel your pain. My career happiness peaked around 2014 or 2015, when I was writing Rails monoliths. I felt like I could focus 100% of my energy on business logic since the framework was so opinionated and the stack was simple. Things went rapidly downhill after that, once microservices, SPAs, node.js, NoSQL, and serverless computing started becoming popular. Everything just felt like a step backward. Microservices made simple things (like transactions) impossible. Express felt like a degraded version of Sinatra. NoSQL, frankly, is utterly pointless, and I have no clue why it ever caught on. Serverless computing is interesting in some respects but the places that I've worked that have gone all in on AWS were total disasters. SPAs are definitely useful for rich, interactive front-ends, but the trend to make everything a SPA and render everything in JS is totally nuts.
I ended up switching to a PM role, where I can focus on the business problems without having to worry too much about the implementation. I do miss coding a bit, but it's not fun enough to do full time anymore.
I ended up switching to a PM role, where I can focus on the business problems without having to worry too much about the implementation. I do miss coding a bit, but it's not fun enough to do full time anymore.
I still work on a Django monolith and agree on being able to focus 100% on business logic. I've found Angular is excellent for "sprinkling" a little JS into the frontend where necessary rather than going the full SPA/React route.
How is Angular adding just a sprinkle of js to your web app? Isn't the ouput of building an Angular app a full SPA?
I am using the "original" angular-js, not the newer Angular whatever version it is now. It's not a full SPA. I just include angular.js and put the ng stuff in my HTML. Maybe the new Angular is different?
Yes, angular 2 (which means anything after angularJS) is a full on SPA just like react is.
I think stimulus is more like angularJS. But modern angular definitely isn’t.
I think stimulus is more like angularJS. But modern angular definitely isn’t.
I worked on multiple Django monolith projects in the past years where parts of it with heavy client-side logic were offloaded to tiny Vue.js applications injected into the html template.
If data requires reloads or manipulations a side restful api needs to be created along the main endpoint which renders html. But it's fairly straightforward with DRF and the enforced by default apps/models structure of Django.
Until a certain point I find this arrangement enjoyable to work with. Once it stops, it's clear as day that the page should be rewritten from scratch with rendering on client side.
If data requires reloads or manipulations a side restful api needs to be created along the main endpoint which renders html. But it's fairly straightforward with DRF and the enforced by default apps/models structure of Django.
Until a certain point I find this arrangement enjoyable to work with. Once it stops, it's clear as day that the page should be rewritten from scratch with rendering on client side.
Have you tried htmlx? It fits this gap quite nicely, it's lets you do AJAX with SSR.
And I think that’s why some stacks like Hotwired and Phoenix have decided to let the server handle a bunch of common JS use cases so that you don’t need some all of the frontend complexity like with React
Spot on. Rails just let you get shit done. All we needed was a Rails for Node.js.
https://mojojs.org/ might just do the trick?
Rails for Node.js is Next.js + Prisma
You have never used Rails, have you?
From the top of my head, you'll also need libraries for:
- Background jobs - Validation - Translations/i18n - CSRF and other common security considerations - Testing (and integration testing) tools - Logging - Email sending - File uploads (S3 storage, etc) - Websockets
And then write the glue code to make all of this work seamlessly, document it for others to understand how you made it work together, ensure there are no security holes and battle test it in production.
Saying that Next + Prisma "is Rails for Node" is like saying a moth is an airplane just because both can fly.
From the top of my head, you'll also need libraries for:
- Background jobs - Validation - Translations/i18n - CSRF and other common security considerations - Testing (and integration testing) tools - Logging - Email sending - File uploads (S3 storage, etc) - Websockets
And then write the glue code to make all of this work seamlessly, document it for others to understand how you made it work together, ensure there are no security holes and battle test it in production.
Saying that Next + Prisma "is Rails for Node" is like saying a moth is an airplane just because both can fly.
Well said. There are a million starter projects and examples each with a different mix of tools hooked up all in very different ways with tons of files and config. And lots of them with bugs or out of date.
The problem with the JS world is they can never coagulate around one solution. Everyone has this insatiable desire to roll their own. Next only works because it leaves out a bunch of stuff.
Instead of the examples/ directory they should build a plugin interface and roll out official integrations with lots of tools. This is the closest we would come to Rails.
The problem with the JS world is they can never coagulate around one solution. Everyone has this insatiable desire to roll their own. Next only works because it leaves out a bunch of stuff.
Instead of the examples/ directory they should build a plugin interface and roll out official integrations with lots of tools. This is the closest we would come to Rails.
I think a big part of this is because of the the popular teachers and bloggers/youtubers which are not more than undercover (and some not even undercover) marketers for companies or solutions promoting the use of their platforms.
So many "Look how easy it is to build a blog with Next.js/Remix/Nuxt.js/Whatever", and it is true. That's really easy and cool and has a really good DX and we all love it.
But in real life you need a ton more things to make things robust and secure. And when people start to patch together stuff to get, let's say, authorization or authentication, into their apps, is when things go wrong and you end up getting emails of "data breaches" from services you signed up to.
Had you used a battle proven full stack framework, 90% of the problems would have been solved in standard, well documented, secure and proven ways.
In the node ecosystem, the opportunities are right there. From what I've seen and tried, Adonis.js is the best thing that has happened in this regard. A real "full stack" framework following Laravel's ideas. It's opinionated, fully featured and well integrated as every feature works nicely with each other. And you're not handed over 40 decisions to make about the ORM, the templating system or how to do permissions. It's all there ready and documented. As with Laravel or Rails.
We just need to have people understand that there's a *very common* set of features every single non-trivial web application needs and that it makes no sense to rewrite it from scratch on every single project.
What scares me the most is all of those people saying that implementing all of this themselves or by tying together 10s of libraries every single time is easy. To me they just don't know what they're doing and what they're getting into.
So many "Look how easy it is to build a blog with Next.js/Remix/Nuxt.js/Whatever", and it is true. That's really easy and cool and has a really good DX and we all love it.
But in real life you need a ton more things to make things robust and secure. And when people start to patch together stuff to get, let's say, authorization or authentication, into their apps, is when things go wrong and you end up getting emails of "data breaches" from services you signed up to.
Had you used a battle proven full stack framework, 90% of the problems would have been solved in standard, well documented, secure and proven ways.
In the node ecosystem, the opportunities are right there. From what I've seen and tried, Adonis.js is the best thing that has happened in this regard. A real "full stack" framework following Laravel's ideas. It's opinionated, fully featured and well integrated as every feature works nicely with each other. And you're not handed over 40 decisions to make about the ORM, the templating system or how to do permissions. It's all there ready and documented. As with Laravel or Rails.
We just need to have people understand that there's a *very common* set of features every single non-trivial web application needs and that it makes no sense to rewrite it from scratch on every single project.
What scares me the most is all of those people saying that implementing all of this themselves or by tying together 10s of libraries every single time is easy. To me they just don't know what they're doing and what they're getting into.
Thanks for the pointer to
adonis.js. I have been playing with just nextjs and nextauth and getting those to play well is a bit of a headache (middleware doesn’t seem to work). I assume an all in one solution stuff has been tested together!
There is a Laravel for Node.js - https://adonisjs.com/
And Laravel is essentially Rails for PHP
+1 for Adonis. I've been using it for some time, together with unpoly + alpinejs and it's a real pleasure. I'm really productive with this stack. In fact, their docs site is built using these tools: https://github.com/adonisjs/docs.adonisjs.com/blob/develop/p...
>NoSQL, frankly, is utterly pointless, and I have no clue why it ever caught on.
It caught on because "feature factory" startups used simple frameworks to make an MVP and didn't know shit about RDBMS administration, optimization, or schema planning so when it was schema migration time it was time for things to start breaking. With NoSQL (specifically the "document store" types) you could just keep throwing shit in there whenever you needed it -- magic schema migration! And it was "Web Scale"©!
It caught on because "feature factory" startups used simple frameworks to make an MVP and didn't know shit about RDBMS administration, optimization, or schema planning so when it was schema migration time it was time for things to start breaking. With NoSQL (specifically the "document store" types) you could just keep throwing shit in there whenever you needed it -- magic schema migration! And it was "Web Scale"©!
I've been through projects that gave schema migrations and when there was any mistake or error during schema migrations it was a real big pain to rollback, fix and release. With mongodb this is gone, schemas are no more of an issue as long as you make sure to keep the models sane and the business logic of the fields up to date.
Schemaless means anything can come put of the DB, or be put onto it. It adds a lot of work to the app
developer to keep things validated and secure and there are more exceptions to handle. Definitely a trade off. Never had big issues migrating schema-ed databases.
Sorry, but when I see "Web Scale" or "MongoDB" I can't help but recall https://www.youtube.com/watch?v=b2F-DItXtZs
This resonates* heavily.
I moved to writing web-code for personal purposes only. Now, I specialize in other types of technical areas for paycheck purposes (C++, Git, PM support, computer HW maintenance and procurement, similar overly niche technical tasks, etc).
I moved to writing web-code for personal purposes only. Now, I specialize in other types of technical areas for paycheck purposes (C++, Git, PM support, computer HW maintenance and procurement, similar overly niche technical tasks, etc).
>I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore
I agree, but the only path forward is to change the specifications for HTML/CSS/JavaScript.
As an industry we need to accept that these technologies get used to build web pages as well as software and adjust. This will remove a ton of the tooling. I think there are 3 basic things we could do to solve this:
1. Add dynamic interpolation to the HTML spec. This stops every framework from having to invent it's own version of it. 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier. 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
But it's going to be a hard sell. I am slowly writing a blog post about this, but I'm not sure I will be able to get anybody to listen. I feel like now, when we're in a browser monoculture where the browser vendor is actually competent is the perfect time to push this stuff through.
BTW: You can put your email in at daniel.do to get emailed when I release my post.
I agree, but the only path forward is to change the specifications for HTML/CSS/JavaScript.
As an industry we need to accept that these technologies get used to build web pages as well as software and adjust. This will remove a ton of the tooling. I think there are 3 basic things we could do to solve this:
1. Add dynamic interpolation to the HTML spec. This stops every framework from having to invent it's own version of it. 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier. 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
But it's going to be a hard sell. I am slowly writing a blog post about this, but I'm not sure I will be able to get anybody to listen. I feel like now, when we're in a browser monoculture where the browser vendor is actually competent is the perfect time to push this stuff through.
BTW: You can put your email in at daniel.do to get emailed when I release my post.
Finally someone is saying it openly. The Web is amazing, the softwarestack powering is horrible.
Just imagine for a second we were to start from scratch. Imagine an HTML/CSS Spec thats easy enough to implement so that we have multiple independent vendors with competing, correct implementations. Imagine something like web assembly as the basis for scripting those HTML/CSS Engines. Imagine the amount of energy, developer time and bugs we could save with a sane, modern standard that implements all the lessons learned from what came before...
One can dream...
Just imagine for a second we were to start from scratch. Imagine an HTML/CSS Spec thats easy enough to implement so that we have multiple independent vendors with competing, correct implementations. Imagine something like web assembly as the basis for scripting those HTML/CSS Engines. Imagine the amount of energy, developer time and bugs we could save with a sane, modern standard that implements all the lessons learned from what came before...
One can dream...
I think what we need is a new spec that compiles down to whatever HTML/CSS/JS/WASM is supported by browsers over time. Waiting for browser vendors to agree on a new spec takes far too long.
The same thing happens in all of comp-sci: we create a new programming language that compiles to an old language (C to Assembly) because changing the old one takes longer than inventing a new one.
The same thing happens in all of comp-sci: we create a new programming language that compiles to an old language (C to Assembly) because changing the old one takes longer than inventing a new one.
Ultimately, that's what all these different frameworks actually are though. Look at how many different languages over the years have compiled down to JS? CoffeeScript, TypeScript, Elm. And all the frameworks that have smoothed over the native DOM API: React, Angular, JQuery, too many to list.
They all implement these concepts in Javascript. But if we don't standardize and allow browser vendors to implement at a lower level, we will always be taking a speed hit and on the framework treadmill. We need to take what we know works and do it.
They all implement these concepts in Javascript. But if we don't standardize and allow browser vendors to implement at a lower level, we will always be taking a speed hit and on the framework treadmill. We need to take what we know works and do it.
Sort of, but React is not a language. It's a runtime lib. JSX is not really helpful - still writing HTML and CSS.
TypeScript has been very useful and successful but it hasn't touched the UI stuff.
We need a better alternative to HTML and CSS. With WASM any language can now be compiled to run in the browser, and it's a matter of time until WASM integrates with the DOM as well.
This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.
TypeScript has been very useful and successful but it hasn't touched the UI stuff.
We need a better alternative to HTML and CSS. With WASM any language can now be compiled to run in the browser, and it's a matter of time until WASM integrates with the DOM as well.
This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.
>Sort of, but React is not a language. It's a runtime lib. JSX is not really helpful - still writing HTML and CSS. TypeScript has been very useful and successful but it hasn't touched the UI stuff.
That's my point. The main thing that JSX does is address that you can't do conditional rendering or interpolation with HTML. It's the same with literally all of these other templating languages. Blade, Jade, Handlebars, Mustache, the list goes on and on. Typescript literally exists to address a deficiency in JS.
I don't think reinventing the wheel is the answer - it should taking these clear improvements and adding them to the core product. A big part of why technologies become popular is because of how accessible they are to newer or less knowledgable developers. I don't think some new idea would work, we should work with what's already there. I don't think there's any fundamental flaw in HTML, CSS or JS that necessitates a complete replacement. Just adjustments.
HTML's purpose is to semantically describe content. I don't see how that is at odds with describing the user interface for software vs. a web page.
CSS can lay things out great. It used to be a pain, but flexbox/grids have made it easy now.
JS is the most popular language in the world. If we added a "types" mode that just adds the typescript syntax and lets you set a flag for it, it'd be even better. We don't need a new programming language for people to learn.
See, that's where we differ. I think HTML and CSS are great. They just need to be improved.
>This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.
Yeah, and if you look at the popularity of electron apps it's pretty clear that people prefer doing this stuff in HTML/CSS/JS, even with all the hacks than trying to learn platform specific stuff. I'm arguing with tweaks, we could do it AND have it be performant and not a pain in the ass.
That's my point. The main thing that JSX does is address that you can't do conditional rendering or interpolation with HTML. It's the same with literally all of these other templating languages. Blade, Jade, Handlebars, Mustache, the list goes on and on. Typescript literally exists to address a deficiency in JS.
I don't think reinventing the wheel is the answer - it should taking these clear improvements and adding them to the core product. A big part of why technologies become popular is because of how accessible they are to newer or less knowledgable developers. I don't think some new idea would work, we should work with what's already there. I don't think there's any fundamental flaw in HTML, CSS or JS that necessitates a complete replacement. Just adjustments.
HTML's purpose is to semantically describe content. I don't see how that is at odds with describing the user interface for software vs. a web page.
CSS can lay things out great. It used to be a pain, but flexbox/grids have made it easy now.
JS is the most popular language in the world. If we added a "types" mode that just adds the typescript syntax and lets you set a flag for it, it'd be even better. We don't need a new programming language for people to learn.
See, that's where we differ. I think HTML and CSS are great. They just need to be improved.
>This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.
Yeah, and if you look at the popularity of electron apps it's pretty clear that people prefer doing this stuff in HTML/CSS/JS, even with all the hacks than trying to learn platform specific stuff. I'm arguing with tweaks, we could do it AND have it be performant and not a pain in the ass.
HTML and CSS were not designed for building software. There's a reason it's nearly impossible to implement a web browser from scratch these days. The spec is an ancient monster. Adding more layout options to CSS doesn't simplify things, but only complicates. How many ways are there to layout stuff these days? Try explaining flexbox to a newbie.
HTML was meant for hyperlinked documents. It may be ok for that, but it's inappropriate for apps. Who cares about semantic meanings of DOM nodes in an app?
I don't think people prefer web dev to desktop dev, but really there's no choice if you need to support multiple OSes. Swift UI is a much more consistent development experience for example. Visual Basic was that for Windows. But cross platform? The only real target there is Skia.
HTML was meant for hyperlinked documents. It may be ok for that, but it's inappropriate for apps. Who cares about semantic meanings of DOM nodes in an app?
I don't think people prefer web dev to desktop dev, but really there's no choice if you need to support multiple OSes. Swift UI is a much more consistent development experience for example. Visual Basic was that for Windows. But cross platform? The only real target there is Skia.
Please write the blog post. It may be a hard sell but think of it more as a creative conversation with the future of web dev. While you may not get the final answer “correct”, your post will help the community progress a much needed discussion.
Number 3 is the ARIA spec right? You should be using that already if you’re writing accessible applications.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Here's what I don't understand about the ARIA spec - and maybe you can help clarify it for me. Why are we using attributes instead of element names?
Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.
Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.
Can you say more about why "it sucks"? Are there some specific changes you can think of that would have made it a less bad idea?
1. It's confusing. The fact that there's a "role" attribute that is implicit sometimes and needs to be declared other times and a "aria-XYZ" set of attributes is stupid. The purist HTML take was always "Markup should describe content" - now we're describing content with attributes?
2. It's positioned specifically as being for accessibility. This is bad for several reasons. First, it's not necessary. The entire goal of semantic markup in the first place was to make it so that the content of documents can be read by machines (both screen readers and other systems) - tacking on a special system just for accessibility is basically them giving up on this entirely. Secondly, a lot of people don't care about accessibility. Like I said, in our current system people barely know how to write HTML. Or they write some bastardized version of it in JSX or w/e. You think they're going to learn the intricacies of ARIA? No.
The goal should be for HTML to be a language that when written properly is accessible by default. Not just "hey everybody it's cool if you use divs for everything, just make sure screen readers know what it's supposed to be."
2. It's positioned specifically as being for accessibility. This is bad for several reasons. First, it's not necessary. The entire goal of semantic markup in the first place was to make it so that the content of documents can be read by machines (both screen readers and other systems) - tacking on a special system just for accessibility is basically them giving up on this entirely. Secondly, a lot of people don't care about accessibility. Like I said, in our current system people barely know how to write HTML. Or they write some bastardized version of it in JSX or w/e. You think they're going to learn the intricacies of ARIA? No.
The goal should be for HTML to be a language that when written properly is accessible by default. Not just "hey everybody it's cool if you use divs for everything, just make sure screen readers know what it's supposed to be."
> Add dynamic interpolation to the HTML spec. This stops every framework from having to invent it's own version of it.
Not sure what this means exactly
> 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier.
Something like AlpineJS built-in?
> 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
ARIA roles kind of already do this.
Not sure what this means exactly
> 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier.
Something like AlpineJS built-in?
> 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
ARIA roles kind of already do this.
My post will expand on all of this in detail, including addressing ARIA.
In practice, any attempt to change these basic specs would be diverted to be to the benefit of Google and its ilk, with the power they have to steer conversations and decisions. It's an accident of history that we ended up with these fairly open and hackable systems as the basis for the Web, and it's at a delicate point where a lot of companies are annoyed that they can't silo and close down more of it.
So the unfortunate reality is that any well-intentioned attempt to reform them would be used instead to reshape them for corporate interests, with no guarantee that we even end up with better specs from a developer point of view. The incentives lay in the direction of guaranteeing corporate interests, with users losing more of their freedom to choose how they access and use the Web; the developer concerns will at best be used as a PR front for the press headlines.
So the unfortunate reality is that any well-intentioned attempt to reform them would be used instead to reshape them for corporate interests, with no guarantee that we even end up with better specs from a developer point of view. The incentives lay in the direction of guaranteeing corporate interests, with users losing more of their freedom to choose how they access and use the Web; the developer concerns will at best be used as a PR front for the press headlines.
Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? Would you choose a React-like model, or maybe something more Svelte-like? Or something different from either of those two that I'm not aware of?
And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the goal removing the build process? Increasing uniformity across the ecosystem?
And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the goal removing the build process? Increasing uniformity across the ecosystem?
Great questions!
>Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers?
The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does.
I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right.
That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?"
>if your proposed solution would look similar to current JS solution X, why would it be better than X?
It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.
>Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers?
The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does.
I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right.
That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?"
>if your proposed solution would look similar to current JS solution X, why would it be better than X?
It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.
I appreciate the ambition to reduce the complexity and tooling overheads. Unfortunately, I doubt we could define a sufficiently general API for the kind of functionality you’re talking about. There is too much variety in the applications we now build with web technologies.
Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a substantial proportion of all web UI development.
But the kind of data binding you’re talking about wouldn’t help at all with implementing a word processor, an FPS game or a data-heavy app built around interactive visualisations. A foundation where UIs are built from simple pieces of DOM derived directly from corresponding variables in JS would severely restrict what we could build on top.
Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a substantial proportion of all web UI development.
But the kind of data binding you’re talking about wouldn’t help at all with implementing a word processor, an FPS game or a data-heavy app built around interactive visualisations. A foundation where UIs are built from simple pieces of DOM derived directly from corresponding variables in JS would severely restrict what we could build on top.
In my scenario, it's not like I'm saying JavaScript frameworks can't or shouldn't exist. My point is they have become the default and I don't think they should be.
We will always need JS frameworks. It's where some of our best ideas have come from. I just think it's time that some of the most successful ideas make it into the standards.
We will always need JS frameworks. It's where some of our best ideas have come from. I just think it's time that some of the most successful ideas make it into the standards.
> Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables.
That would be a very admirable and IMO sufficient goal. Being able to do "modern forms" with "native" capabilities seems fairly reasonable.
The word processor, fps, data heavy requirements are IMO being taken care of by WebAssembly, which is a more appropriate technology for those sorts of things than the DOM is anyway.
That would be a very admirable and IMO sufficient goal. Being able to do "modern forms" with "native" capabilities seems fairly reasonable.
The word processor, fps, data heavy requirements are IMO being taken care of by WebAssembly, which is a more appropriate technology for those sorts of things than the DOM is anyway.
I look forward to the post coming into my RSS reader :)
> they didn't have to do stuff like chase down NPM problems or debug Webpack.
The ship has well and truly sailed on that one. Building a reactivity framework into the browser isn't going to solve dependency management or transpiling.
But I wonder if ESM is going to change this game a bit. Now that dependencies are statically analysable in the page source, a CloudFlare or similar could sit between the "source" and the browser and do intelligent caching and bundling transparently.
> they didn't have to do stuff like chase down NPM problems or debug Webpack.
The ship has well and truly sailed on that one. Building a reactivity framework into the browser isn't going to solve dependency management or transpiling.
But I wonder if ESM is going to change this game a bit. Now that dependencies are statically analysable in the page source, a CloudFlare or similar could sit between the "source" and the browser and do intelligent caching and bundling transparently.
State has nothing to do with the DOM. State is a data feature of your application which is not the DOM. It sounds like you are stuck in some inescapable framework mindset. If you can escape framework insanity state is an easily solved problem and the DOM stops being scary.
Using React with an API back-end is only 1 of many choices.
There's tools like Hotwire[0] and htmx[1] (both are back-end agnostic) that will let you create good old boring web apps with any back-end language where you don't need to write a ton of JS. You can sprinkle in front-end quality of life enhancements as needed to make nice feeling web apps with reasonably minimal complexity.
[0]: https://hotwired.dev/
[1]: https://htmx.org/
There's tools like Hotwire[0] and htmx[1] (both are back-end agnostic) that will let you create good old boring web apps with any back-end language where you don't need to write a ton of JS. You can sprinkle in front-end quality of life enhancements as needed to make nice feeling web apps with reasonably minimal complexity.
[0]: https://hotwired.dev/
[1]: https://htmx.org/
From my experience the more exotic frameworks are often pushed at smaller companies by developers hoping they'll be hard to replace whereas big companies use what s most popular to ensure they can find replacements easily.
Htmx isn't a framework, and is usually embedded in a more popular backend-rendering framework like Django or rails. Htmx is just a library that removes the need for the most common client-side SPA features, (i.e. partial page updates).
Hotwire is created by Basecamp which also houses the main creators of Rails.
Basecamp has been around for ~20 years. I have a lot of confidence that it'll be around and supported because it's a substantial part of the stack involved with a real world application that is their primary business. It's also from a group of folks who have an impeccable track record for supporting the tools they use.
Basecamp has been around for ~20 years. I have a lot of confidence that it'll be around and supported because it's a substantial part of the stack involved with a real world application that is their primary business. It's also from a group of folks who have an impeccable track record for supporting the tools they use.
Nothing involving React will resolve the complexity issue...
The benefits react provides in functionality (page transitions and controls) could have been better addressed within web browsers, but the process of web design is constantly trying to resolve front end issues in code to suit a wide variety of OS versions and browsers, which is where a big problem lies...
i don't have the answers myself, but this urge to use tons of different libraries, langs, services, and tools just to build web apps, and then the never ending cycle of updating things daily to maintain stability and security may make people money, but it's really not sustainable in the long run. This is why most sites are beginning to be run on platforms like WIX and sharepoint, while independent developers and small app companies go broke. There is just too much damn complexity gumming up everything.
The benefits react provides in functionality (page transitions and controls) could have been better addressed within web browsers, but the process of web design is constantly trying to resolve front end issues in code to suit a wide variety of OS versions and browsers, which is where a big problem lies...
i don't have the answers myself, but this urge to use tons of different libraries, langs, services, and tools just to build web apps, and then the never ending cycle of updating things daily to maintain stability and security may make people money, but it's really not sustainable in the long run. This is why most sites are beginning to be run on platforms like WIX and sharepoint, while independent developers and small app companies go broke. There is just too much damn complexity gumming up everything.
Amen
Don't forget Unpoly: https://demo.unpoly.com/
And Alpine https://alpinejs.dev/ and petite-vue https://github.com/vuejs/petite-vue
Unpoly is the best thing I've discovered in the frontend world in the last 5 years. It's a breath of fresh air when compared to all the crazyness going on.
I use it to replace almost all "api" calls to the backend and for the "turbolinks like" navigation, modals, etc. Then I use Alpinejs for the really interactive/complex parts.
I'm not doing a React/SPA ever again if I have any chance to decide on that.
I use it to replace almost all "api" calls to the backend and for the "turbolinks like" navigation, modals, etc. Then I use Alpinejs for the really interactive/complex parts.
I'm not doing a React/SPA ever again if I have any chance to decide on that.
I bumped into an old friend recently and he and his wife work at a real estate company. They were raving about this new system they are a couple of years into the development of and how it's built on this great "Kubernetes" system.. they asked what I develop my products with and I almost felt embarrassed to say PHP and a couple of servers in two locations for redundancy that run Archlinux with a LAMP (LNMP? I guess with NGINX/MariaDB these days) stack .. same thing I've used for 20 years now (I was one of the first AL volunteers). When I asked what language their system is developed in they said Kubernetes, of course.
Anyway, it kind of reminds me of the days when everyone was developing a PHP Framework .. I've never used one and if I was to apply for a PHP job I'd be unlikely to succeed as I'm very specialised in getting shit done.
Anyway, it kind of reminds me of the days when everyone was developing a PHP Framework .. I've never used one and if I was to apply for a PHP job I'd be unlikely to succeed as I'm very specialised in getting shit done.
Thing is if you understand php you dont really need a framework. Sure composer packages are a must to avoid rewriting whats out there, but a framework not so much. When i conducted interviews i was shocked at how many php devs had no clue about what an sql injection is, they almost all answered “the framework does it for you” and it was such a basic thing.
Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).
But “what if we switch to a different database engine”? Yet i’ve never seen that happen!
Edit: wait smarty still a thing!?
Edit: wait smarty still a thing!?
I used Postgres when I first started out in ~2002 but it was slow, really slow, I switched to MySQL and it was fast and the customers happy. The MyISAM table engine was shit hot(fast) but it took me years to get my head around constraints and then indexes etc to actually get a basic level of competence and realise MyISAM was a bunch of trade off's for performance. Anyway I loved PG and still do romanise it.. what if I stayed.. what could have been.. but it didn't get the job done, for me.
Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.
Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.
This point of view is a fallacy itself. ORMs are about productivity and maintainability. Some of us write enterprise applications where ORMs are a godsend. They're not a replacement for being knowledgeable in SQL whatsoever.
It's just my opinion based on 20+ years of developing data management solutions across thousands of customers.. any framework employs a set of beliefs and that creates a box you are constrained to think in, hell SQL is one of them boxes. You say "They're not a replacement for being knowledgeable in SQL whatsoever." .. so what are they then?
Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.
Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.
Not sure if you've used Entity Framework, but you can do compos (with logic) amazing complex queries with relatively little code in a way that is statically typed and super easy to maintain. I'm talking about pulling heavily structured data from the database without having to pull from flat tables and structure it yourself server side.
Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc..
We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.
Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc..
We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.
But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.
The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries.
Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs.
I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM.
I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.
Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs.
I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM.
I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.
Can you show me an example of the 10x less code?
You're going to get a huge reduction in code for all sorts of things, especially when navigating multiple relations, grouping, sub-selects, etc..
var results = db.myTable
.where(x => x.value > 6)
.where(mySpecialConditionalLogicFunction)
.select(x => {
thing = x.relation.relation.relation.value,
thingList2 = x.relation.relations
.groupby(y => y.value)
.select(g => g.count)
.orderby(y => y.value)
.take(5),
thing3 = x.relations
.where(z => z.relation1.value < z.relation2.value)
.select(z => z.relation.value)
.max(),
thing4 = myReusableSelectDTOfunction,
etc..
This brings fond memories of my early stages where i became fond of the method chaining pattern. I became fascinated by it when using doctrine.
However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.
The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.
Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.
However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.
The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.
Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.
Take a single line from my example 'x.relation.relation.relation.value'
The SQL would be
In addition compiling will validate the ORM code generates valid SQL. On the other hand compiling will not validate a SQL string.
'Custom functions' are just larger versions of the anonymous functions in my example. Very easy for other developers to go to the reference and understand.
The SQL would be
select w.value
from x
join y on y.relation=x.relation
join z on z.relation=y.relation
join w on w.relation=z.relation
In addition compiling will validate the ORM code generates valid SQL. On the other hand compiling will not validate a SQL string.
'Custom functions' are just larger versions of the anonymous functions in my example. Very easy for other developers to go to the reference and understand.
Hold on, we are talking php here. There is no code compiling.
Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.
I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.
Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.
Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.
Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.
I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.
Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.
Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.
With hundreds of developers and millions of lines of code - yes Typescript and ORMs will completely eliminate entire classes of bugs, and be a force multiplier when it comes to productivity.
You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.
You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.
Totally agreed re keeping an open mind. But after having used all the niceties you describe i understood that php itself is a fractal of poor design and practices. Gave up on using literally everything you described and ended up writing better code at a fraction of the time.
I do recommend reflecting on things as not knowing everything goes both ways.
I do recommend reflecting on things as not knowing everything goes both ways.
I am concerned how much your posts center around you writing code and not a team. Are you concerned about maintainability? Have you written software with large teams before and have had to maintain that software over a number of years?
They're a convenience for 99.9% of use cases. For the other 0.1%, I write SQL, but to be honest, I've never had to yet.
You can deliver business value with boring glue code.
You can deliver business value with boring glue code.
So you have 0.1% SQL skill .. work on it.
Actually a flat 0%.
Well, that the issue with php devs.
Oh I don't know any PHP, sadly. That's probably another issue with us.
You think you did a funny but you’d be surprised how many php devs dont know php.
Oh, all of them.
I will be bias here as I made my own ORM (for typescript and postgre, no less), but I have to hard disagree. As other comments have pointed out, ORMs are about productivity, getting persistence done quickly.
Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand?
Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic.
Few more points, but I think the drift is caught.
Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand?
Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic.
Few more points, but I think the drift is caught.
“ Also, it doesn't have to be black and white - ORM or no ORM
The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.
The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.
I ask this question a lot too, and yeah it’s shocking to see how many that believe things like magic quotes or some other unknown layer solve everything.
Magic quotes is of course very different from an ORM doing the application-specific encoding. It’s just very worrying when people don’t know which layer of the stack sanitizes for them.
For those of you young enough to not have witnessed php. Magic quotes used to be a popular configuration option that would sanitize all GET and POST inputs to make it safe to use in sql. Needless to say, it didn’t work and instead corrupts user data that is not intended to go through sql.
Magic quotes is of course very different from an ORM doing the application-specific encoding. It’s just very worrying when people don’t know which layer of the stack sanitizes for them.
For those of you young enough to not have witnessed php. Magic quotes used to be a popular configuration option that would sanitize all GET and POST inputs to make it safe to use in sql. Needless to say, it didn’t work and instead corrupts user data that is not intended to go through sql.
no such thing as frontend development. only full stack. and react for all the trillions of words written about it, what can you actually do with it? not much.
also it's over-saturated as hell. you think there's high demand, you're right, now try applying for a position and see how it goes.
there are two types of roles in modern web dev:
1 .90% of jobs are code monkey work: extremely saturated, you are competing with global workforce who will work for half your salary or less. i will get downvoted, probably cos there so many bootcampers and others who don't like to hear this reality.
2. 10% of jobs at top tier tech companies that pay the top salaries. good luck with the 10 stage interviews, aptitude exam, leetcoding and then getting ghosted.
the complexity itself just comes from the amount of steps required to do something trivial:
2010 edit an html button:
1. pull the file from ftp or sourcesafe/svn
2. edit the button
3. upload to ftp
2020 edit an html button:
1. install git
2. install npm, node
3. clone and install the code
4. deal with myriad node js errors
5. deal with myriad deprecation warnings and other issues in npm
6. start local environment
6.1 local requires docker
6.2 install docker
6.3 try to start docker
7. docker requires sudo
8. request sudo from IT
9. fill a form explaining why you need sudo
10. install docker
11. start the local environment
12. edit the html button
13. local server not refreshing
14. fix local tooling issues
15. commit changes
16. your changes are 10 commits behind the branch
17. try to merge automatically, cannot be merged
18. make a PR
19. smug know it all "senior" developer with 2 years experiences, gives a bunch of nitpicky comments on the PR and refuses to merge it
20. go back to step 6
also it's over-saturated as hell. you think there's high demand, you're right, now try applying for a position and see how it goes.
there are two types of roles in modern web dev:
1 .90% of jobs are code monkey work: extremely saturated, you are competing with global workforce who will work for half your salary or less. i will get downvoted, probably cos there so many bootcampers and others who don't like to hear this reality.
2. 10% of jobs at top tier tech companies that pay the top salaries. good luck with the 10 stage interviews, aptitude exam, leetcoding and then getting ghosted.
the complexity itself just comes from the amount of steps required to do something trivial:
2010 edit an html button:
1. pull the file from ftp or sourcesafe/svn
2. edit the button
3. upload to ftp
2020 edit an html button:
1. install git
2. install npm, node
3. clone and install the code
4. deal with myriad node js errors
5. deal with myriad deprecation warnings and other issues in npm
6. start local environment
6.1 local requires docker
6.2 install docker
6.3 try to start docker
7. docker requires sudo
8. request sudo from IT
9. fill a form explaining why you need sudo
10. install docker
11. start the local environment
12. edit the html button
13. local server not refreshing
14. fix local tooling issues
15. commit changes
16. your changes are 10 commits behind the branch
17. try to merge automatically, cannot be merged
18. make a PR
19. smug know it all "senior" developer with 2 years experiences, gives a bunch of nitpicky comments on the PR and refuses to merge it
20. go back to step 6
> request sudo from IT
If you work for a company that doesn't give you Sudo on your own machine as a developer by default, find a new job
Don't work for companies that still treat their professionals like children.
If you work for a company that doesn't give you Sudo on your own machine as a developer by default, find a new job
Don't work for companies that still treat their professionals like children.
Easier said than done. This style of doing things is very common in large corporate environments such as financial services. The first time anybody works at a place like this they are shocked by all the IT red tape, but it's an interesting (and frustrating) rite of passage. It takes maturity and experience to understand that there is always a reason for "stupid" complications.
These organization should change their infosec posture to support sudo on dev machines as standard issue, especially if you’re issuing laptops. Maybe I’m immature but I’d prefer not to suffer as such for the sake of a “rite of passage” from ages past.
Some organizations still haven’t adjusted their infosec posture to allow git, let alone sudo.
I think it's very easy to not work there, just leave and don't go back.
I suspect most people that stick around either don't know any better or do it for the money/status/whatever and not for the technology.
Absolutely unacceptable to not give a developer local root on their own machine. Manage profiles and install logging all you want, but requiring a developer to ask permission to install docker/git/tools they need is not security, it's incompetence.
If your employer won't give you the tools you need to do your job you should find another one. If your IT/security department is there to block you instead of help you get work done, you should also find a new job. I'm not saying walk out the door today, just that you don't deserve to be treated like that.
If your employer won't give you the tools you need to do your job you should find another one. If your IT/security department is there to block you instead of help you get work done, you should also find a new job. I'm not saying walk out the door today, just that you don't deserve to be treated like that.
While I agree with the message you are trying to convey, the 2020 case doesn't have to be more complicated than the 2010 case:
2010 edit an html button:
0. Install an ftp client (you need to mention that if you mention installing git)
1. pull the file from ftp or sourcesafe/svn
2. edit the button
3. upload to ftp
2020 edit an html button:
1. clone the code 2. edit the html button 3. commit changes
2010 edit an html button:
0. Install an ftp client (you need to mention that if you mention installing git)
1. pull the file from ftp or sourcesafe/svn
2. edit the button
3. upload to ftp
2020 edit an html button:
1. clone the code 2. edit the html button 3. commit changes
You can’t test the 2020 code without Node.
Come on now. With modern flow, you have to "install git", but in ye olde times you don't install svn or ftp? And back then we didn't have gatekeeping seniors? And we request sudo now, and not back then? I think you got that confused.
Old software sucked a lot, and automation sucked a lot. Weird issues where you HAD to know what went wrong, because handholding was looked down upon. The lack of automation meant that servers were pets, you looked after them, groomed them, maybe even sang a song to get the piece of junk going. Modern automation means you mostly care about the blueprint, not the actual instance. If it's not working properly, you reimage. If you need more, fire up more instances.
Also, what can you do on the frontend only? I have two examples from the top of my head:
https://www.photopea.com/
https://simplepdf.eu/
Old software sucked a lot, and automation sucked a lot. Weird issues where you HAD to know what went wrong, because handholding was looked down upon. The lack of automation meant that servers were pets, you looked after them, groomed them, maybe even sang a song to get the piece of junk going. Modern automation means you mostly care about the blueprint, not the actual instance. If it's not working properly, you reimage. If you need more, fire up more instances.
Also, what can you do on the frontend only? I have two examples from the top of my head:
https://www.photopea.com/
https://simplepdf.eu/
> Also, what can you do on the frontend only?
I was talking specifically about React. But it's not a surprise that "modern front end" devs conflate React with JavaScript.
I was talking specifically about React. But it's not a surprise that "modern front end" devs conflate React with JavaScript.
I see. I was confused by the statement before it: "no such thing as frontend development. only full stack."
Getting back to the point, my simplepdf.eu example is indeed using React - according to Builtwith, it's built with Next.js, which is used to build React applications.
Getting back to the point, my simplepdf.eu example is indeed using React - according to Builtwith, it's built with Next.js, which is used to build React applications.
It’s crazy and impressive how we devs created this fucking huge industry where hundreds of millions was spent to solve a problem that didn’t really exist and actually made things harder and more expensive.
every solution creates new issues. sometimes the trade-offs are worth it, but many many are not - but there is a lack of stability and appreciation for long term support, so trade-offs are being made left right and center. you work on constantly shifting surfaces.
you nailed it! this is exactly the problem. everything is horribly overcomplicated these days. i've 13 years of business experience and it gets harder and harder to even set up the most simple "hello world" demo of most frameworks. also the job market represents this insanity too: 5 years ago I easily got senior positions, now i don't even know the words inside most job descriptions even in my field. And on top of all, stuff like kubernetes, kibana and prometheus now also is often expected from a typical backend developer. absolute mayhem!
A couple builders were complaining why they couldn't build houses like in the old days when you would slap 2 blocks of wood together and call it a day. now you have to use steel, heatproof it, soundproof it, check the integrity of the build, submit designs, take safety into account, what a waste...
obviously sarcastic. most of the things you are complaining about bring to mind a person who is bored of doing responsible coding.
obviously sarcastic. most of the things you are complaining about bring to mind a person who is bored of doing responsible coding.
A couple people have asked what complexities I’m referring to and mainly what I mean is just how much bloat goes into making anything, and at a higher level the general course of action seems to be to just keep adding to the system until you get what you want out of it instead of trying to fix or improve underlying problems with the web.
I know we can’t just pause the internet while everyone comes to a consensus on how we want to make it more interactive and fix underlying problems, but at least to me it seems like all the effort that could be spent working towards that is instead being spent figuring out ways to just avoid as much of the underlying pieces as possible by jamming your own implementation on top of it.
I agree that getting setup and using things like React or Node for a backend is easy, but the number of dependencies, size of the app, tooling needed, memory used are all going to grow exponentially as soon as you start trying to do something non trivial, and the solution to fix these problems is yet again to add more complexity, where you will need to learn a lot more about how all of those nice tools that just worked for you out of the box are actually working
This isn’t a React or a frontend specific example entirely, but I’ve seen many people jump into creating a simple app and right off the bat implementing a federated GraphQL design because of all the great things they heard about GraphQL from the community, which is fine but a very simple REST design would have worked just as well if not better and would be in my opinion much simpler to maintain and manage complex things like caching.
I know we can’t just pause the internet while everyone comes to a consensus on how we want to make it more interactive and fix underlying problems, but at least to me it seems like all the effort that could be spent working towards that is instead being spent figuring out ways to just avoid as much of the underlying pieces as possible by jamming your own implementation on top of it.
I agree that getting setup and using things like React or Node for a backend is easy, but the number of dependencies, size of the app, tooling needed, memory used are all going to grow exponentially as soon as you start trying to do something non trivial, and the solution to fix these problems is yet again to add more complexity, where you will need to learn a lot more about how all of those nice tools that just worked for you out of the box are actually working
This isn’t a React or a frontend specific example entirely, but I’ve seen many people jump into creating a simple app and right off the bat implementing a federated GraphQL design because of all the great things they heard about GraphQL from the community, which is fine but a very simple REST design would have worked just as well if not better and would be in my opinion much simpler to maintain and manage complex things like caching.
everyone has a choice in taking on those dependencies. as a solo dev you get to make those choices. In the context of work, it is harder because you have to balance many other needs from technical to just the human squishy feeling of making people's code get accepted and not fighting everyone on every damn thing. It's hard to get everyone on the same page!
Not really related to the above but I learned React when I started my current job and I hated and did not understand it when I first started https://cmdcolin.github.io/posts/2020-07-04. Now it has changed my thinking entirely, and I think react is very powerful. Not without awkwardness and whatnot, but it's better than spaghetti jQuery era
Not really related to the above but I learned React when I started my current job and I hated and did not understand it when I first started https://cmdcolin.github.io/posts/2020-07-04. Now it has changed my thinking entirely, and I think react is very powerful. Not without awkwardness and whatnot, but it's better than spaghetti jQuery era
Web Development is as complicated as you (or the team) makes it. Your issue seems to be with people's choices rather than the ecosystem. Changing to another area won't solve anything for you. Choose the right team for the kind of work you like.
It sure looks like we’re nearing the “peak Java Enterprise Edition” moment for frontend web development space.
We got here honestly: Single Page Apps made “fat” clients possible in the browser, but that meant a lot of logic had to move to the front end, so they naturally became bigger and more complex. Meanwhile, we still want to have the “lazy installation” experience of browsing to a web page and having things load quickly, and this adds all sorts of complexity like bundle splitting, hydration, “edge” hosting, etc.
I’m not sure where we go from here, complexity-wise, but here are some guesses:
* no/low code will produce a new “ruby on rails” for the modern SPA space. (There are already contenders.) * increased environment complexity will move development into the cloud and off of our local machines. * there won’t be a sudden disappearance of the older approaches, just like SPAs didn’t kill RoR.
We got here honestly: Single Page Apps made “fat” clients possible in the browser, but that meant a lot of logic had to move to the front end, so they naturally became bigger and more complex. Meanwhile, we still want to have the “lazy installation” experience of browsing to a web page and having things load quickly, and this adds all sorts of complexity like bundle splitting, hydration, “edge” hosting, etc.
I’m not sure where we go from here, complexity-wise, but here are some guesses:
* no/low code will produce a new “ruby on rails” for the modern SPA space. (There are already contenders.) * increased environment complexity will move development into the cloud and off of our local machines. * there won’t be a sudden disappearance of the older approaches, just like SPAs didn’t kill RoR.
I think we'll just go back to the old approaches. I already build apps with thin frontends, and maybe use HTMX if desired. Fat frontends aren't worth the complexity unless you have an interactive app (e.g. Google Docs), which you very probably don't.
I've been doing front-end development off and on for 25 years and I still had a moment like this just this week.
A different team updated a library we're supposed to use and all of a sudden, the deployed service was crashing on startup (worked locally). It appeared as though the problem was some EMCA6 syntax wasn't playing well with Babel configuration that seemed fine to me.
I got so frustrated that I ended up removing Babel (because it wasn't needed to begin with), which meant I had to change all the import statements to 'require' and had to change all the export syntax to CommonJS. Finally got it working after many hours and refactoring...
Except then I realized that the base docker image in the dockerfile was node 12 and not 16. If I had just updated the dockerfile, I wouldn't have had to remove Babel and would have saved myself a day.
Modern front-end development is sort of like child birth. Your brain conveniently forgets what it felt like to push a watermelon through a straw.
A different team updated a library we're supposed to use and all of a sudden, the deployed service was crashing on startup (worked locally). It appeared as though the problem was some EMCA6 syntax wasn't playing well with Babel configuration that seemed fine to me.
I got so frustrated that I ended up removing Babel (because it wasn't needed to begin with), which meant I had to change all the import statements to 'require' and had to change all the export syntax to CommonJS. Finally got it working after many hours and refactoring...
Except then I realized that the base docker image in the dockerfile was node 12 and not 16. If I had just updated the dockerfile, I wouldn't have had to remove Babel and would have saved myself a day.
Modern front-end development is sort of like child birth. Your brain conveniently forgets what it felt like to push a watermelon through a straw.
[deleted]
PHP.
Use PHP, it’s so crazy easy for web development.
- No compiling,
- no middleware,
- no state (which also means no memory leaks),
- just drop a file on web server and it works (no crazy CI pipeline),
- the documentation is fantastic,
- it’s extremely fast, and
- no surprises because it’s tried and true.
PHP is so under appreciated.
Use PHP, it’s so crazy easy for web development.
- No compiling,
- no middleware,
- no state (which also means no memory leaks),
- just drop a file on web server and it works (no crazy CI pipeline),
- the documentation is fantastic,
- it’s extremely fast, and
- no surprises because it’s tried and true.
PHP is so under appreciated.
The issue with php is the type of developers that use it and bloated frameworks. Nearly all developers still debate wether to use setters and getters and have no clue how to use the language itself, as a result using over engineered frameworks. The language itself is nice but is swamped by amateurs.
The "PHP is full of amateurs" trope is so tired.
You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry.
You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves.
Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.
You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry.
You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves.
Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.
You are right about the reasons there are so many amateurs in the php world. But i disagree with the statement that they become professionals over time. If you keep doing the same wrong thing over and over you just become better at doing the same wrong thing over and over, many being just old junior developers. Add the fresh supply of amateurs entering the php job market each year and you are stuck.
There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.
There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.
You are living in a fantasy world if you think this is limited to one language
Also good about PHP:
- mostly backwards compatible with easy upgrades, even between major versions
- many new features all the time for better static analysis, type safety, speed, succinct code, etc
- designed for use with Web
- PHP itself is a (good) templating langue, so no need to reinvent the wheel there
- FFI interface for integrating native code
- easy to learn
Some downsides though:
- Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP
- Need something like FPM to fire up one whole process per visitor
- Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there
- Still no typed resource handles until PHP 9+
- Syntax is cumbersome in many ways, though improving
- mostly backwards compatible with easy upgrades, even between major versions
- many new features all the time for better static analysis, type safety, speed, succinct code, etc
- designed for use with Web
- PHP itself is a (good) templating langue, so no need to reinvent the wheel there
- FFI interface for integrating native code
- easy to learn
Some downsides though:
- Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP
- Need something like FPM to fire up one whole process per visitor
- Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there
- Still no typed resource handles until PHP 9+
- Syntax is cumbersome in many ways, though improving
I tried out PHP recently for a project because I have fond memories of it, but didn't end up going with it. I want server side rendering for the SEO benefits, but I also want some good 'app like' interactivity on the page. Doing the app like stuff with PHP is possible, but you kind of have to have mirror routines, one to load the data, and other api calls to update the data using whatever binding library you choose.
The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend
I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already.
Interested in others thoughts on this.
The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend
I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already.
Interested in others thoughts on this.
You can add any interactivity you want to PHP (or any other server rendered html) using Alpine.js, Unpoly, HTMX, or any other kind of modern approach to frontend JavaScript. It is not anymore a dichotomy between ugly jQuery spaghetti or full SPA Next.js thing.
I did consider Alpine, the pro is that it is very light. The con is that the components don’t seem as complete as MUI and not free either. Also the repo activity of next/react/MUI is much higher than PHP/alpine.
One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.
I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.
One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.
I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.
> The con is that the components don’t seem as complete as MUI and not free either.
I think you're mixing different things here. Not liking Alpine because you don't like the components is like not liking React because you don't like some component library for it.
Alpine per se is a perfectly standalone library. I use it for my projects and I do not use their components library. Same I use React and don't use MUI either on some projects.
> Also the repo activity of next/react/MUI is much higher than PHP/alpine.
If the project is well maintained, widely used, documented and has no evident unsolved/ignored bugs... isn't this a feature? Why do we need things to constantly change?
> One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.
I've worked for companies that, even using popular tools, ended up stranded. One of then with a Vue 2 project which they already "declared" they'd never move to Vue 3 because of all the third party dependencies and own code they had. Same at another job with Python 2/3. So choosing popular libraries, while safer, it's not always safe.
On the other hand, when you choose React (or any other "SPA" heavy tool) you will also need to decide on 10s of other libraries. From state management, to routing, maybe a meta-framework, a validation library, an ORM or data access library, some other for doing maybe background jobs, another for translations, another for graphql or your rest API, etc, etc, etc. Any of those can go unmaintained and cause big headaches.
I highly doubt anything such as Rails, Laravel or Django will go unmaintained and leave you stranded. Alpine.js doesn't look like it is going away any time soon as it is already pretty popular. Would love to say the same thing about Adonis, but I don't know many people using it yet, although I have big hopes for it. Unpoly, HTMX, etc... are more valuable by their ideas and ideology that by their implementation imho. They're small enough like to maintain it yourself or write your own implementation in a worst case scenario.
I think you're mixing different things here. Not liking Alpine because you don't like the components is like not liking React because you don't like some component library for it.
Alpine per se is a perfectly standalone library. I use it for my projects and I do not use their components library. Same I use React and don't use MUI either on some projects.
> Also the repo activity of next/react/MUI is much higher than PHP/alpine.
If the project is well maintained, widely used, documented and has no evident unsolved/ignored bugs... isn't this a feature? Why do we need things to constantly change?
> One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.
I've worked for companies that, even using popular tools, ended up stranded. One of then with a Vue 2 project which they already "declared" they'd never move to Vue 3 because of all the third party dependencies and own code they had. Same at another job with Python 2/3. So choosing popular libraries, while safer, it's not always safe.
On the other hand, when you choose React (or any other "SPA" heavy tool) you will also need to decide on 10s of other libraries. From state management, to routing, maybe a meta-framework, a validation library, an ORM or data access library, some other for doing maybe background jobs, another for translations, another for graphql or your rest API, etc, etc, etc. Any of those can go unmaintained and cause big headaches.
I highly doubt anything such as Rails, Laravel or Django will go unmaintained and leave you stranded. Alpine.js doesn't look like it is going away any time soon as it is already pretty popular. Would love to say the same thing about Adonis, but I don't know many people using it yet, although I have big hopes for it. Unpoly, HTMX, etc... are more valuable by their ideas and ideology that by their implementation imho. They're small enough like to maintain it yourself or write your own implementation in a worst case scenario.
I need well fleshed out components, and because of the size of the project and the lifetime of it - something that won’t have to be rewritten because the tech went stale next year.
Same with ORM and state management - sequelize and redux seem to be the most active and compatible with next.
I had the same experience being stranded with AngularJS. You never know what will be abandoned next, you can only make choices to help minimize that chance.
Same with ORM and state management - sequelize and redux seem to be the most active and compatible with next.
I had the same experience being stranded with AngularJS. You never know what will be abandoned next, you can only make choices to help minimize that chance.
For my freelance work, I did a ton of "old school" PHP (no frameworks.) A few years back, I tried Laravel and it was incredibly productive.
> - no state (which also means no memory leaks),
Ehh, what? Sessions are state.
> - just drop a file on web server and it works (no crazy CI pipeline)
Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini.
> - the documentation is fantastic,
Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place.
PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.
Ehh, what? Sessions are state.
> - just drop a file on web server and it works (no crazy CI pipeline)
Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini.
> - the documentation is fantastic,
Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place.
PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.
> Sessions are state
Is database state?
> php-fpm, opcache
Nope
> countless parameters
Certainly not
> "mysql_real_escape_string" vs "mysql_escape_string"
There are only a handful of these, and you can learn about them with a simple google search.
Is database state?
> php-fpm, opcache
Nope
> countless parameters
Certainly not
> "mysql_real_escape_string" vs "mysql_escape_string"
There are only a handful of these, and you can learn about them with a simple google search.
> Is database state?
Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores.
Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.
Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores.
Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.
> This data isn't magically stored in the air and if you use more than a single machine
I'm curious, what do you think the OP meant when they said "stateless"?
> I assume that you haven't worked at scale with php
Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?
I'm curious, what do you think the OP meant when they said "stateless"?
> I assume that you haven't worked at scale with php
Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?
> I'm curious, what do you think the OP meant when they said "stateless"?
Any kind of user session where user information is stored for access across multiple pages. When you use $_SESSION and write a variable into it, the content is persisted on the server and the user gets a cookie with an ID which points to their session variables. This is state that needs to be shared across servers when want you scale out.
The opposite would be e.g. an jwt, where the state is stored in the token.
Any kind of user session where user information is stored for access across multiple pages. When you use $_SESSION and write a variable into it, the content is persisted on the server and the user gets a cookie with an ID which points to their session variables. This is state that needs to be shared across servers when want you scale out.
The opposite would be e.g. an jwt, where the state is stored in the token.
Okay, I think the OP instead meant that server-based rendering is more "stateless" because you do a full page refresh to get any new content, as opposed to a SPA where state management is a big problem.
session_* can be misused if developer is not careful be closing the session as soon as possible to avoid being open during the entire request (mostly a problem for the default file session storage).
Personally I store a token in in my own cookie and then read from whatever storage. No need to correctly implement SessionHandlerInterface (which can be tricky to get right)
Personally I store a token in in my own cookie and then read from whatever storage. No need to correctly implement SessionHandlerInterface (which can be tricky to get right)
Shhhh stop talking about PHP, the ruby devs will start contributing code and ruin it! (I'm already angry that they moved the YAML parser out of the PHP standard library...)
Yeah web development went from being a passion to just being a job where I now feel like I just play the complexity game with teammates, managers, and stakeholders.
I don't care about this stuff anymore. I only care about the paycheck.
Yeah, the technology is cool... we do Docker containers... so its a 'microservices' web app with a remote registry for our containers plus a bunch of disgusting npm packages and weird frontend react client bloat.
I prefer my side-projects. They are succinct and concise. No bloat. Just DIY simplicity.
I don't care about this stuff anymore. I only care about the paycheck.
Yeah, the technology is cool... we do Docker containers... so its a 'microservices' web app with a remote registry for our containers plus a bunch of disgusting npm packages and weird frontend react client bloat.
I prefer my side-projects. They are succinct and concise. No bloat. Just DIY simplicity.
I don't know if this helps or hurts but I took up Elixir a few years ago and was liking it, the way the FP simplifies the scope you have to operate within and the general stability of the API that Jose has stated, i.e. it's feature complete for the foreseeable future, changes now are mostly optimizations such as pushing more into the erlang layer.
Then they introduced releases which can package everything into a tar file that has all the CSS, JS, HTML, erlang VM, etc. in it and runs as a binary via systemd and proxied through your .
Then they introduced LiveView and it was the first time I really had a "wow" moment since first learning Rails many many years ago. I can do nearly everything I want in real-time with it + JS hooks.
I really do think this addresses a lot of the frustration I keep experiencing w/r/t complexity in web development. I can just write Elixir code and get about 90% of the features of a JS framework like React.
The only real knock on it is it's strongly typed not static typed (they're working on a solution) but with code analysis tools like dialyzer and credo a lot of that worry is addressed. It's not for everyone but FWIW it has been a breath of fresh air to me a 10+ year web developer.
Then they introduced releases which can package everything into a tar file that has all the CSS, JS, HTML, erlang VM, etc. in it and runs as a binary via systemd and proxied through your .
Then they introduced LiveView and it was the first time I really had a "wow" moment since first learning Rails many many years ago. I can do nearly everything I want in real-time with it + JS hooks.
I really do think this addresses a lot of the frustration I keep experiencing w/r/t complexity in web development. I can just write Elixir code and get about 90% of the features of a JS framework like React.
The only real knock on it is it's strongly typed not static typed (they're working on a solution) but with code analysis tools like dialyzer and credo a lot of that worry is addressed. It's not for everyone but FWIW it has been a breath of fresh air to me a 10+ year web developer.
I've looked at Elixir a bit, but I came away with the expression that it would be a bit like doing Django before 1.7 where I had to do schema migrations manually. This is a huge deal to me.
I didn't see any forms libraries either, so the forms situation seems even more primitive. I'm the author of iommi so I now have very high level abstractions for forms/tables/menus/etc, and a transparent way to compose these. I would hate to start over from scratch...
Am I just missing some libraries?
I didn't see any forms libraries either, so the forms situation seems even more primitive. I'm the author of iommi so I now have very high level abstractions for forms/tables/menus/etc, and a transparent way to compose these. I would hate to start over from scratch...
Am I just missing some libraries?
Fwiw I was afraid of manual migrations too, coming from Django, but its not that terrible once you get used to it. There should be a few form libs out there but I havent needed one so far. Chris McCord said at ElixirConf that there are plans of reworking the forms api to make it work better with LiveView.
I'm not afraid of it. It just seems silly and tedious.
I also felt that way coming from Django, but I got used to it and embraced it
It’s a lot like Rails in that regard, where you have to model the data yourself. But it’s a part of the job — and it teaches you take advantage of the DB in ways that Django can’t.
It’s a lot like Rails in that regard, where you have to model the data yourself. But it’s a part of the job — and it teaches you take advantage of the DB in ways that Django can’t.
Elixir is a great idea, but it's already dead. I know of several companies here in Europe that already ditched it and went back to other older technologies or moved to Go, etc. because the Elixir ecosystem is so small. Also they had tons of trouble hiring for it.
I just use Go for a self contained back end and server. For the front end I use the html templates, but for the most part it is traditional html, css, and js. No compiling js.
That said, I primarily work in other areas. This is just for when I need a web app.
That said, I primarily work in other areas. This is just for when I need a web app.
My academic background is Electronic Engineering and embedded development but found myself in fullstack and then frontend development roles for over 7 years. I began to experience what you described, essentially a bunch of hype technologies bandwagoned by junior devs and HR recruiters spouting buzzwords and insane abstractions, npm dependency hell and glue code coming out of my ears. The whole ecosystem is crazy.
The worst part about it is the technical debt that companies encounter. Technology should be serving business objectives, first and foremost. If your tech-stack is outdated in 2 years time, something is really wrong.
I’ve gone back to EE, hardware engineering and embedded development. I think this specialization probably reduces job availability, but I can always fall back to webdev in tougher times if I have to, and its something to set me apart from all the 8 week bootcamp coders flooding into the webdev market
The worst part about it is the technical debt that companies encounter. Technology should be serving business objectives, first and foremost. If your tech-stack is outdated in 2 years time, something is really wrong.
I’ve gone back to EE, hardware engineering and embedded development. I think this specialization probably reduces job availability, but I can always fall back to webdev in tougher times if I have to, and its something to set me apart from all the 8 week bootcamp coders flooding into the webdev market
As someone who works in full stack development, what complexities are you talking about exactly? I just spin up a NextJS app with an express server if I need a backend as well. In a way, it's been easier than before where you'd have to set up Webpack and friends. I just write React code and it automatically shows up on the page.
You can do more complex stuff, sure, but it's not necessarily required. So it depends on what you're doing, which if you can answer I can help give an answer to.
You can do more complex stuff, sure, but it's not necessarily required. So it depends on what you're doing, which if you can answer I can help give an answer to.
> As someone who works in full stack development, what complexities are you talking about exactly? I just spin up a NextJS app with an express server if I need a backend as well. In a way, it's been easier than before where you'd have to set up Webpack and friends.
Every time I read things like this I wonder if most people here are just building landing pages or side projects.
I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks, etc, etc. "Just next.js and express" or "just next.js and prisma" is still missing a TON of stuff for me. Of course you can npm install 3000 other packages to achieve all of this, but that's a lot of work to get it right, documented, secured and battle proven.
> I just write React code and it automatically shows up on the page.
I just write HTML in a file and it shows up on the page. My solution is simpler, isn't it?
Every time I read things like this I wonder if most people here are just building landing pages or side projects.
I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks, etc, etc. "Just next.js and express" or "just next.js and prisma" is still missing a TON of stuff for me. Of course you can npm install 3000 other packages to achieve all of this, but that's a lot of work to get it right, documented, secured and battle proven.
> I just write React code and it automatically shows up on the page.
I just write HTML in a file and it shows up on the page. My solution is simpler, isn't it?
> I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks,
Sure, I was simplifying to make a point, of course I use all of those. My main point however was that there are defined, standardized solutions for all of those. It's not like there's that much churn in authentication libraries for example, most people would use Passport or just JWT.
> but that's a lot of work to get it right, documented, secured and battle proven.
It's really not, because again, solutions are pretty standardized.
Sure, I was simplifying to make a point, of course I use all of those. My main point however was that there are defined, standardized solutions for all of those. It's not like there's that much churn in authentication libraries for example, most people would use Passport or just JWT.
> but that's a lot of work to get it right, documented, secured and battle proven.
It's really not, because again, solutions are pretty standardized.
> there are defined, standardized solutions for all of those
Really? I have never seen two Next.js projects, open source or not, which use the same subset of libraries. Most don't even share the same "approach" to communication with the backend. Some use GraphQL, some other just API routes, other's proxy to another backend, other trpc, others firebase like solutions, etc... And none of them would qualify as "simple" to anyone else than the person that built it. Even more, no two single projects share the same structure or code organization.
> It's really not, because again, solutions are pretty standardized.
Tying together all of those solutions and guarantee you're not creating security holes in doing so, documenting it for others and making it robust and battle proven is complex for almost everyone, maybe not for you if you're top 1%, granted. I'd love to hear about those standard solutions you mention, because as I said above, those standard solutions are different for everyone. And I've seen tons of wasted time and effort in discussing what's the "standard solution" to use. From people discussing if they should do validations with yup or express-validator or joi to discussing if they prefer prisma or knex to entire weeks debating if migrating to GraphQL would be better.... tons of time and company money wasted.
Really? I have never seen two Next.js projects, open source or not, which use the same subset of libraries. Most don't even share the same "approach" to communication with the backend. Some use GraphQL, some other just API routes, other's proxy to another backend, other trpc, others firebase like solutions, etc... And none of them would qualify as "simple" to anyone else than the person that built it. Even more, no two single projects share the same structure or code organization.
> It's really not, because again, solutions are pretty standardized.
Tying together all of those solutions and guarantee you're not creating security holes in doing so, documenting it for others and making it robust and battle proven is complex for almost everyone, maybe not for you if you're top 1%, granted. I'd love to hear about those standard solutions you mention, because as I said above, those standard solutions are different for everyone. And I've seen tons of wasted time and effort in discussing what's the "standard solution" to use. From people discussing if they should do validations with yup or express-validator or joi to discussing if they prefer prisma or knex to entire weeks debating if migrating to GraphQL would be better.... tons of time and company money wasted.
I was thinking the same thing recently. I’ve finally realized that React is painful and overly complex. I just followed the crowd and got too deep. Backbone was elegant and simple. I could step through all the code being executed with my debugger. React is impossible to step through and the error messages are still terrible. It’s like an entirely new programming language and runtime. This “it’s just javascript” bullshit is so far from the reality now.
There is sooooo much you have to think about when writing a good React component with hooks and to ensure it remains performant and is bug free.
I really want to go back to basics. Using as little framework as possible.
I’d much rather something simple that I have full control over and that I can trace the entire execution with a debugger than all this magic crap.
I don’t even like JSX. I always pass an object in like: ‘<Foo {…fooProps} />’. Would much rather just use a literal js object.
I feel like React is a lot like dependency injection frameworks. The initialization code you would have to write without using one is actually very simple and straightforward.
Is it really that difficult to manually render components as needed? Do we actually need this huge runtime vdom overhead? Or any of these other compilers/transpilers.
There is sooooo much you have to think about when writing a good React component with hooks and to ensure it remains performant and is bug free.
I really want to go back to basics. Using as little framework as possible.
I’d much rather something simple that I have full control over and that I can trace the entire execution with a debugger than all this magic crap.
I don’t even like JSX. I always pass an object in like: ‘<Foo {…fooProps} />’. Would much rather just use a literal js object.
I feel like React is a lot like dependency injection frameworks. The initialization code you would have to write without using one is actually very simple and straightforward.
Is it really that difficult to manually render components as needed? Do we actually need this huge runtime vdom overhead? Or any of these other compilers/transpilers.
I have same opinion on react and after trying sveltekit I was really surprised how simple front end could look like. Now I can't even use anything except svelte and it's kinda sad but man it feels right for frontend.
I had an epiphany two years ago when GDPR came into effect. USA Today had this fancy page, but to comply with the new law they created an eu.* subdomain where they basically just showed articles. Text and images and very basic css, not even a fancy navigation. It was blazingly fast, just doing normal complete reloads between pages. I bet it was even cheap to make. So I realized, actually most of these things like SPAs are not truly needed, not even AMP was needed, they are just a bandaid on the complexity we add ourselves, and the kicker is, the users for the most part don't care about any of that. They just want to consume your content.
If your heart is still in it, I'd try to learn a skill that will be relevant forever. Something that would be a part of a university curriculum, not a framework. As others have pointed out, other areas of the industry are not necessarily better. An anegdote from a colleague there: he was maintaining a simple PHP backend where people bought stuff the company was selling. Another team built a replacement for this, real engineers, microservices, elasticsearch, containers, kubernetes, took forever. They switched it on and a week later noticed they are having less sales. They switched back to their legacy backend and everything was fine again.
edit: also I interviewed a bit last year and it was mostly that you'd think people are making space shuttles. You get asked all these technical questions, about JS and so, and then when I asked about, hey what do you actually do as a developer, what are your daily tasks. And the answers are, well we had to recently make our gallery page responsive. Sad.
If your heart is still in it, I'd try to learn a skill that will be relevant forever. Something that would be a part of a university curriculum, not a framework. As others have pointed out, other areas of the industry are not necessarily better. An anegdote from a colleague there: he was maintaining a simple PHP backend where people bought stuff the company was selling. Another team built a replacement for this, real engineers, microservices, elasticsearch, containers, kubernetes, took forever. They switched it on and a week later noticed they are having less sales. They switched back to their legacy backend and everything was fine again.
edit: also I interviewed a bit last year and it was mostly that you'd think people are making space shuttles. You get asked all these technical questions, about JS and so, and then when I asked about, hey what do you actually do as a developer, what are your daily tasks. And the answers are, well we had to recently make our gallery page responsive. Sad.
If your heart is still in it, I'd try to learn a skill that will be relevant forever.
Electrician
Electrician
I’ve bounced around between frontend and backend and devops, plus some iOS and one Android project. I’ve hopped in and out of various languages/frameworks. For the past year or so I’ve been using elixir which is my first big functional language job, as an example.
I would not worry about job opportunities. Here’s why:
General problem-solving abilities (eg. breaking down work into smaller chunks of work until you have something actionable) translate well to all kinds of software.
Skills like being able to communicate well with other engineers, product folks, etc is also similar.
Also, tech moves fast. Even if I were to have stuck with only frontend work, that landscape has changed so much in 14 years it’s not like the way I built things in 2008 is the same as 2022. Which is to say that regardless of staying in one area or moving around, I’ve always had to keep learning new things. I think other areas are like this too, eg Apple coming out with new ways of doing things every few years; Android SDKs having major changes over time.
Maybe I’m just feeling preachy at the moment but follow what excites you :)
I would not worry about job opportunities. Here’s why:
General problem-solving abilities (eg. breaking down work into smaller chunks of work until you have something actionable) translate well to all kinds of software.
Skills like being able to communicate well with other engineers, product folks, etc is also similar.
Also, tech moves fast. Even if I were to have stuck with only frontend work, that landscape has changed so much in 14 years it’s not like the way I built things in 2008 is the same as 2022. Which is to say that regardless of staying in one area or moving around, I’ve always had to keep learning new things. I think other areas are like this too, eg Apple coming out with new ways of doing things every few years; Android SDKs having major changes over time.
Maybe I’m just feeling preachy at the moment but follow what excites you :)
I transitioned from product work to platform/dev productivity work (think frameworks, internal tools) surrounding the web stack, which is a form of extreme specialization. It effectively means I'm not directly dealing w/ useEffect stale closure sort of crap, but instead I work w/ things like supply chain management, CI flakiness and build optimization, which involves developing a skillset that doesn't really fit into the "jack of all trades, master or one" narrative; it's more like developing depth in a wide array of obscure things plus a large dose navigating "working groups" to complement a workforce composed largely of React experts.
Career growth is currently primarily coming from increased internal impact at a large company. In terms of future career growth, most of the recruiter spam I get for Senior/Staff/Principal roles is below my current pay grade, so I expect that further growth will require shifting more and more into director track.
</two-cents>
Career growth is currently primarily coming from increased internal impact at a large company. In terms of future career growth, most of the recruiter spam I get for Senior/Staff/Principal roles is below my current pay grade, so I expect that further growth will require shifting more and more into director track.
</two-cents>
There are a few things I think you could do about it:
1. Find somewhere to work were they use a tech stack you feel is more appropriate.
2. Work at a smaller company where you have more say in the tech stack and tooling.
3. Find a company or team where someone else works on developer tooling and automation, so you only need to worry about site building.
4. Freelance and specialise in what you enjoy working with.
I work at a small (15 people) web agency where I have a large say in what we use. It's surprisingly little React/Vue, a bit of WordPress (not everyones favourite maybe) and a lot of backend work on APIs and admins in Laravel and plain PHP/HTML with some vanilla JS. Only about 10 percent of the clients ever care what stack we use.
All of our 60+ projects are setup the same way:
1. Pull down the repo and run "docker compose up" to start you local environment. Any composer or npm commands should be run through docker compose, so no local installs (except docker) are needed.
2. Push to staging branch to deploy to staging and merge to production branch to deploy to production.
1. Find somewhere to work were they use a tech stack you feel is more appropriate.
2. Work at a smaller company where you have more say in the tech stack and tooling.
3. Find a company or team where someone else works on developer tooling and automation, so you only need to worry about site building.
4. Freelance and specialise in what you enjoy working with.
I work at a small (15 people) web agency where I have a large say in what we use. It's surprisingly little React/Vue, a bit of WordPress (not everyones favourite maybe) and a lot of backend work on APIs and admins in Laravel and plain PHP/HTML with some vanilla JS. Only about 10 percent of the clients ever care what stack we use.
All of our 60+ projects are setup the same way:
1. Pull down the repo and run "docker compose up" to start you local environment. Any composer or npm commands should be run through docker compose, so no local installs (except docker) are needed.
2. Push to staging branch to deploy to staging and merge to production branch to deploy to production.
Not that there might a a huge market for it, but I'm going to attempt provide "least complicated solution" service to potential clients. While results might not look very fancy or have many animations, client will get working website faster and cheaper, and their customers will actually get superior experience, as website loads fast and doesn't do annoying things. Wish me luck.
I haven't done proper web development in a very long time, but I recently did some work with a front-end contractor. I made some self-effacing comment about not knowing frameworks and all that, and he gave me an amused look and said that he doesn't bother with them. He showed me his code, and it was all quite easy to read and looked very maintainable. His output is great, and to my knowledge we've almost never had post-deploy issues.
In my career, I've witnessed a lot of "framework"-style vanity projects (several were my idea). Fewer than 100% of them have been boondoggles (but that's the most generous estimate I'll give).
Food for thought, you might be better off without.
In my career, I've witnessed a lot of "framework"-style vanity projects (several were my idea). Fewer than 100% of them have been boondoggles (but that's the most generous estimate I'll give).
Food for thought, you might be better off without.
>> but I recently did some work with a front-end contractor
All no-framework-needed examples seem to boil down to having a simple enough problem needing just one (or few) front end developers. Would be good to hear how a larger team (say 10+) managed without one.
All no-framework-needed examples seem to boil down to having a simple enough problem needing just one (or few) front end developers. Would be good to hear how a larger team (say 10+) managed without one.
I noped out of the whole web development thing. I know its where the world moved to, but I always felt it was a technological wrong turn. Java applets were great, sure they had issues, but they were solvable. But the tech giants had to ruin it so now we have JS frameworks of the week built on top of a system never meant for rich clients.
I stuck with desktop thick clients for embedded devices and scientific computing. Mostly C++ / Qt or Java / Swing / JavaFx as a tech stack. Couldn't be happier, the tech stack isn't changing under my feat constantly and I can quickly bang out features.
I stuck with desktop thick clients for embedded devices and scientific computing. Mostly C++ / Qt or Java / Swing / JavaFx as a tech stack. Couldn't be happier, the tech stack isn't changing under my feat constantly and I can quickly bang out features.
That's why I stick with Ruby/Rails (while having 20 years of experience with variety of other languages/frameworks like C, C#, Go, JavaScript/React):
* "Optimized for Programmer Happiness"
* The Principle of Least Surprise
The knowledge you gained 10 years ago is still applicable, language/framework is not going anywhere soon. I kinda love what I do.
Shameless plug - my Ruby book https://leanpub.com/rubyisforfun/
* "Optimized for Programmer Happiness"
* The Principle of Least Surprise
The knowledge you gained 10 years ago is still applicable, language/framework is not going anywhere soon. I kinda love what I do.
Shameless plug - my Ruby book https://leanpub.com/rubyisforfun/
Have my upvote. Full stack frameworks like Rails, Laravel or Adonis are not "fashion" anymore apparently. And people keep wasting time reinventing the wheel because that's the fashionable thing to do.
Frontend development jumped the shark for sure.
Why can’t we go back to the old server-side template rendering and use progressive JS for interactivity? Just like the good old days.
Why can’t we go back to the old server-side template rendering and use progressive JS for interactivity? Just like the good old days.
You can do that if you're building a website, but people want to build desktop-class applications these days, and you can't just sprinkle some JS on server-side rendering and make it behave like that. Also, the same people with a lot of experience in backend work probably aren't that good at creating GUIs, and vice versa.
Then stop using these large frameworks. You don’t need them. They aren’t there to build your product for you. They are there to ease hiring.
When you return to vanilla JS you have the freedom to dramatically reduce your code size and increase performance.
See this comment upvoted 27 times: https://news.ycombinator.com/item?id=32914694
When you return to vanilla JS you have the freedom to dramatically reduce your code size and increase performance.
See this comment upvoted 27 times: https://news.ycombinator.com/item?id=32914694
> Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons?
Yes, I quit being a FE developer in 2019, after around 13 years. There were a few reasons, but one of them is just what you describe. Looking ahead to the rest of my career, I knew I wanted to make things and not be a manager, but I could not imagine myself living in the world that front end development had created for the next 20 years and also being happy.
In my case, I had been a hybrid developer / designer for most of my career (as a contractor, I juggled roles based on what the client needed). So, my mid-career change was that I just switched to not doing contracting, and only doing design.
It's not that I enjoy design more than programming, but I do think it's a more sustainable path. I never used to program in my spare time, but now I do it a lot because I miss the fun parts. I'm sure as hell not doing React on the weekends, though.
The design world has its own frustrations, but so far I think it was a great choice.
Yes, I quit being a FE developer in 2019, after around 13 years. There were a few reasons, but one of them is just what you describe. Looking ahead to the rest of my career, I knew I wanted to make things and not be a manager, but I could not imagine myself living in the world that front end development had created for the next 20 years and also being happy.
In my case, I had been a hybrid developer / designer for most of my career (as a contractor, I juggled roles based on what the client needed). So, my mid-career change was that I just switched to not doing contracting, and only doing design.
It's not that I enjoy design more than programming, but I do think it's a more sustainable path. I never used to program in my spare time, but now I do it a lot because I miss the fun parts. I'm sure as hell not doing React on the weekends, though.
The design world has its own frustrations, but so far I think it was a great choice.
Don't tell anyone. They'll think you're the problem. Just smile and install the latest tooling.
[deleted]
I’m a journalist who learnt to make websites back in the day and never bothered with newer, fancier technologies. My background isn’t suited to take on big projects, but I still have lots of fun designing little projects, such as my personal page[1] and weblogs[2].
Bonus point: these websites are always super snappy and easy to navigate. I can’t understand big projects based on React and other technologies that, no matter what happens on development, result in slow, busy, and generic websites.
[1] https://rodrigo.ghed.in [2] https://notes.ghed.in
Bonus point: these websites are always super snappy and easy to navigate. I can’t understand big projects based on React and other technologies that, no matter what happens on development, result in slow, busy, and generic websites.
[1] https://rodrigo.ghed.in [2] https://notes.ghed.in
IMO, maybe some technologies do make sense for certain team sizes.
I haven't worked much with React, although every time I did, I felt like everything was overkill.
Then again, I've worked with k8s and while other people may think k8s is overkill, for a team our size – hundreds of devs working on separate microservices, I think it makes sense.
It doesn't make sense for a small startup, but once you get to a certain size, the pure human element forces you to look for alternatives. While complex, k8s is actually a great solution to a lot of the problems we were facing.
It's possible that React fits that same need, and while it may seem like overkill to me, maybe I don't know enough about it.
I haven't worked much with React, although every time I did, I felt like everything was overkill.
Then again, I've worked with k8s and while other people may think k8s is overkill, for a team our size – hundreds of devs working on separate microservices, I think it makes sense.
It doesn't make sense for a small startup, but once you get to a certain size, the pure human element forces you to look for alternatives. While complex, k8s is actually a great solution to a lot of the problems we were facing.
It's possible that React fits that same need, and while it may seem like overkill to me, maybe I don't know enough about it.
Web development is complex and has always been. 15 years ago you'd deal with complex hacks to work around the table based layout mess, the horrible browser APIs, javascript's prototype inheritance, Apache configuration and, god forbid, networks of .htaccess files.
10 years ago you'd deal with communicating stuff between language borders, what interaction to handle in javascript, what in ruby/php/perl/whatever and how to interact between the languages.
Now you deal with build processes, transpilers, bundle size optimization, framework configuration and broken react state updates.
It's intrinsically complex, deal with it.
10 years ago you'd deal with communicating stuff between language borders, what interaction to handle in javascript, what in ruby/php/perl/whatever and how to interact between the languages.
Now you deal with build processes, transpilers, bundle size optimization, framework configuration and broken react state updates.
It's intrinsically complex, deal with it.
I think that developers will always complicate things to the point where they can't complicate it any further. If something is already complex (due to browser incompatibilities, weird HTML/CSS/JS bugs, etc.) then developers can't raise the complexity much. Now that those issues have mostly been resolved, we've invented build systems and weird declarative/functional frameworks to bring it back up to that same complexity level.
I don't know how it happens, but you'll never escape it. Just give up and enjoy the suck. Do yourself a favor and start a side hustle project using plain javascript and python or something. But don't get too attached to it - if it gains traction and you get funding and hire a few developers, they'll rewrite your app in the latest trendy pile of abstractions. And the suck will be back. Just move on.
OK, so I am late to the party, but I have some thoughts.
One, if you search for the word complicated on HN, the top hit is the same complaint from 2019. This isn't getting better. https://news.ycombinator.com/item?id=20637849
Two, from the discussion in February, web development is literally the worst job in the USA for degree of change in complexity / lack of ability to build career capital over time. This is (and will in the future) driving talented people out of the profession. https://news.ycombinator.com/item?id=24910949 https://whoisnnamdi.com/never-enough-developers/
Three, I have a pet theory. Indulge me. We have noted before that there is a lot of overlap between software engineering contracting and, say, carpentry. Key difference: once a cabinet is done, it's done. There isn't any need for follow up, enhancements, new requirements, changes. However, if you make a software project so complicated that only you or someone with very similar experience can make changes to it, you drive up the likelihood of capturing the benefit of a future income stream. This is also the impetus behind very complicated frameworks: the more people adopt your complicated solution, the more likelihood they drive business towards you.
Lastly, this crowd isn't going to like this, but the solution in other engineering disciplines is standardisation and opinionated off the shelf solutions. It's that or wrestling with complexity forever.
One, if you search for the word complicated on HN, the top hit is the same complaint from 2019. This isn't getting better. https://news.ycombinator.com/item?id=20637849
Two, from the discussion in February, web development is literally the worst job in the USA for degree of change in complexity / lack of ability to build career capital over time. This is (and will in the future) driving talented people out of the profession. https://news.ycombinator.com/item?id=24910949 https://whoisnnamdi.com/never-enough-developers/
Three, I have a pet theory. Indulge me. We have noted before that there is a lot of overlap between software engineering contracting and, say, carpentry. Key difference: once a cabinet is done, it's done. There isn't any need for follow up, enhancements, new requirements, changes. However, if you make a software project so complicated that only you or someone with very similar experience can make changes to it, you drive up the likelihood of capturing the benefit of a future income stream. This is also the impetus behind very complicated frameworks: the more people adopt your complicated solution, the more likelihood they drive business towards you.
Lastly, this crowd isn't going to like this, but the solution in other engineering disciplines is standardisation and opinionated off the shelf solutions. It's that or wrestling with complexity forever.
> I have a few years of experience working mostly on the frontend with React and am getting more and more frustrated with all the added layers of complexity needed to work with most common frontend frameworks.
It's complicated because you (or your team) are using very, very low level tools, which were made for large teams, working at large companies with complex architectures adapted to fit more people working on the problem, with large budgets where all of this can be afforded. In fact, you might need to use those low level tools in most of those environments. I'm talking about React, GraphQL, SPA architecture, microservices built with microframeworks (some times in pretty low level languages for the Web such as Go, etc...)
Try Rails, Laravel or, if you want to stay in the JavaScript world: Adonis.js. Pick a modern "sprinkles" library for the parts you need interactivity such as htmx, unpolyor alpinejs (or Hotwire if using Rails). And boom... Everything is simple again. Just not trendy and fashion.
It's complicated because you (or your team) are using very, very low level tools, which were made for large teams, working at large companies with complex architectures adapted to fit more people working on the problem, with large budgets where all of this can be afforded. In fact, you might need to use those low level tools in most of those environments. I'm talking about React, GraphQL, SPA architecture, microservices built with microframeworks (some times in pretty low level languages for the Web such as Go, etc...)
Try Rails, Laravel or, if you want to stay in the JavaScript world: Adonis.js. Pick a modern "sprinkles" library for the parts you need interactivity such as htmx, unpolyor alpinejs (or Hotwire if using Rails). And boom... Everything is simple again. Just not trendy and fashion.
I worked in web development for about a year, then switched to general devtools and CI/CD, then to infrastructure orchestration work on deployment, Kubernetes, service proxies, deployment. After that I joined a startup and worked on backend, mobile apps (Android), and now I’m back to working on complicated frontend.
I think the fundamental reason this is true is because devs over engineer on purpose to make a meal out of simple things. Pretending that your thing will need all the bells and whistles means you can claim you did all sorts of glorious things on your resume and take yourself all that much more seriously.
I can't believe no one is mentioning Django.
Still in use, still killing it.
Still in use, still killing it.
Django is great, I've used it for many, many years until about 6 years ago.
The problem I find with Django is that it's a purely backend framework. The moment you want to use their highly outdated templating system it becomes evident it's from the 00s. It doesn't even handle assets bundling.
Laravel and Rails instead can be considered more "full stack" solutions, as both have really nice frontend stories too.
But Django is great if you want to build a backoffice with the Admin and django-rest-framework. That's how we used it back in the day anyways.
The problem I find with Django is that it's a purely backend framework. The moment you want to use their highly outdated templating system it becomes evident it's from the 00s. It doesn't even handle assets bundling.
Laravel and Rails instead can be considered more "full stack" solutions, as both have really nice frontend stories too.
But Django is great if you want to build a backoffice with the Admin and django-rest-framework. That's how we used it back in the day anyways.
I had a great experience with Hotwired Turbo and Stimulus.
I completely agree with you. While I don't have a solution, I have a related question on next.js. (Shortlisted next.js since I liked the overall design). Can someone help? Posting here since its related.
Background: Primarily a backend developer. I had used java swing and struts long ago. Played around with vanilla react and next.js (through vercel). I had a look at the various samples provided by vercel. But I struggle with the syntax and hence finding it very difficult to write something from scratch. How do you guys write a new application in next.js?. Do you hand code it?. Also, is CSM a must ? Most of the examples in vercel are simple applications. How does one design a slightly advanced user interface from scratch?
Background: Primarily a backend developer. I had used java swing and struts long ago. Played around with vanilla react and next.js (through vercel). I had a look at the various samples provided by vercel. But I struggle with the syntax and hence finding it very difficult to write something from scratch. How do you guys write a new application in next.js?. Do you hand code it?. Also, is CSM a must ? Most of the examples in vercel are simple applications. How does one design a slightly advanced user interface from scratch?
This is why new frameworks are created. Someone gets upset over X, in this case complexity, and then creates something to fix the situation. That's why React came to be. The incompatibilities between frontends made it hard to produce a good product so eventually we get what we have.
The fix is to reevaluate and start over. That's way harder than continuing to use what's available so things continue as they have been.
I haven't used React for a while but it definitely made developing for different browsers much easier but it you wanted to do a simple app it was way harder to use it. It all comes down to what you are creating and reaching for the right tool.
The fix is to reevaluate and start over. That's way harder than continuing to use what's available so things continue as they have been.
I haven't used React for a while but it definitely made developing for different browsers much easier but it you wanted to do a simple app it was way harder to use it. It all comes down to what you are creating and reaching for the right tool.
It's simple, quit web development and slide into other niches. I found mine in blockchain and smart contract development. Now I find myself solving interesting problems rather than trying to make 1000 frameworks and libraries work.
Everything since static HTML has been a mistake.
I wrote a js lib similar to HTMX, which I call HTMF[1]. Unlike HTMX I try to stay as close to the metal of the current semantics as possible. So, all interactions are based off of forms. I also tried to keep the wording similar to HTML/JS semantics. It's pretty small lib but pretty amazing how far I can get with it. These days I mainly build offline-first apps with it. But I built it in such a way that it can easily be a progressive enhancement to an MPA app.
[1]: https://github.com/jon49/htmf
[1]: https://github.com/jon49/htmf
After jumping like a flea between frameworks for, what, 10 years (was an amateur dev), I came to the conclusion that I will use one well maintained framework for everything.
I settled on Quasar (based on Vue and recently also Vite).
If I need to have [a page with a button | anything really] I will use Quasar (and Typescript).
Yes, it is overkill. Yes, it is not lean. Yes, it is simpler to do it in 5 lines of vanilla JS.
But OTOH I always know what I will get, do not need to guess, know the time it will take me to write something.
And, notably, frees me from thinking what to use now. I have the hammer for anything that remotely looks like a nail, even if it is actually a screw.
I settled on Quasar (based on Vue and recently also Vite).
If I need to have [a page with a button | anything really] I will use Quasar (and Typescript).
Yes, it is overkill. Yes, it is not lean. Yes, it is simpler to do it in 5 lines of vanilla JS.
But OTOH I always know what I will get, do not need to guess, know the time it will take me to write something.
And, notably, frees me from thinking what to use now. I have the hammer for anything that remotely looks like a nail, even if it is actually a screw.
I feel you. I feel this since 2014 actually. Same exact DX - Developer Experience.
Switched from web backend to unreal engine game programming dev. Havent started yet on the new gig but one of my main motivations to not do web stuff anymore was having to deal with people introducing unnecessary layers between you and what you want to do in code, all that time. It is just a thing because web companies can afford both the extra cost and extra performance hit that these "best practices" incurr (and cultural inertia, maybe), while in games, I believe, there isnt space for any of that, you must start simple to complex because of budgets. Not the other way around.
Like you I tend to agree that the effort delivering front end projects often seems to outweigh the value added over recent years. I can think of half a dozen projects I've seen over the last few years where the effort teams put into figuring out stacks of new tools was an order of magnitude greater than the value added (and most of the projects failed to deliver or became haunted forests soon afterwards which is even worse!) It's not sustainable, businesses are wasting far too much money and too many talented developers are left feeling inadequate.
The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.
With that in mind, my advice would be:
1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)
2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.
3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.
The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.
With that in mind, my advice would be:
1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)
2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.
3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.
Having complexity without understanding the “why” behind the complexity is a major issue. My best advice is to balance pragmatism with simplicity and always prioritize personal learning and understanding. If you use React, ask yourself why. You will eventually learn a lot of microtopics the more you do this. I like working in infra because microtopics are treated as first class. There is no shortage of articles about database consistency models for example. Learn the microtopics and you future proof yourself from mindless tech decisions
Could you give some examples of the complexities you're tired of?
Not OP but I'll give you an example concerning a project that used Material UI which is a React UI component library.
For one, we had to rewrite the app 3 times because the library switched from Less, to 2 different css-in-js solutions across 3 different major versions.
Then we switched to server side rendering and suffered some weird glitches. Turns out, when using SSR, styles get rendered twice: once on the server and once in the browser. So you have to write a custom logic to remove the styles that are rendered on the server.
What I'm trying to say is that React was invented at Facebook to solve problems they were having but the industry was too quick to adopt it as a solution for their own problems. Facebook can afford to rewrite a piece of software 100 times because of their unlimited budget. They can also deal with all the bs that comes with frontend frameworks because of their ability to throw an unlimited amount of engineers at a problem.
Small company with 10 engineers? Just use something appropriate for problems you're trying to solve at your budget.
For one, we had to rewrite the app 3 times because the library switched from Less, to 2 different css-in-js solutions across 3 different major versions.
Then we switched to server side rendering and suffered some weird glitches. Turns out, when using SSR, styles get rendered twice: once on the server and once in the browser. So you have to write a custom logic to remove the styles that are rendered on the server.
What I'm trying to say is that React was invented at Facebook to solve problems they were having but the industry was too quick to adopt it as a solution for their own problems. Facebook can afford to rewrite a piece of software 100 times because of their unlimited budget. They can also deal with all the bs that comes with frontend frameworks because of their ability to throw an unlimited amount of engineers at a problem.
Small company with 10 engineers? Just use something appropriate for problems you're trying to solve at your budget.
That's very fair, do you still think it was a net positive opposed to writing your own component library?
https://mui.com/system/styles/basics/ It looks like MUI had some decent intentions in their changes.
https://mui.com/material-ui/guides/server-rendering/#mui-on-... It also looks like they called out how to address the SSR issue (maybe they recently added these docs?).
I kind of accept this type of friction as a part of libraries changing (As long as the upgrade paths aren't insane).
https://mui.com/system/styles/basics/ It looks like MUI had some decent intentions in their changes.
https://mui.com/material-ui/guides/server-rendering/#mui-on-... It also looks like they called out how to address the SSR issue (maybe they recently added these docs?).
I kind of accept this type of friction as a part of libraries changing (As long as the upgrade paths aren't insane).
I think we would be much better off using traditional html, bootstrap scss, and some jquery for interactions. But nobody likes to be boring so React it is.
React itself isn't really the problem because there are some valid use cases for it. However, it's currently being thrown at every web development problem even when there are better and more stable solutions.
But if I had to use React today, I'd stay away from MUI for sure since they constantly demonstrated a lack of maturity.
React itself isn't really the problem because there are some valid use cases for it. However, it's currently being thrown at every web development problem even when there are better and more stable solutions.
But if I had to use React today, I'd stay away from MUI for sure since they constantly demonstrated a lack of maturity.
React tooling is only getting easier, esp. considering anyone coming from the age of Webpack. The recent wave of framework innovation has been about DX by bundling things together into one cohesive experience. Also, nobody is required to keep up with the bleeding edge unless you're a framework author trying to breakout. If you don't like the marginal benefits provided by some performance story in React, then don't do it.
There are also more easier-than-Heroku competitors than ever.
There are also more easier-than-Heroku competitors than ever.
That this realistic comment is showing downvotes is worrisome about the general aptitude of HN wrt front-end dev. Good ol' Gell Mann Amnesia...
[deleted]
I experience the same. I mostly stopped with web development because of this, and get a lot more satisfaction out of static pages, because it is so simple (and fast!).
There is a huge shortage of developers on corporate information security teams. Many organizations' CorpSec teams spend an egregious amount of time toiling in manual processes. In infosec, that is why you constantly hear of burnout.
If you wanted to switch into information security as a developer, many well-paying, well-known orgs would welcome you in with open arms in some kind of automation developer role. I have never felt better about my job prospects.
If you wanted to switch into information security as a developer, many well-paying, well-known orgs would welcome you in with open arms in some kind of automation developer role. I have never felt better about my job prospects.
This is very interesting. Where can I start and learn more about it?
This article is a really brief primer on this line of work. A lot of it is working with Python, JavaScript, APIs, and building custom solutions to get different COTS security tools and things like Jira to talk to each other. It may not be for everyone but I really enjoy it.
https://www.cadosecurity.com/the-next-in-demand-job-title-se...
https://www.cadosecurity.com/the-next-in-demand-job-title-se...
I find it very much interesting as well. Would you be available for an informal chat?
I focus on backend and native GUI development, when required to do Web GUI development vanilaJS + SSR are my tools for the last 20 years, I leave the deep knowledge of the FE framework of the day to the FE teams.
To this day I have been lucky to always been able to find something, maybe because I've always embraced a polyglot toolbox and not being int a silo as XYZ Developer.
To this day I have been lucky to always been able to find something, maybe because I've always embraced a polyglot toolbox and not being int a silo as XYZ Developer.
Yes, I did exactly this and for the same reasons. I left web development in 2015 when the tooling was starting to get a bit silly. I had an opportunity to move into devops and system administration at the same company and team so I took it. I'm still finding it enjoyable and I do like how much more powerful the point of simplicity is in this field.
>Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons?
I became a manager of engineers, so now these all are not my problem anymore. I'll do my tinkering in Factorio and Entropy TD, and I build as big of a spaghetti as I'd like.
I became a manager of engineers, so now these all are not my problem anymore. I'll do my tinkering in Factorio and Entropy TD, and I build as big of a spaghetti as I'd like.
Amen. I would even say the same thing about UI/UX design, with tight coupling with react components with naming conventions and tokens. Overly complex design systems.
It all sounds great in theory, but it comes with so many baggage, and only tends to work in certain SV type companies.
It all sounds great in theory, but it comes with so many baggage, and only tends to work in certain SV type companies.
It happens on the backend too. For the infrastructure too. Honestly, maybe unpopular opinion but it's why I went into management. I was just tired of gluing together dozens of libraries to parse/format data around and deal with this crap.
This entire thread would look exactly the same if the main topic was cybersecurity. :)
Server side rendering ftw
Use a component based framework like Primefaces and you’ll realize you can push code way about 10x faster than a js stack.
Web-development is still better than Mobile Development, just use NextJS and make your websites/webapps.
Everything is complex and many analysis looks like CSI investigations.
been there, just move to Svelte XD
simplicity is king
don't use tools just because it's popular but make your productivity plummet..
don't use tools just because it's popular but make your productivity plummet..
I was active in web application development three times (1999, 2007 and circa 2010). Every time, I was horrified by the number of patches, workarounds and conditional code that were needed when doing "pure" web development. But at the same time, every application I developed was a little easier than the previous one, for four reasons.
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
It's business-generated complexity, not complexity out of necessity. And I don't mean business made the complexity directly, but it's an indirect effect of trying to commodify developer jobs.
If you have a job posting describing "work on our website" you get all sorts of random candidates that have no real place in your company, but when you say "developer with framework XYZ experience" you can skip everything, judge their framework experience and move on (or so it is thought to work).
This means that to be attractive you need to use it as a developer, but inside a company this stuff has to be used to make sure that the current developer(s) can be replaced easily (not how it realistically works beyond CRUD apps), and expanding the workforce is easier because attracting developers with technology keywords is easier than business job descriptions.
End result: using technology not because it's the best fit, but because it is off-the-shelf. Essentially a modern version of using Oracle and Windows NT 3.51 back in the day, you're using it because it's an easy off-the-shelf keyword, not because it actually has anything to do with what you are technically trying to get done. Enterprise IT and HR shaking hands all over again.
Some more expansion on this topic (story time):
Generally when you are large enough as a team or business unit to have lots of collaboration, you need some way to exchange information and ideas, and work together using similar-ish principles. That can mean various things, from all using the same OS and IDE to having up-to-date API documentation and integration tests. This means that if you have to transport some idea, project or application across people (and teams) you need a method and format to do so.
This nearly automatically also means you can't do solo yolo all day and you need to have rules and packaging standards so you don't end up figuring out what Pete did on his machine so it works on Jack's machine but not Jane's. Chroot-in-a-tarball works, virtual machine images, maybe autotools with a bunch of setup scripts. But most of the older methods all have the same problem: your systems all need to be rather similar to work with it, and you need to have systems knowledge to make use of it.
With the expansion of the workforce, that becomes more and more scarce, to the point where most Junior and Medior engineers have no clue how their computer actually works, how to manage an operating system, how how to understand the influence of externalities (be it them influencing other teams, or the other way around). People with less experience are easier to 'create' (yes, I know, we're not actuallt manufacturing people on-demand for work), as it requires less affinity, less time, and less education resources. So we can get more of them, and as long as they are put in an environment where they don't need to be as capable as 'full fat' engineers, the business can keep running.
So, what do we do? We package and standardise. First with environments, we have virtual machines, images, packer, and can see those local virtual machines with ansible and saltstack and if it works there, the project will work on other workstations and servers just the same, since it was all provisioned the same. No more guessing. But this is a really heavy method of doing this, and the greybeards will complain that just using some file protocol to directly edit something or a simple jail or chroot was much lighter (faster, less resources etc). At the same time, from a security perspective, sandboxing stuff gets more traction, and with namespaces and control groups we also get docker (pre-OCI), which gets a bunch of people excited because you can now make transportable environments that are essentially jails, but without having to know anything about jails or bsd and it works on Linux!
Parallel to this, we get various tools for dependency management, mainly derived from the same concepts that drive dpkg/apt and rpm/yum, because it worked so well for system packages, why not use it for nearly every language under the sun? This gets into DLL-hell rather quickly, contaminates the operating system by installing packages needed for your projects globally for the entire system, so now whenever you switch to a different projects you basically have to reinstall. Boo! But luckily someone heard of this fancy new container thing and you can just do all of that stuff in there!
Now we can simply create those project environments as container images (got some real traction once OCI was a thing), so an engineer working on some new feature has even less of a requirement regarding their skillset. Just hire someone who can run docker containers and work on framework XYZ! Tons of those available. So instead of having teams with 5 highly skilled workers with deep knowledge and a high cost, you just get 3 Juniors for bulk work, 1 medior for checking their work and 1 senior that's in that classic "know as much as possible" bucket do mitigate any complex issues that may arise.
Fast forward to today, the new greybeards are the senior engineers of a decade ago, less and less new people with deep knowledge have been added to the workforce, but large masses of either highly specialised or shallowly trained people are being hired. They are not unskilled, but just skilled for a specific piece of the business, because that works for other departments so why not IT? And there is a shortage after all...
The now rare and in high-demand deep knowledge engineers are tired of getting the same questions for the same architectural problems and same business complexities, so they come up with software frameworks that they can apply to the problem. It doesn't matter if the other team members have a varying gradient of understanding of the details of the solution, as long as the tickets get closed and added value is perceived by non-technical people. Those same people may see those framework names, and recognise them in various important places around the business. Hiring more people now focuses on making sure that they will be able to work with this stuff, because it's what the business is already using after all. And to be attractive, new engineers are trained to use those frameworks.. and now the cycle just repeats itself.
Moral of the story: it's a mix of race to the bottom, commodification, shortage and standardisation. That last one is important, because using standards is preferred in a risk-averse environment, and most businesses are just that.
If you have a job posting describing "work on our website" you get all sorts of random candidates that have no real place in your company, but when you say "developer with framework XYZ experience" you can skip everything, judge their framework experience and move on (or so it is thought to work).
This means that to be attractive you need to use it as a developer, but inside a company this stuff has to be used to make sure that the current developer(s) can be replaced easily (not how it realistically works beyond CRUD apps), and expanding the workforce is easier because attracting developers with technology keywords is easier than business job descriptions.
End result: using technology not because it's the best fit, but because it is off-the-shelf. Essentially a modern version of using Oracle and Windows NT 3.51 back in the day, you're using it because it's an easy off-the-shelf keyword, not because it actually has anything to do with what you are technically trying to get done. Enterprise IT and HR shaking hands all over again.
Some more expansion on this topic (story time):
Generally when you are large enough as a team or business unit to have lots of collaboration, you need some way to exchange information and ideas, and work together using similar-ish principles. That can mean various things, from all using the same OS and IDE to having up-to-date API documentation and integration tests. This means that if you have to transport some idea, project or application across people (and teams) you need a method and format to do so.
This nearly automatically also means you can't do solo yolo all day and you need to have rules and packaging standards so you don't end up figuring out what Pete did on his machine so it works on Jack's machine but not Jane's. Chroot-in-a-tarball works, virtual machine images, maybe autotools with a bunch of setup scripts. But most of the older methods all have the same problem: your systems all need to be rather similar to work with it, and you need to have systems knowledge to make use of it.
With the expansion of the workforce, that becomes more and more scarce, to the point where most Junior and Medior engineers have no clue how their computer actually works, how to manage an operating system, how how to understand the influence of externalities (be it them influencing other teams, or the other way around). People with less experience are easier to 'create' (yes, I know, we're not actuallt manufacturing people on-demand for work), as it requires less affinity, less time, and less education resources. So we can get more of them, and as long as they are put in an environment where they don't need to be as capable as 'full fat' engineers, the business can keep running.
So, what do we do? We package and standardise. First with environments, we have virtual machines, images, packer, and can see those local virtual machines with ansible and saltstack and if it works there, the project will work on other workstations and servers just the same, since it was all provisioned the same. No more guessing. But this is a really heavy method of doing this, and the greybeards will complain that just using some file protocol to directly edit something or a simple jail or chroot was much lighter (faster, less resources etc). At the same time, from a security perspective, sandboxing stuff gets more traction, and with namespaces and control groups we also get docker (pre-OCI), which gets a bunch of people excited because you can now make transportable environments that are essentially jails, but without having to know anything about jails or bsd and it works on Linux!
Parallel to this, we get various tools for dependency management, mainly derived from the same concepts that drive dpkg/apt and rpm/yum, because it worked so well for system packages, why not use it for nearly every language under the sun? This gets into DLL-hell rather quickly, contaminates the operating system by installing packages needed for your projects globally for the entire system, so now whenever you switch to a different projects you basically have to reinstall. Boo! But luckily someone heard of this fancy new container thing and you can just do all of that stuff in there!
Now we can simply create those project environments as container images (got some real traction once OCI was a thing), so an engineer working on some new feature has even less of a requirement regarding their skillset. Just hire someone who can run docker containers and work on framework XYZ! Tons of those available. So instead of having teams with 5 highly skilled workers with deep knowledge and a high cost, you just get 3 Juniors for bulk work, 1 medior for checking their work and 1 senior that's in that classic "know as much as possible" bucket do mitigate any complex issues that may arise.
Fast forward to today, the new greybeards are the senior engineers of a decade ago, less and less new people with deep knowledge have been added to the workforce, but large masses of either highly specialised or shallowly trained people are being hired. They are not unskilled, but just skilled for a specific piece of the business, because that works for other departments so why not IT? And there is a shortage after all...
The now rare and in high-demand deep knowledge engineers are tired of getting the same questions for the same architectural problems and same business complexities, so they come up with software frameworks that they can apply to the problem. It doesn't matter if the other team members have a varying gradient of understanding of the details of the solution, as long as the tickets get closed and added value is perceived by non-technical people. Those same people may see those framework names, and recognise them in various important places around the business. Hiring more people now focuses on making sure that they will be able to work with this stuff, because it's what the business is already using after all. And to be attractive, new engineers are trained to use those frameworks.. and now the cycle just repeats itself.
Moral of the story: it's a mix of race to the bottom, commodification, shortage and standardisation. That last one is important, because using standards is preferred in a risk-averse environment, and most businesses are just that.
Can I ask what exactly you're tired of in the frontend world?
Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?
Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.
Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.
Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.
FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.
Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?
TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!
Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?
Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.
Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.
Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.
FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.
Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?
TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!
Thanks for the great post from a different perspective. I kind of agree with you. But the problem is that there are way too many options for a given task, and it's difficult to evaluate all and zero in on something. I need a small help from you. I am new to web development. After a lot of research, I have zeroed in next.js. I loved the overall design, api/workers integration, deployment using vercel. But struggling to design something from scratch. Also, finding the jsx syntax very complex. (I come from java background). Could you recommend a good headless cms for working with next.js? This is for hoppy project, not for day work.
We evaluated a dozen or so for work last year, and my two personal favorites were DatoCMS and GraphCMS (now called Hygraph). A bit more details in this thread here (https://news.ycombinator.com/item?id=32993835), but basically DatoCMS had a great out of the box editor experience, while Hygraph had a slightly better/more flexible data model and GraphQL mutability. There are a LOT of options out there now though... you can see a big list here (not my site): https://cms-comparison.io/#/card
If I were you, I'd just pick a CMS and try to get started with a demo project. Here's Dato's tutorials for Next.js, including videos and step by steps to start from: https://www.datocms.com/docs/next-js
And here are a bunch of starter templates if you just wanna clone one and see how it works: https://www.datocms.com/marketplace/starters
Once you make a simple prototype in one, you can begin to understand how they tie together with the frontend. And then you can swap out any backend (or any frontend) you like once you understand the nuances better.
As for JSX, I can't really help there because I never learned Java, but it's basically just HTML + Javascript. LinkedIn Learning has a bunch of great videos on how to learn React, and there are free resources out there too (not sure about quality though). At the end of the day JSX is just a templating language that lets you inject JS into HTML. React is more than just JSX and that can get complicated though, so some tutorials might be helpful (or look at the example templates above).
If I were you, I'd just pick a CMS and try to get started with a demo project. Here's Dato's tutorials for Next.js, including videos and step by steps to start from: https://www.datocms.com/docs/next-js
And here are a bunch of starter templates if you just wanna clone one and see how it works: https://www.datocms.com/marketplace/starters
Once you make a simple prototype in one, you can begin to understand how they tie together with the frontend. And then you can swap out any backend (or any frontend) you like once you understand the nuances better.
As for JSX, I can't really help there because I never learned Java, but it's basically just HTML + Javascript. LinkedIn Learning has a bunch of great videos on how to learn React, and there are free resources out there too (not sure about quality though). At the end of the day JSX is just a templating language that lets you inject JS into HTML. React is more than just JSX and that can get complicated though, so some tutorials might be helpful (or look at the example templates above).
This stems from the fact that many in web dev are not really engineers. There’s a lot of reinventing the wheel and cult like following of various tech influencers. Instead of extending existing libraries people just fork repositories, add minor changes, and advertise them as new. A lot of architectural patterns are just a soup of concepts thrown around without proper planning or understanding of dry or solid.
A big problem is for anything to be successful it had to be similar enough to the last thing. E.g. all the new frameworks that look and feel like React. Every new thing is constrained and sticky taped onto the older thing. So no one can ever step back and ask themselves what the truly ideal thing is.
Try Blazor. Backens C#, frontend C$, shared project for DTO classes, 0 other required dependencies, no 1GB node-modules folder. Easy and fast.
Good, mor job security for us.
I was active in web application development three times (1999, 2007 and circa 2010). Every time, I was horrified by the number of patches, workarounds and conditional code that were needed when doing "pure" web development. But at the same time, every application I developed was a little easier than the previous one, for four reasons.
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
I think you should try out Angular. React ecosystem is a mess and needs extremely experienced developers to produce software that doesn't suck.
Angular, on the other hand, it's quite simple and helps you to get the shit done.
Angular, on the other hand, it's quite simple and helps you to get the shit done.
[deleted]
I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore which really doesn’t make me excited to work on much in this space now.
The one redeeming quality of doing this kind of work is that it is in very high demand, and I worry that the price of becoming more specialized or doing something more enjoyable with less bloat is that it becomes much harder to find jobs.
Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons? If anyone considers themselves very specialized in an area, do you worry about job opportunities?