Well, distribution is the killer feature. More, it's inherent property of the platform (web).
Web devs are in full control of their whole stack (excluding the browser where you occasionally need to account for incompatibilities), have to maintain only one version of the app (no upgrade needed on client-side), are not constrained by the platform owner's policies (app store tax).
Yes, it's more limited than native technologies in other ways, so it's not an answer for every problem.
I'd argue that the risk of your own instance being inaccessible for whatever reason is significantly higher than GitHub or GitLab having a full outage.
All good, but without being actionable they're just vanity metrics that only get discussed during performance reviews. They don't provide any meaningful insights on how to improve actual performance in day-to-day work.
I wrote Elasticsearch CLI just to scratch my own itch, as for certain tasks I just prefer to stay in the terminal. It's written in bash, uses curl under the hood and provides zsh completions for index and alias names.
About 10 years ago I attended a small local conference in Poland and met a guy who came there with his ~10yo son. As it turned out, the father was only an escort.
The kid was the most active person from the audience when it came to QA sessions after the talks. He asked genuine and interesting questions and spoke from his own experiences about building web apps and browser extensions.
I've never met anyone like him, even though I worked with some really good engineers in their 20s and 30s.
We're using dashing to present some internal information about our company's cashflow.
We built a second application (in Rails) that collects data from various sources, stores and transforms it, and then exposes it via API for dashing to use.
So in our case, dashing is a neat presentation layer and it serves its role very well.
I think that's because of wide variety of CMS applications build with PHP that are so common. Also it's cheaper to hire a PHP programmer than .NET, Java or Ruby one.
I wouldn't say it's better. saxy wraps around Nokogiri SAX Parser by implementing it's callbacks.
What I wanted to achieve is to take advantage of SAX parser (memory efficiency when used correctly) with as little preconfiguration as possible, because I often face one-off tasks that involve importing large XML files into database.
I've seen some implementations of SAX parsers, but they either missed the point by only using it's API under the hood and still returning all the results at once (thus not being memory-efficient at all) or required extensive configuration (which seems a waste for one-off imports).
Web devs are in full control of their whole stack (excluding the browser where you occasionally need to account for incompatibilities), have to maintain only one version of the app (no upgrade needed on client-side), are not constrained by the platform owner's policies (app store tax).
Yes, it's more limited than native technologies in other ways, so it's not an answer for every problem.