1. 17
  1.  

  2. 5

    Before you bet on PWA as your mobile app’s technology, make absolutely sure to carefully check on the list below if all the APIs you need will be available to you:

    https://whatwebcando.today/

    Many things are possible, but some others are totally not (yet?).

    If you checked the list and want to try, you may like to know that any Elm app created with the awesome create-elm-app helper is automatically a PWA. For JS/React apps, create-react-app seems to have an opt-in feature for that too.

    1. 1

      I didn’t know Elm had seamless PWA support now, that’s really cool! It might make me look at using Elm for a project or two.

    2. 6

      On top of good info, I love the styling of your web site. Minimalist and accessible with a touch of color. And fast! :)

      1. 8

        Thanks! I’ve been trying to make this website really really stinkin fast. https://hackcss.egoist.moe is the CSS framework I use. I have the colors tuned towards Gruvbox https://www.github.com/morhetz/gruvbox because I think it looks nice.

        1. 3

          Thanks for the link. Saving it in case anyone finds it useful.

        2. 1

          Indeed! Lovely site. I’d like to see more sites like this.

        3. 3

          Nice article but code snippets could be improved, for example this fragment:

          var checkResponse = function(request){
            return new Promise(function(fulfill, reject) {
              fetch(request).then(function(response){
                if(response.status !== 404) {
                  fulfill(response);
                } else {
                  reject();
                }
              }, reject);
            });
          };
          

          Looks a little bit better as:

          var checkResponse = function(request){
            return fetch(request).then(function(response){
                if(response.status !== 404) {
                  return response;
                } else {
                  throw new Error('Request failed');
                }
            });
          };
          

          We can also reuse response.ok that returns true on 2xx status codes and convert the function to async:

          async function checkResponse(request) {
            const response = await fetch(request);
            if (response.ok) {
               return response;
            }
            throw new Error('Request failed');
          }
          

          Other functions can also be improved but I leave it as an exercise for the reader :)

          1. 2

            To be honest, if someone threw me these rewrite suggestions in code review, I’d be rather annoyed. It isn’t immediately obvious whether or not the behaviour and/or performance characteristics are equivalent in all circumstances.

            1. 5

              To be honest, if someone threw me these rewrite suggestions in code review, I’d be rather annoyed.

              How do you approach ensuring high code quality then? First version had two nested functions and unnecessary construction of Promise object.

              It isn’t immediately obvious whether or not the behaviour and/or performance characteristics are equivalent in all circumstances.

              There are performance issues with nested promises. The first version is also brittle - if a future modification to it throws an exception in the innermost function the promise will never resolve. The last version handles this case automatically.

              1. 1

                How do you approach ensuring high code quality then?

                Generally speaking, I don’t. I write the dumbest/cheapest code (within reason) that solves the problem for the business.

                I don’t care if some code is slow — it only matters that the application as a whole is performant. I won’t optimise performance until a real-world bottleneck is observed.

                I also don’t care if some code is brittle. Code does not need to be amenable to change if the feature it supports is scrapped or the company shuts down before code needs to be changed.

                There are performance issues with nested promises. The first version is also brittle - if a future modification to it throws an exception in the innermost function the promise will never resolve. The last version handles this case automatically.

                That may be true, and it sounds like a reasonable justification. But this justification was missing from your initial reply. In your initial reply, you said the code could be “improved” by doing it your way, because your way “looks a little bit better”. How the code looks is not a strong motivator for investing in this kind of change — at least in my opinion.

                1. 5

                  Code does not need to be amenable to change if the feature it supports is scrapped or the company shuts down before code needs to be changed.

                  I guess we just have different experiences with code lifecycle. For me code must be correct first and readable second as it makes maintaining it easier and successful software is always improved as more features are added.

                  But if you “don’t care if some code is brittle” because “company shuts down before code needs to be changed” then I guess you never need to think about this.

            2. 1

              I am not a javascript person. Can you please explain what this is doing and why I should care about the fixes? I’m sorry but I legitimately don’t understand enough about high-meme javascript to know why this works better.

              1. 1

                I’m not sure what is “high-meme javascript” but generally in code (JavaScript or not) one aims for a high signal to noise ratio. That is avoiding boilerplate if there are simpler constructs. For example when working with promises the Promise constructor is rarely needed. Actually it is used only when bridging Promise-enabled code with non-Promise-compatible one such as old API using callbacks.

                One particularly powerful construct for simplifying code is async functions. They let the programmer write simple synchronous-looking code that under the hood will operate on promises and automatically call “then” what it is necessary correctly propagating errors inside of it.

                The other change (response.ok instead of checking for 404) makes sure you don’t add to cache responses such as temporary 500 errors.