3 ms·

Show HN: iskulpt.js – Extending HTML into WordPress components for profit

3 points by motsi 8y ago

motsi 8y ago
So I set out to create a theme builder that stays true to the WordPress API and allows you to code and style a theme visually. Why this over all the other 100s if not 1000s of options you might ask? In one word, CONTROL. You can place e.g. a post title, comment count, widget area etc exactly where YOU WANT IT. I found a lot of the builders are great as long as you stick to their templates, the moment you want something slightly different things get hairy very quickly. At the moment WordPress support is ready for prime time. I built the application in such way that rolling out support for other CMS e.g. Drupla or Joomla will be a fairly straight forward endeavor. You will find that my pricing is significantly lower than that market average, and the reason for this is simple. My market is theme shops and developers who want to build the themes they envision quickly but add some further customizations and resell to clients.
chatmasta 8y ago
I'm not the target market, but it looks like a lot of work went into this. Just want to say, nice job. I especially like the "layout mode" abstraction. What's your tech stack look like on the frontend? Any comments on the development process, e.g. how long it took, major challenges?
- motsi 8y ago
  A couple years ago about 2 maybe, I was heavily into Common Lisp and built a similar application for the heck of it. I learnt some pretty important lessons though. No matter how awesome a laungauge is business decisions and the language ecosystem are practicalities you can't get away from. For example, it's already hard enough to find a good developer for a popular langauge, now imagine one for some esoteric one :SMH: So to your actual question :) Sometime last year I dusted off the original concept and decided to focus on something I think still has room for growth. I redid the entire code base in Javascript. JS in the browser and Node.js at the back. Everything server-side and client-side is written in ES6 so I can use sytantic sugar like ES6 classes. I find the code to look much cleaner this way. I use Babel to transpile the client-side libraries to ES5 so that the code runs in pretty much all browsers. Setup deployments to AWS ElasticBeanstalk with scaling rules in place to handle traffic spikes etc. Did a fair bit of profiling using Locust (https://locust.io/ https://locust.io/) to actually determine the correct parameters I should base my scaling logic on. For the database I make use of Postgres. Originaly I used MongoDB, seems like a natural fit for JS right? Not really. I can't remember the details, but I had so many technical issues. There was also some issue with transaction sematics etc. Bottom line I got fed up and picked Postgres but made extensive use of the JSON datatype since I built a JSON API.

3 points by motsi 8y ago

So I set out to create a theme builder that stays true to the WordPress API and allows you to code and style a theme visually. Why this over all the other 100s if not 1000s of options you might ask? In one word, CONTROL. You can place e.g. a post title, comment count, widget area etc exactly where YOU WANT IT. I found a lot of the builders are great as long as you stick to their templates, the moment you want something slightly different things get hairy very quickly. At the moment WordPress support is ready for prime time. I built the application in such way that rolling out support for other CMS e.g. Drupla or Joomla will be a fairly straight forward endeavor. You will find that my pricing is significantly lower than that market average, and the reason for this is simple. My market is theme shops and developers who want to build the themes they envision quickly but add some further customizations and resell to clients.

chatmasta 8y ago

I'm not the target market, but it looks like a lot of work went into this. Just want to say, nice job. I especially like the "layout mode" abstraction. What's your tech stack look like on the frontend? Any comments on the development process, e.g. how long it took, major challenges?

motsi 8y ago
A couple years ago about 2 maybe, I was heavily into Common Lisp and built a similar application for the heck of it. I learnt some pretty important lessons though. No matter how awesome a laungauge is business decisions and the language ecosystem are practicalities you can't get away from. For example, it's already hard enough to find a good developer for a popular langauge, now imagine one for some esoteric one :SMH: So to your actual question :) Sometime last year I dusted off the original concept and decided to focus on something I think still has room for growth. I redid the entire code base in Javascript. JS in the browser and Node.js at the back. Everything server-side and client-side is written in ES6 so I can use sytantic sugar like ES6 classes. I find the code to look much cleaner this way. I use Babel to transpile the client-side libraries to ES5 so that the code runs in pretty much all browsers. Setup deployments to AWS ElasticBeanstalk with scaling rules in place to handle traffic spikes etc. Did a fair bit of profiling using Locust (https://locust.io/ https://locust.io/) to actually determine the correct parameters I should base my scaling logic on. For the database I make use of Postgres. Originaly I used MongoDB, seems like a natural fit for JS right? Not really. I can't remember the details, but I had so many technical issues. There was also some issue with transaction sematics etc. Bottom line I got fed up and picked Postgres but made extensive use of the JSON datatype since I built a JSON API.