[eigenvalue]

If this works well, I could see it reducing a huge amount of drudgery in the industry. But it could also reduce billable hours for less experienced developers who take on this sort of work. I have been wondering for a while why such a tool didn't already exist given its obvious utility.

[dyarosla]

The utility may be obvious but the solution is far from it.

The problem is that custom UI is extremely non-trivial. Getting something to work in a way thats even just slightly different from what the default UI does can be a huge undertaking; from reasons having to do with integration, rendering, dataflow, or any other obscure thing.

IMO it’s a dangerous misconception to think that most custom UIs can be implemented via a simple extension- that’s the real reason why there’s so many front end developers.

[orarbel1]

You definitely have a point.

This type of solution has obvious upside. The truth is that it has been tried many times before (Flash, Frontpage, Adobe Muse). The hard thing here is to being adopted both by the designers who start the process and at the same time generate code that developers will agree to work with.

The way we tackle this is by giving designers tools to express what they want in ways that were not available before, and then use the output to generate code. For example, one popular feature is Stacks[1] which is basically CSS Flexbox for Sketch. When designers use Stacks, we can then use that data and generate an actual CSS Flexbox from it.

Designers are adopting this approach but in terms of code generation, we still have a lot of room for improvement. The code works great, but it's not always optimal in the way that a good human developer would write it.

We have an internal goal, which is to pass the "Turing Test", where a developer will not be able to recognize whether our algorithms or by a fellow human developer.

[1] https://medium.com/sketch-app-sources/auto-layout-introducin...

[jbob2000]

For a proper development shop, the developers wouldn't use the generated code. It would require so much rework to fit their framework that you might as well just write it from scratch. I have worked with tools like yours, Adobe has an enterprise product that is a bit ahead of yours.

Writing HTML and CSS is not the hard part of front-end development. A modest developer can put this together quickly. The hard part is using javascript or someone other tech to piece it all together.

I would encourage you not to chase your internal goal. Instead, focus on making designers better instead of trying to turn designers into developers. W3C will release a new CSS/HTML spec, or some fancy new JS framework will come out and you'll be left scrambling to re-engineer.

[orarbel1]

We get this a lot and I do understand where you're coming from. Replacing human engineers will not happen any day now, but we project our vision years ahead.

For the time being, even if developers don't use the generated code, but rather just inspect it is better then guessing how a component should work by staring at a static image or a GIF.

If you take for example this elaborate interactive component: https://handoff.animaapp.com/#/timeline/XKHmOQP5Hcuipv/anima...

It was made completely by Michal, our co-founder/designer in Sketch with Anima. No code was manually written. Trying to convey this today usually involves hand-waving or for advanced teams, a GIF. By handing off functional code, a developer can interact and see the values that make this work. Even if not using the actual generated code.

Does that make sense? What do you think?

[dwaltrip]

So it becomes a medium of communication rather than an actual usuable code. That is interesting...