I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Is the frontend so complicated that we have given up all hope of drag and drop editors?
No, they can actually make the frontend more complicated in multiple ways.
The code they generate often contains embedded metadata that's dependent on where and when it was generated. This is problematic when you want to keep it under version control, because the generated code is not trivially reproducible and your patches will have lines that don't actually have anything to do with the changes.
It's unfortunately very typical that you have to reformat the code they generate to make it comply with your project's coding standards (at least, when it's not in some custom language).
It's not unusual for them to be very picky about the code that is fed in as the initial state of the layout to edit. This means in turn you have to understand how the editor works to be able to edit the code by hand and have it still be editable by the editor afterwards.
Quite a few either offer too much granularity in control placement, or not enough, so you either end up with controls on a larger grid than you intended, or have trouble making sure everything is lined up correctly.
They don't work on the command line. Sounds stupid, but this is a huge reason for quite a few people to not want to use them (I'm a good example of such a person, my desktop environment is used as little more than a multiplexer for terminal emulators and a web browser when I'm coding).
Some of them still don't support scaled relative positioning (which is kind of important for portable UI's).
They automate what is honestly one of the least difficult parts of coding in many cases. Unless you're dealing with old systems or very poorly designed API's, getting the UI layout to a reasonable state is often exponentially easier than coding the actual behavior of the application and binding the UI to that.
Keep in mind also that the heyday for these things was the late 1990's to the early 2000's, a time when there was an ongoing push to make it so that people who didn't understand computers at a low level could still program by avoiding actually writing code. As that went on though, a lot of the smarter businesses realized that this was a Bad Idea (yes, it's that bad of an idea that it warrants capital letters), both because of the points I mentioned above, and the fact that letting people who don't actually understand computers at a low level do your software development leads to all kinds of long-term issues, and as a result there's been a pretty steady shift away from them for anything that isn't really graphic-design work instead of programming.
Hi! I'm Rohan, a Full Stack Software Engineer, with a background of working with Deep Learning and AI, who loves to use his skills to create products that are at the intersection of all of these!
No, they can actually make the frontend more complicated in multiple ways.
Keep in mind also that the heyday for these things was the late 1990's to the early 2000's, a time when there was an ongoing push to make it so that people who didn't understand computers at a low level could still program by avoiding actually writing code. As that went on though, a lot of the smarter businesses realized that this was a Bad Idea (yes, it's that bad of an idea that it warrants capital letters), both because of the points I mentioned above, and the fact that letting people who don't actually understand computers at a low level do your software development leads to all kinds of long-term issues, and as a result there's been a pretty steady shift away from them for anything that isn't really graphic-design work instead of programming.
All great points which I could not have thought of myself!
Thanks for helping me understand!
Yep, relative layouts, version coding, and not being able to follow coding standards are a biggie!
The reasons or the views I had in mind were for smaller projects, but it's great to understand another - more experienced take on things!