My Journey into Automation: A Not So Critical View of PageDraw.io

My time as a developer has had its fair share of nights going through the grunt work of building projects from scratch, importing modules and installing node packages. Which raised the question for me a long time ago, can this process be easier?

Contemplating automations of processes has been one of the most fulfilling aspects of being a developer for me thus far. In fact, the main reason I got into software was to create effective ways to automate tasks. I remember implementing excel functions as an undergrad for a Management Policies class’s competitive Capstone. Keep in mind that this class was considered the existential basis of business school retention.

From creating decision making automation tools in excel for that class to boilerplate template creations as a dev, my journey into automation has been quite a find myself experience. As a result, I have since created a blog for automation specifically and started this series, “My Journey into Automation”. The very first article talks about creating a CLI boilerplate tool.

However, projects don’t just stop with the boiler plate, there is also a front-end and a back-end. In this article, I will talk about the efforts of automation as it relates to the front-end, specifically about PageDraw.io, a startup that automates react components with wireframes. I will talk about it’s success and also why it ultimately is no longer a viable application in today’s software automation arena.

Unfortunately, since starting this article I have come to the realization that none other than Gabriel Guimaraes, the founder of PageDraw.io, has written an article that explains his successes and failures with it. You can actually checkout his article in Medium here: https://medium.com/@gabriel_20625/technical-lessons-from-building-a-compiler-startup-for-3-years-4473405161cd

As sort of a synopsis of his article and the main failures of PageDraw.io come down to this most important concept, “ Is the product something that someone actually wants?”. As a DevTool, PageDraw.io was to cater to the developer and make the process of UI development an easier task. However, during the process of its creation, use of the platform became a blocker, since for most devs any related tool fixes associated with the software wouldn’t be possible because PageDraw’s code was cloud based and not open source.

Another problem came down to a better alternative. Was simple JSX capable of providing the same benefit as PageDraw and if not, what was the significant improvement as opposed to the cost of PageDraw’s creation? It turns out, the software only seems to be a 10% improvement to JSX. In fact, Gabriel states as a closing statement on the PageDraw.io website, “We think you can get 90% of the benefits of PageDraw by just using JSX better”.

I can’t end an article, regardless of how short without talking about successes. PageDraw did get a few things right, and that is the efforts to put readability above optimization. As Gabriel talks in his article, maintainability of code is key. By first focusing on readability of code and then optimizing, he and his team were able to get PageDraw’s codebase down to <20k lines of code and still have ideal optimization. I’ll end this article as quickly as I started, simply put, know your audience.