cris-ward
It's difficult to overemphasise how much this kind of thing gives users of your software confidence. The common assumption is, if it looks good, it works well (and the opposite).
Github repos can vanish, NPM will only let repos be deleted if they have no direct dependencies also on NPM. So you have some guarantees your dependencies wont vanish.
I started using this library several years ago and have eventually had to rework it using prosemirror because I just couldn't keep up with the breaking changes.
Both libraries work in very similar ways, with slate using React for its rendering layer. However Prosemirror has been v1 for quite a while and in retrospect I'd have saved myself a lot of headaches if I'd taken the above warning more seriously.
Excellent resource that gives you interesting instant feedback. Reminds me of learning Basic in the 80's.
Reminds me of when windows started to hide file extensions by default.
We've since moved to using typescript on the front-end and crystal on the back end and both type systems have a lot of similarities. They both also help catch many more errors earlier which gives us a lot more confidence in our code and simplifies the scope of tests which are needed. You can get to a point with a javascript application when you feel you'll create a new bug just by looking at the wrong way.
Crystal as a languages feels really cool. It's very low on boiler plate, which makes it really easy to read and doesn't take a lot of explaining. It takes the best bits of Ruby, so has a easy to follow logic which allows you to understand how everything hangs together. There is also very easy to get hypnotised by the 3ms response times when you're running it locally.
I'd say the only down points at the moment is the size of the community. The lack of 3rd party libraries and inability to 'google for a solution' could be an issue. However crystal's community makes up for in energy what it lacks in size, the gitter room is very active - https://gitter.im/crystal-lang/crystal
Web dev is not the most complex of programming tasks and our team is small, so your mileage may vary, but so far so good.
We like to run our sites inside docker containers so they're easy to reproduce from dev to live environments. A compiled language like crystal, with it's own standard library and tiny memory footprint means we can, with low traffic sites host more together on a server and keep our clients hosting costs low. With higher traffic sites we can use that saved memory for in-memory caches for high use resources.
As mentioned in the article the cms typically uses < 5mb of Ram. In our development environment that really helps. Running lots of sites locally isn't a problem. Node_modules folder for the node version of our cms is 430mb, vs our crystal shards of 773kb. So disk space isn't an issue either.
Type checking has helped reduce runtime errors, it's hard to compare with the node version as the number of errors is often related to code complexity. But anyone who uses typescript will know that moving from a dynamic to a statically typed language is a real eye opener for how many errors we make as programmers. Unlike Typescript, crystal isn't just pretending to have types so there is no `:any` to cheat the system.
If there are any specific metrics you'd like I'll see what I can come up with. But hopefully that gives you an idea of our motivation and the benefits we get.