In a type-safe environment I think you should just be able to switch your pur sang SQL builder to another dialect. Because of the type-safety you’ll be able to find incompatibilities at compile time which makes the migration easy enough (ignoring data migration). This avoids creating a weird ad hoc SQL dialect trying to fit all the others in a single API.
Right, instead of abstracting away the database I think it makes sense to invest in making it attractive to use. Putting an abstraction layer (like ORM) on top of it basically hides it's amazing features.
PS. maintainer of mammoth here. Thanks for the mention.
I agree. Additionally, it looks like the comments feature is compatible with the JSDoc syntax. I'm not too sure about the return syntax though. This means I can start type checking some of the large and older JavaScript projects, all documented with JSDoc, of some of my clients. I'm eager to test this out.
In my experience, in some organisations, it's hard to introduce TypeScript instead of JavaScript, because of reasons. For example, one of my clients made a bet on CoffeeScript back in the days, and that didn't work out, so now they are hesitant to adopt anything. Being able to introduce at least the type checking feature will start to drive change to this hesitation.
I'm curious though, how do these minifications, or CSS minifications in general, affect runtime performance? Reducing the file size is great, and a goal in itself (though brotli is more important where gzip is supported), but another important goal is rendering the page fast. Some CSS selectors are faster than others, is this something minifiers take into account? Or is this not significant at all?
I think it's very hard to say that one metric is key for every product. Teams should think careful about their metrics and figure out what matters most. Retention is not always the key. Think about a dating website for a second.
Personally I feel focussing on growth is focusing an all pirate metrics, but one or two at a time. You shouldn't solely focus on acquisition or activation. Especially if your retention is too low. But sometimes your retention is good enough so you can focus on other things.
The focus now is on increasing the retention of a small user base. I first want to make sure things work super easy and the added value is clear. For example, in our Atom plugin, you can just sign in and it's all set up. You don't need to copy any access token manually.
Monetization will happen when we start focussing on teams, managers and invoicing.
Which editor do you use btw? Please try Koala for a week as I'm eager to receive feedback. Which editor do you use btw?
Yes, this is true. I only discovered wakatime a few days ago. The major difference at the moment is wakatime's free plan only includes 1 week of data retention, whereas Koala's plan includes indefinite data retention.
You can actually configure a .koala file in the root of your project to define what to send to Koala.
Nevertheless, I see your point. I'm thinking of going open source and releasing a community edition so you can set-up a hosted version. Would that be interesting for you?
Can you give an example of the TTS software you consider advanced? The software I tried works, but too often sounds robotic and far from natural. Especially for the Dutch language.
I work on Mammoth which is a pur sang Postgres query builder, see https://github.com/Ff00ff/mammoth.