Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is no…
A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic impli…
Maybe in the context of the parent comment this holds true, but in my experience this is like walking on a knife's edge.
There's the very distinct possibility that you'll end up with homebrew frameworks and libraries that are overcomplicated, buggy, not commented and exceedingly hard to work with. I've seen that happen many times and it makes me consider not just whether people want to do that, not whether people have the time to do that, but even whether it's possible for them to do.
In one project people wanted all of their front end components to be custom and as a consequence spent 3x-5x longer building everything, none of their components were Googleable for someone who's been onboarded and thus people forgot how they even work after 2 weeks of not editing them and had to rediscover that later. I tried adding a component sandbox/playbook to help them provide examples, but no one was interested in doing that when they were already behind the expectations of the business. Picking an off-the-shelf framework would have saved them all of these troubles. Maybe there were actual reasons behind the choice of approaching the project this way, apart from padding their resumes, however after inquiring about those, i didn't get a convincing response.
In another case, i had to work on a custom web back end framework, which had been developed by another company, in a country the language of which i don't speak. Curiously enough, all of their code comments were in this language, there yet again was a lack of any sorts of documentation, the implementation was obtuse, slow and any simple changes to the forms took days to implement properly, even when it would take around 30 minutes in established technologies. Furthermore, the actual framework hadn't received any updates in years and therefore i fear to think what sorts of security issues it had. An off-the-shelf framework would have at least been updated and probably would have more decent documentation.
In short:
- never underestimate the ability of people who lack oversight to make things worse
- frameworks and libraries that are used by thousands of people are probably at least decent
- there's definitely also something to be said about how well tested they are and how known the bugs are
- because of the above, popular technologies seem like a pretty safe bet, as does off-the-shelf code appear to be
- of course, despite all of the above, it's perfectly okay to explore new tech stacks and write your own code, just don't half ass it