Chris McCormick

At the end of June I finally shipped Slingcode, the browser based code editor I've been working on for several months.

The response was overwhelming:

• ~22,000 visitors to the site.
• ~7,000 uses of the Slincode app.
• ~2,400 YouTube views of the intro.
• Made the front page of Hacker News.
• 100+ reactions on dev.to.
• 57 retweets of the launch.

This has been a humbling experience and I'm grateful to every person who checked it out and those who gave me feedback. Thank you!

Since then I've been recording screencasts for getting started with technologies like React, Vue.js, and SVG live-coding in Slingcode. You can find the screencasts at slingcode.net/screencasts.html or on the YouTube playlist embedded here:

I hope this tool and the screencasts are useful to you.

Enjoy!

Un-template is a minimal Python library to modify and render HTML. The idea is to start with a pure HTML document, choose the bits you want to modify using CSS style selectors, and then change them using declarative Python datastructures. This means you can use pure Python to replace sections of HTML and do all of the "template logic", similar to how declarative front-end frameworks work.

Install it with pip install ntpl.

Here's an example. It's a Django view function that returns a web page. A file called index.html is loaded, two HTML tags with IDs content-title and content are replaced with new content. A link tag with ID home is replaced completely with a new link tag.

from ntpl import slurp, replace, replaceWith, render

template = slurp("index.html")
faqs = markdown(slurp("FAQ.md"))

def faq(request):
    html = template
    html = replace(html, "#content-title", "FAQ")
    html = replace(html, "#content", faqs)
    html = replaceWith(html, "a#home", render(["a", {"href": "/"}, "home"]))
    return HttpResponse(html)

That's basically all there is to it. You can use it like this instead of Django's native internal templating language.

You can get the source code on GitHub or install it with pip.

It is inspired by Clojure's Enlive and Hiccup, this library uses pyhiccup and Beautiful Soup to do its work.

When you're building some MVP or SLC it's tempting to over-think technical choices early on. It's tempting to build in all kinds of features and infrastructure.

"People might want a PDF," you think to yourself, "so I'll also build and deploy a PDF rendering server!"

"I'll need a way to measure everything my ten million customers are doing at scale so I'll deploy this elastically scaling mega analytics doodad framework server and hook it up to every user action in my app!"

It's much easier to imagine new features than it is to actually build them. Before you know it there is a vapourware castle shimmering on the horizon.

I've found a useful thought pattern to combat this type of over-engineering. For every technical question just think to yourself:

What will my zero customers think of this?

When you are building the first version of something there are literally zero users. Unless it is the core function of the thing you are building, making a PDF rendering server or deploying a giga-scale analytics system is not what you should be doing. Your zero users don't care about those things! Getting even one person to actually use your thing and tell you if it's good or not is what you should be doing. Talking to people and asking them what they need is what you should be doing.

Let's protect the most scarce resource of all: our own time. At the start of the project let's make a bee-line towards shipping the best possible implementation of the core function of the software so we can find out if its useful and good.