4 ms·

There have been attempts at tools like this more or less as long as I can remember. The earliest one I recall seeing was Adobe Photoshop exporting sliced design

There have been attempts at tools like this more or less as long as I can remember. The earliest one I recall seeing was Adobe Photoshop exporting sliced designs, but I'm sure there were similar takes earlier too. There are two main issues that are more or less universal: generating reasonable code, and drawing the rest of the owl. The first part does not need much explanation, teaching a machine to generate reasonable code that's understandably structured is akin to teaching a machine to program in general. Context is hard and the output of such programs is generally a big mess. The second problem is drawing the rest of the owl [0]. Wiring up a frontend to a backend is not a trivial task, and one that I would argue to date does not have solid universal solutions. There are many companies and libraries trying to address this in different ways, but they all come with their own pains. Asking a tool to nail down both of the above issues is a very, very tall order and I don't expect anyone to succeed for the general case anytime soon. I do think great progress can be made in narrower scopes though. [0] https://knowyourmeme.com/memes/how-to-draw-an-owl https://knowyourmeme.com/memes/how-to-draw-an-owl

robertnowell 5y ago
I appreciate the thoughtful response. Wiring up a frontend to a backend isn't a trivial task, but is pretty typical software engineering. If part of the work (the ui) could be done for you, wouldn't that be a clear value-add?
- Etheryte 5y ago
  Yes and no. For the literal first prototype you get out of the door, yes, having some baseline UI work done for you would be nice. For the sake of the argument, let's assume that the code generated by said tool is at least somewhat reasonably structured so refactoring the code isn't a nightmare either. You wire the UI up to some data and get it out of the door to get some feedback. The problem comes after that initial step — you show the first prototype to some test users or stake holders and figure out what needs to change. Integrating the now changed output of the updated UI with the code you already have will no longer be trivial. So long as the prototype is lean, this will be manageable for some time, but sooner or later it will not. The problem is that for most projects, the initial prototype stage is a very miniscule part of the whole product lifetime. Getting one prototype for cheap can be good, but there are UI prototyping tools that can do this. Using those tools instead of trying to reapply the updated output to your now-existing code base will most likely be less work. In general I do think that tools in this niche will mature over time, but in my very subjective opinion, they won't be the holy grail of cutting down development time. Most of the time, the hard part of software development is the long haul, not the initial kickoff.
  - robertnowell 5y ago
    Ah, so what you're saying is that a big problem that dev+design teams will encounter is that they need to be able to iterate on designs together, so a real solution here would need to be able to integrate updates to the design into the codebase (and possibly vice versa). Am I understanding your point correctly?
    - Etheryte 5y ago
      Yes, exactly. This is a problem that many teams already struggle with when doing this manually, e.g. which design constraints are shared and which are unique. Context is hard to put into machine language and I see the above issue as one of the main hurdles in this space.

robertnowell 5y ago

I appreciate the thoughtful response. Wiring up a frontend to a backend isn't a trivial task, but is pretty typical software engineering. If part of the work (the ui) could be done for you, wouldn't that be a clear value-add?

Etheryte 5y ago
Yes and no. For the literal first prototype you get out of the door, yes, having some baseline UI work done for you would be nice. For the sake of the argument, let's assume that the code generated by said tool is at least somewhat reasonably structured so refactoring the code isn't a nightmare either. You wire the UI up to some data and get it out of the door to get some feedback. The problem comes after that initial step — you show the first prototype to some test users or stake holders and figure out what needs to change. Integrating the now changed output of the updated UI with the code you already have will no longer be trivial. So long as the prototype is lean, this will be manageable for some time, but sooner or later it will not. The problem is that for most projects, the initial prototype stage is a very miniscule part of the whole product lifetime. Getting one prototype for cheap can be good, but there are UI prototyping tools that can do this. Using those tools instead of trying to reapply the updated output to your now-existing code base will most likely be less work. In general I do think that tools in this niche will mature over time, but in my very subjective opinion, they won't be the holy grail of cutting down development time. Most of the time, the hard part of software development is the long haul, not the initial kickoff.
- robertnowell 5y ago
  Ah, so what you're saying is that a big problem that dev+design teams will encounter is that they need to be able to iterate on designs together, so a real solution here would need to be able to integrate updates to the design into the codebase (and possibly vice versa). Am I understanding your point correctly?
  - Etheryte 5y ago
    Yes, exactly. This is a problem that many teams already struggle with when doing this manually, e.g. which design constraints are shared and which are unique. Context is hard to put into machine language and I see the above issue as one of the main hurdles in this space.