3 ms·

I know you try to couch this for "simple" projects, but if done correctly I believe that something like this can be useable for complex applications as well. F

I know you try to couch this for "simple" projects, but if done correctly I believe that something like this can be useable for complex applications as well. From a super high level, we have "structure" and "components". Using anything computer generated for application structure is risky and a bad idea. BUT, for components, I believe there are certain contexts where a "react component" which is autogenerated, by makers.so for example, might work. While I acknowledge some components are foundational and need to be flexible, robust, interactive, configurable, and clean, there are some which don't. There are some components which level in "application space" which are one-offs, experimental, and somewhat rigid in their usage. For these types of components, as long as the computer generated html/css is encapsulated into the component, it might not matter what the implementation details are. If you just need to set it and forget it, you can save time by using a "Makers.so figma group => react component" process. Later on, if you do need that component to be "productized", then upgrade it to handwritten html/css later. Notes: * I built a proof of concept single page application with this approach (Sketch + www.animaapp.com) and it looked promising. Most of the wrinkles in that workflow are being solved at the figma level with variants and "flexbox" support. * Unless you use more advanced css approaches/sandboxing, you need to make sure the css boundary between your application and the autogenerated components aren't in conflict. This might mean that makers.so baseline css assumptions (reset, whitespace, etc) might drive the baseline css for your application. Which is a bit of the tail wagging the dog. Hence, the high level of experimentation with this approach. * And yes, I have been around long enough to have "created applications using Microsoft FrontPage" and done a "Photoshop export to HTML" to be very disappointed with the results. :)

johndamaia 5y ago
Such great feedback, Tom. Thank you for taking the time. I'm definitely going to distill all your notes and thoughts on this. It's funny you mentioned Microsoft FrontPage. Alexis Ohanian [0] also made the same comment :) [0] https://twitter.com/alexisohanian/status/1448288261172989960?s=20 https://twitter.com/alexisohanian/status/1448288261172989960...
- tomhallett 5y ago
  Thought experiment below -- Setup: In the data warehouse world, there is a very interesting trend happening with the rise of the "Analytics Engineer". Historically, all data transformations had to happen with "handwritten python/hadoop/spark code" by a software engineer. This process is expensive and slow, because they are often translating SQL code written by a Data Analyst into python/spark code. But with dbt [1], we see Data Analysts becoming Analytics Engineers. They know a lot about SQL, a lot about the dbt framework, a bit about jinja macros, a bit about yaml, and a bit about the command line - now they can create some really powerful data transformations which is the underpinning of the "Modern Data Stack". Thought experiment: Right now, we have a problem where any change to a figma design requires a software engineer to update the react application. What about if tools like makers enabled a "dbt-like" workflow, where a "Component Engineer" can turn a figma component into a "simple react component". A component engineer's work flow would be based on makers, storybook, and a cloud IDE. The goal being that designers start to become "Component Engineers", in the same way that many "Data Analysts" have become "Analytics Engineers". [1]: https://discover.getdbt.com https://discover.getdbt.com
  - johndamaia 5y ago
    This is brilliant! We designers like freedom of thought, and Figma give us that. The goal with makers.so is: inside the same tool I use to lay out ideas, I can also publish them (i.e. use makers.so components) without ever depending on a developer or third party app. A "Component Engineer" is this second stage of the process (after playing around, I can now publish this with some rules).
    - tomhallett 5y ago
      Congrats on makers - I think this will be very very cool! I'll give it a spin and show it to our designer.
      - johndamaia 5y ago
        Thanks Tom. I'd love to hear yours and your designer's thoughts about the plugin. Happy to answer any questions you might have.
josefrichter 5y ago
> but if done correctly I believe that something like this can be useable for complex applications as well I think this is one of the most fascinating "problems" in IT. There have been THOUSANDS of attempts to auto-convert design to code and it never works. It's been tried for at least 30 years now and still nobody solved this problem.. This leads me to believe we are solving the wrong problem. I actually believe Flash was the closest thing to this holy grail. Except it was acquired by greedy Adobe that failed to evolve the product. I am far from having a solution, I was just thinking that WASM is actually similar to Flash. What I mean is this: whole Figma can run in browser thanks to WASM. It has all the tools to visually create responsive websites in it. You can share Figma file as view-only. If I go to extreme, why not have Figma file in read-only mode on custom URL? No translation to HTML, just expose the Figma engine directly. (bandwidth and SEO problems are not impossible to solve) At the end of the day, we are just trying to come up with different ways of adjusting same content for different screen sizes. It's a shame we are still losing this battle :-)

johndamaia 5y ago

Such great feedback, Tom. Thank you for taking the time. I'm definitely going to distill all your notes and thoughts on this. It's funny you mentioned Microsoft FrontPage. Alexis Ohanian [0] also made the same comment :) [0] https://twitter.com/alexisohanian/status/1448288261172989960?s=20 https://twitter.com/alexisohanian/status/1448288261172989960...

tomhallett 5y ago
Thought experiment below -- Setup: In the data warehouse world, there is a very interesting trend happening with the rise of the "Analytics Engineer". Historically, all data transformations had to happen with "handwritten python/hadoop/spark code" by a software engineer. This process is expensive and slow, because they are often translating SQL code written by a Data Analyst into python/spark code. But with dbt [1], we see Data Analysts becoming Analytics Engineers. They know a lot about SQL, a lot about the dbt framework, a bit about jinja macros, a bit about yaml, and a bit about the command line - now they can create some really powerful data transformations which is the underpinning of the "Modern Data Stack". Thought experiment: Right now, we have a problem where any change to a figma design requires a software engineer to update the react application. What about if tools like makers enabled a "dbt-like" workflow, where a "Component Engineer" can turn a figma component into a "simple react component". A component engineer's work flow would be based on makers, storybook, and a cloud IDE. The goal being that designers start to become "Component Engineers", in the same way that many "Data Analysts" have become "Analytics Engineers". [1]: https://discover.getdbt.com https://discover.getdbt.com
- johndamaia 5y ago
  This is brilliant! We designers like freedom of thought, and Figma give us that. The goal with makers.so is: inside the same tool I use to lay out ideas, I can also publish them (i.e. use makers.so components) without ever depending on a developer or third party app. A "Component Engineer" is this second stage of the process (after playing around, I can now publish this with some rules).
  - tomhallett 5y ago
    Congrats on makers - I think this will be very very cool! I'll give it a spin and show it to our designer.
    - johndamaia 5y ago
      Thanks Tom. I'd love to hear yours and your designer's thoughts about the plugin. Happy to answer any questions you might have.

josefrichter 5y ago

> but if done correctly I believe that something like this can be useable for complex applications as well I think this is one of the most fascinating "problems" in IT. There have been THOUSANDS of attempts to auto-convert design to code and it never works. It's been tried for at least 30 years now and still nobody solved this problem.. This leads me to believe we are solving the wrong problem. I actually believe Flash was the closest thing to this holy grail. Except it was acquired by greedy Adobe that failed to evolve the product. I am far from having a solution, I was just thinking that WASM is actually similar to Flash. What I mean is this: whole Figma can run in browser thanks to WASM. It has all the tools to visually create responsive websites in it. You can share Figma file as view-only. If I go to extreme, why not have Figma file in read-only mode on custom URL? No translation to HTML, just expose the Figma engine directly. (bandwidth and SEO problems are not impossible to solve) At the end of the day, we are just trying to come up with different ways of adjusting same content for different screen sizes. It's a shame we are still losing this battle :-)