DEV Community

Cover image for Dark devlog #2: what next?
Paul Biggar for Darklang

Posted on • Edited on

Dark devlog #2: what next?

After spending the last week on some extremely urgent things on my plate (helping the team get jobs, moving, infra stability, costs, and legal and transition work), I have time to get back to the product.

There's still not a clear sense of what to work on next. The positioning that we end up with is going to dictate the important work. However, it's clear that the main areas that need love in the near term, regardless of exactly what direction we're taking with the product, are:

  • positioning
  • contributors
  • onboarding
  • package manager

Positioning and long term

Positioning is what I talked about last week, figuring out what Dark can be that's useful in the short term (while sticking with the same long term vision). The main thing I'm zeroing in on here is trying to position around what Dark is really good at right now, while trying to maintain a reference of what Dark will be in the future. This would hopefully allow room to position as for example a "better zapier" while also allowing me to talk about building React apps, backends, internal tools, etc.

An alternative--or possibly a compliment--to the "better zapier" positioning that occurred to me is to create a forms library. It's still pretty difficult to put a form on the internet and do whatever you want with it, and you can see for example Netlify adding products that move in that direction. So what if we made a Dark library that had an experience as good as Typeform, backed by Dark, so that you could create a form with a super customized backend. This would allow fully-custom actions on each event, rather than just getting the results in a spreadsheet (as an example, you could automatically send a slack message when someone picks the "urgent" field from the form).

Contributors

After the initial excitement in the community about contribution, things have settled down to a core 5-10 people who are the most excited, which seems about right. I need to keep working on this, but I need to recognize that this is a journey. I'm going to set aside 30 minutes a day to work on contributor docs and tooling, to make sure that there's steady progress in making this better (this is on top of reviewing and talking to contributors).

I also need to announce that the Dark repo is public, and a blog post to discuss that. I'm planning to have a contributor virtual meetup as well.

One area that is needed is enabling contributors to contribute to build new features which use Dark as major components. While language and execution features need to be written in OCaml, most other parts of the product could be safely written in Dark.

Well, theoretically. Right now, permissions in Dark are extremely coarse-grained. There's no way to add a contributor to a Dark canvas used for customers, without giving them access to the entire organization we use for this, including customer data. This is obviously a core product problem in Dark as well, so solving this would be beneficial to devs using Dark as well.

Another area I'm going to work on here is refactoring the client/frontend; it's a bit of a mess and I want to separate out components, document types, etc, to make it easier to contribute to. 90% of the work to be done is on the client, so I think this will help a lot.

Onboarding

This is the place I'm going to spend the next while doing a deep dive into. Sydney and Victoria recently made great progress here, especially with a tooltip-based tutorial framework that I can work with.

I need to take a look at what the analytics are like so I can see a complete funnel from homepage to completed tutorial.

I'm thinking of having a tutorial menu, so you can be stepped through the tutorials in the docs without having a different page open.

While we've been making fairly broad product changes over the last year, solving things in the smallest way possible, I want to take a different approach to improving the product now. Instead, I want to make an amazing experience for a particular aspect of the product. So for onboarding, this is an opportunity to address core product problems, like the omnibox being weird, or layout sucking. Dark's positioning could also get dragged in here as well, as that's obviously the top of the funnel.

My first steps are to instrument the website, frontend, and client, so I have a baseline to measure from. I saw Wisdom on HN recently and this seems like an amazing tool (especially given our user experience information is currently split between Rollbar, Fullstory, Segment and Heap). I'll try instrumenting with this and see what I learn about the funnel is like.

Package manager

Having a package manager is important, as Dark developers are pretty much just calling 3rd party services by manually writing HTTPClient calls. With all the different constraints I'm not really sure that I'm prioritizing correctly here. But you gotta pick something, and the package manager has more unknowns right now. I think this will be next after onboarding, though if contributors want to take it up, I could imagine spending time helping on it in the near future.

Any direction we take needs both the package manager and good onboarding, so this will get done either way.

Costs

The other thing that I'm keeping an eye on is costs. We're spending quite a bit of money on things like cloud services that we're not really using, and it seems like we're massively overpaying for capacity on Google Cloud, relative to what we're using. Technically it's free but we'll run out of credits eventually and it's better to be ahead of this, so I'm spending a small amount of time each day looking at this. Today I reduced the size of our read replicate, which is basically unused, saving probably $500 a month.

tl;dr

In the short term, I'll be spending a lot of time on onboarding, and a smaller amount of time on costs. I also plan to continually spend time on contributors, especially on docs.


You can sign up for Dark here, and check out our progress in these features in our contributor Slack or by watching our GitHub repo. Comment here or on Twitter.

Top comments (2)

Collapse
 
cooleydw494 profile image
David Cooley

I'm incredibly interested in the package manager. Not so much in contributing to the development of it to be honest (not writing that off though), but in the sense that I feel my potential for contribution would increase greatly if suddenly I could contribute Dark code instead of OCaml. Learning OCaml is fun, but the barrier to making more meaningful Dark contributions would be almost nonexistent compared to that of doing the same thing in OCaml. In fact, some of the code I've already written in my app could easily become a Dark package if developed a bit further.

Coming from PHP I can't even imagine working without the expansive set of quality packages that are easily installable via Composer (PHP's excellent package manager). It is absolutely vital to that ecosystem and I think it could be here as well. It is like the difference of learning C and writing PHP extensions or contributing to the language itself (which relatively few people do) vs sharing solutions you already had to write in PHP (which is massively popular). Certainly all of it is necessary, but I'm sure you get my point.

Also, maybe in the contributors meeting you can discuss more what opportunities already exist for contributing actual Dark code?

Collapse
 
chasers profile image
Chase Granberry

Yeah positioning it something like a Pipedream in the short term might be interesting.