
Show HN: iskulpt.js – Extending HTML into WordPress components for profit - motsi
https://www.iskulpt.com
======
motsi
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
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
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.

