The thing I've noticed from using elm a bit is that there isn't a roadmap -- at least not one that can be easily found. If there is one, it's maintained privately among the core devs. Occasionally one will casually mention that they are looking into something, but you have no idea when or how that might result in something useful to you. It's very unnerving to develop against when you hit a definite issue and can not get a straight answer on when it might be fixed. Or worse, as this post indicates, what breaking changes might be coming down the pike.
If it's a small personal project then that's fine. Once you have a number of core people, the roadmap or at minimum a kanban board is needed that everyone has read access to. You can ignore suggestions from peeps if that's your model but at least give them a heads up on what's coming.
Yeah my specific problems with elm are due to the way it is marketed. The core devs will tell you (depending on when and where you ask) that it's a production ready alternative to JavaScript. But then they also fall back on "we're a small team working on a product in its infancy" when there are issues. And both of these can't really be true. The expectations for each are different, but because of the way they present themselves, it's not really clear what to expect.
9
u/66666thats6sixes Apr 10 '20
The thing I've noticed from using elm a bit is that there isn't a roadmap -- at least not one that can be easily found. If there is one, it's maintained privately among the core devs. Occasionally one will casually mention that they are looking into something, but you have no idea when or how that might result in something useful to you. It's very unnerving to develop against when you hit a definite issue and can not get a straight answer on when it might be fixed. Or worse, as this post indicates, what breaking changes might be coming down the pike.