1. 28
  1. 6

    10% ain’t worth having my app made legacy with two weeks notice.

    1. 8

      0.16 -> 0.17 was a big change but I’m puzzled by the implied criticism. Does version 0.16/0.17 indicate “ready for production”? I always inferred from the versions and the sparse documentation & libraries that Elm is experimental, so I’m very cautious about using it for any production stuff (and so I wasn’t bothered by the 0.16 -> 0.17 transition). Projects in experimental phase can and should change, wouldn’t you say?

      Unfortunately, these days nobody seems to indicate clearly (or even to know?) whether the project is stable and suitable for production use, and that’s a problem, but it’s definitely not unique to Elm.

      1. 5

        React was at 0.14 but in production on things like Instagram for a while. I think Elm is decently ready for production, but there is the whole Clojure-style “at the whims of the BDFL” vibe going on, esp. with the subscriptions change.

        That being said, I think it’s mostly fine. Types make this a lot less painful than (say) Py2 -> Py3. If you really like Elm, this is a small cost to pay compared to the pain of using a pure-JS (or even Typescript) environment. In the worst case, it’s a vibrant experiment in building front-end apps. The tools and practices that are showing up are more important than the language IMO.

        There is also the whole thing where you can stick on older versions for a while if you don’t want to do the change just yet. It’s not like older stuff disappeared. Py2/Py3 sucks but if you were on Python 2, you were mostly fine.

        I think the more frustrating thing is that there wasn’t a clear deprecation path. Ideally, you have one or two versions where both mechanisms are in place, so you can gradually port things .

        Though I say this as a Purescript user who has all dependencies break at every minor version release ;)

        1. 1

          You do that much triangulation and marketing about being the “practical” alternative, some expectations are implicit to that.

          1. 1

            Fair enough. I guess I just don’t believe any tech marketing after having a sufficient number of painful lessons. My own experiments showed that Elm is still quite a long way off from being production ready, and I treat it accordingly.

            1. 1

              shrugs We use GHCJS in prod. It may be even less mature than Elm or PureScript, but it doesn’t dictate to us how to build our app, we share datatypes with the backend, and the compiler is very hackable. The GHCJS creator is very easy-going and modest as well.

        2. 4

          Signal noted.

          (Sorry. Bad pun.)

          1. 2

            Yep and I wouldn’t want to be the guy who has to debug this once the lib is deprecated (code generated from the simple “form” example):

            var _user$project$Temp1472650027426490$viewValidation = function (model) {
                var _p0 = _elm_lang$core$Native_Utils.eq(model.password, model.passwordAgain) ? {ctor: '_Tuple2', _0: 'green', _1: 'OK'} : {ctor: '_Tuple2', _0: 'red', _1: 'Passwords do not match!'};
                var color = _p0._0;
                var message = _p0._1;
                return A2(
                                    {ctor: '_Tuple2', _0: 'color', _1: color}
            var _user$project$Temp1472650027426490$update = F2(
                function (msg, model) {
                    var _p1 = msg;
                    switch (_p1.ctor) {
                        case 'Name':
                            return _elm_lang$core$Native_Utils.update(
                                {name: _p1._0});
                        case 'Password':
                            return _elm_lang$core$Native_Utils.update(
                                {password: _p1._0});
                            return _elm_lang$core$Native_Utils.update(
                                {passwordAgain: _p1._0});
          2. 4

            Why is “fast” always labelled these days? “Blazing fast” seems to be the phrase du jour, and “lightning fast” is another that I hear often.

            1. 1

              I would be a lot more interested in this compared to frameworkless JS.

              I don’t give two tugs of a dead dog’s…ear, we’ll say, if we just keep comparing large clanky frameworks against one another and keep failing to baseline against the fastest-possible core ES5 implementation.

              1. 2

                The fastest possible ES5 implementation is not really what front-end frameworks and tools are competing against. They’re competing against the average front-end codebase.

                Whether frameworks and etc are a net gain or not is certainly contingent and debatable, but the baseline for that evaluation should be the production code you’ve actually worked on, not an ideal. I’d say you’re a very fortunate person if you’ve worked on non-trivial vanilla JS code that was anywhere close to the fastest possible implementation. :)