Copy, experiments, & art

[krainboltgreene]

Alright, so I'm no good at blogs and this is probably not going to be much better, but I'm going to try. Let's talk latest Lacqueristas stuff!

I've recently been paying a copywriter to work on the marketing pages and give our mascot a backstory. The author has made this all a fantastic experience, they were the perfect choice. I've already started putting the copy into the about pages (pull requests soon).

Speaking of marketing pages I finally got around to thinking about how the frontend would handle these. Sadly snabbdom static rendering isn't quite finished yet so I just went with mustache + html. We should have some basic marketing pages (landing + newsletter + about) live soon.

Okay, so "live soon", what does that mean? Well some of you might know the frustration I went through early in Lacqueristas. I assumed I could just start hosting everything on Heroku (my preferred host currently). I wanted these to also be a chance for me to learn about SSL and letsencrypt.org. Frustratingly I found out that while SSL is easy, Heroku charges $20 per SSL addon! With a frontend and backend, staging and production of each, I was looking at a $80/mth bill for no goddamn reason. Welp, now that's not a problem! I'll be investigating this further on the weekend and we can get v1 out then.

Finally, let's talk about v1. Right now the frontend is written in javascript, using Cycle.js (a very fresh framework), snabbdom (a very fresh view layer), and a cavalcade of build scripts. The backend is even more so with my own custom framework and my own jsonapi handler. This doesn't lend itself to pairing or even sharing. Most people are accustomed to React + Redux + Falcor/Relay and Express/Hapi on the backend. While I love my work and I think the experimentation is going well I'm also aware of the drawbacks.

So here's the "call to action": Should I switch to more popular technologies?

[hannahhoward]

Hey Kurtis,

So here's my quick thoughts. How you want to build this really has a lot to do with the goals of the project. It totally makes sense to explore new tech in an open source project, especially since the stakes are lower and you have no job pressure. But if a large goal of Laqueristas is simply to be a successful product, then yes I would consider switching to more well known tools. If anything else, it simply means someone can submit a quick PR without having to learn a wall of new tech. Even to this day I consider several of the decisions in Xing poor "product" decisions, even if they were sound "tech" decisions. Where that balance lies is obviously something only you can really figure out. I struggle with this every day because I'm certainly drawn heavily to new tech, but also recognize the value of making decisions that lead to quick turn around on product, and easy spin up for beginners. One thing I like to remind myself is that in 2016, 80%+ of the web runs on PHP. :) Also one thing teaching has taught me over and over is that what I see as "easy" is not what is actually "easy" to less experienced people. I think this is because most things that feel "easy" to me are the things that make senior level problems I struggle with easier.

[quephird]

I'm not sure my perspective counts for much because I hardly ever delve into JavaScript or any of the myriad of frameworks out there. I know that I struggled a bit understanding your framework, Kurtis, because there was no documentation to refer to. That's not a slam at all, by the way; it's just that I needed to rely on you to explain how things worked and I'm not familiar enough with modern JavaScript idioms and techniques to figure stuff out on my own. So, the only thing I'd say is if you're interested in bringing on other folks, it might be a similar challenge for them as for me.

[hannahhoward]

Also, it would be worth looking at a middle ground. Look at the stuff that's most likely to make it harder for folks and take that out, leave stuff that pushes the edge a bit in.