5 ms·

I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bi

I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best, frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS. As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity. That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.

dbmikus 6y ago
I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * search Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.
- unclebucknasty 6y ago
  >Over the next 10 years I think we're going to see more and more codeless SaaS services Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now. I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names). But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever. Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win. Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.
  - dbmikus 6y ago
    I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will: * pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together * they will differentiate themselves from their competitors based on their product offering and branding, less so on tech So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.
- groestl 6y ago
  It might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.
  - TeMPOraL 6y ago
    > the process has a tendency to self correct over time - creative destruction and all that I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.
    - searchableguy 6y ago
      Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?
      - ComputerGuru 6y ago
        Let’s hope the public sector isn’t the model that the software industry is following.
        TeMPOraL 6y ago
        Why, but it is. It's not the public sector that's causing these problems, it's the private companies that fulfill government contracts.
- int_19h 6y ago
  It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD. Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.
  - jimbob45 6y ago
    RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools. I could fully foresee VB making a comeback in the future.
    - int_19h 6y ago
      RAD never really died, we just stopped calling it that. But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.
      - benibela 6y ago
        A typical Delphi app might have done that, but a selling point of Delphi was that it had data binding. Connect the TDB* vies to a TDataSource, and it would show the values of a database, without requiring manual updates.
        int_19h 6y ago
tiborsaas 6y ago
Don't be shy, go that last extra mile and just say that frontend engineers are fraud.

dbmikus 6y ago

I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * search Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.

unclebucknasty 6y ago
>Over the next 10 years I think we're going to see more and more codeless SaaS services Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now. I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names). But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever. Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win. Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.
- dbmikus 6y ago
  I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will: * pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together * they will differentiate themselves from their competitors based on their product offering and branding, less so on tech So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.
groestl 6y ago
It might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.
- TeMPOraL 6y ago
  > the process has a tendency to self correct over time - creative destruction and all that I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.
  - searchableguy 6y ago
    Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?
    - ComputerGuru 6y ago
      Let’s hope the public sector isn’t the model that the software industry is following.
      - TeMPOraL 6y ago
        Why, but it is. It's not the public sector that's causing these problems, it's the private companies that fulfill government contracts.
int_19h 6y ago
It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD. Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.
- jimbob45 6y ago
  RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools. I could fully foresee VB making a comeback in the future.
  - int_19h 6y ago
    RAD never really died, we just stopped calling it that. But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.
    - benibela 6y ago
      A typical Delphi app might have done that, but a selling point of Delphi was that it had data binding. Connect the TDB* vies to a TDataSource, and it would show the values of a database, without requiring manual updates.
      - int_19h 6y ago

tiborsaas 6y ago

Don't be shy, go that last extra mile and just say that frontend engineers are fraud.