1. 45

  2. 15

    This is a great overview of things to bring up when someone on their high horse is trying to denigrate your profession using knowledge culled from a brief interaction with Wordpress or something else equally terrible.

    1. 4


    2. 8

      It’s been about 4 years since I shipped any $work production front end, and 2 years since any side project.

      I was happily surprised by this article. Judging a post by it’s title I was nervously expecting “React ES2019 Webpack Babel Gulp sauce!” But its just some nice browser native capable stuff.

      1. 8

        Totally. I was very happy that relatively simple things can be done with relatively simple tools.

        1. 1

          I’ve primarily focused on native apps, but keep having a pining to learn js and play with some of the new buzzword compliant tech (webpack / webassembly / possibly react native) to get an idea of performance. Any reading recommendations on this front?

          As much as I like native apps, some of the future ideas I have don’t quite fit the mold of writing for a single platform at a time / have a desire for leveraging urls.

          1. 2

            It really depends on what kind of product you are creating. If you are serving content to people to read or watch, then stick to the kinds of things as noted in this post: HTML+JS+CSS. If you are making games, go webassembly, and if you are making heavily interactive SaaS apps, then read this treatise below…

            I more or less gave up on the whole front end, aside from some useless follies here or there, because it’s just moving too much and I couldn’t deal with it anymore. After a good 15 years of vanilla javascript plus some jQuery, I learned the first versions of React by following the docs provided by Facebook and building some projects, and then they deprecated the whole thing and moved to ES6 classes and Babel! I shifted into a different role at work that doesn’t go near it aside from the odd demo of the search tech we build.

            Aaand, because it moves so fast, there’s nothing good to read! There is no seminal book or publication that has a shelf life of more than 3 months in this crazy space. It’s just surfing rapids. The punchline is, sorry, but I don’t have any general reading advice. But I can say that find a project you want to build, pick a stack, and do it. You can’t really go wrong with any choice right now…because you can just spend time learning something else. The basics laid out in this post above, plus hardening your javascript and browser skills, is where the gold is. Frameworks are just sugar.

            1. 3

              For $work, I have been keeping up with ‘modern frontend’ (backbone => angular => react/redux/graphql/flowtype).

              Despite some of them being very well built, I see them usually failing the teams that adopt them.

              They are almost always adopted for performance reasons, but they only actually improve performance if you’re putting in an heroic effort. Most teams and most apps end up with a better performance/effort ratio by rendering HTML and CSS and using <a href="/whatever"> for page transitions.

              1. 3

                Yes! I think that what happened was that while people spent years coming up with cool new JS frameworks, server hardware and bandwidth improved enough that server-side rendering stopped being the problem it was in the mid 2000’s.

                1. 4

                  I was looking at perf for an (admittedly simple) service in golang and was astonished to see a 3-digit number for the response time.

                  Surely, it couldn’t take hundreds of milliseconds to render this page, I thought - then I saw the unit was microseconds.

                  Servers have gotten fast.

                  1. 4

                    The other nice thing about server rendering is it’s much friendlier on bandwidth and slow devices. I think the pendulum is gonna swing back in the next couple of years

                    1. 3

                      Yes, now that battery-challenged smartphones on wireless connections are much more common than beefy desktops/laptops on ethernet, server-side rendering makes more sense :)

                2. 1

                  Thanks, largely thinking about personal writing tools, found pspdfkits post today fascinating: https://pspdfkit.com/blog/2017/webassembly-a-new-hope/

            2. 3

              You can use feature queries in CSS now. CSS Grid is pretty much there (hey Microsoft update your stuff please). CSS even has native variables and you can change them in the inspector and see everything update! Filter effects too.

              On the JS side, ES6 is everywhere, there’s no need to compile actual classes into prototype tricks anymore. (Well, except IE11, but unless you’re working on Big Popular Mainstream Sites you can just not support IE11 :D)

              Speaking of ES6 classes, now you can use the DOM as your component model, with ES6 classes — Custom Elements v1 is a thing, along with the other Web Components specs. For now only supported natively in Chromium based browsers, but the polyfill is good.

              So, the platform gives us the things jQuery was used for — querySelectorAll, classList, making requests, animations… And there’s also a native component model. So what’s left? Well, data binding and templating. So Polymer provides that, with some extra sugar that makes writing elements easy. It extends HTMLElement with layers that give you all the nice things.

              1. 2

                Though for Real Life(TM) you still need a shed load of polyfills to mask the pain, alternatively stiff liqueur.

                1. 2

                  Mostly only if you insist on doing heaps of stuff client side.

                  1. 2

                    I do all my drinking client side, what are you talking about?

                2. 2

                  Does frontend now universally mean web? (or at least webtechnologies?) I’m still somewhat surprised by that assertion.

                  1. 1

                    I don’t think it’s exclusive. I’m a web programmer so “frontend” for me generally means web.

                  2. 2

                    This is a great article. I picked up a few tips and I’ll probably refer back to it when diving back into frontend work.

                    When I got to your forEach code, I vaguely remembered something about having to turn lists of nodes into an array with Array.slice, so I tried running the example code you wrote. Turns out you’re missing a closing bracket on the .forEach call, which I discovered by copying and pasting the example without inspecting it ?

                    As a side note, it also appears to be getElementsByClassName that returns a node list that does not respond to array methods:

                    document.getElementsByClassName('foo').forEach((el) => {console.log(el)})
                    // VM284:1 Uncaught TypeError: document.getElementsByClassName(...).forEach is not a function
                        at <anonymous>:1:46
                    ).forEach((el) => {console.log(el)})
                    // ...list of elements

                    EDIT - apparently you can also use [...nodeList] and Array.from(nodeList) in ES6 according to these answers: https://stackoverflow.com/questions/3199588/fastest-way-to-convert-javascript-nodelist-to-array

                    1. 2

                      Thanks! I updated the code to add the parens I was missing:

                      var divList = document.querySelectorAll("div");
                      divList.forEach(function(elem) {
                      1. 2

                        Huh, I thought querySelectorAll also returned NodeLists instead of arrays!! o_0

                        Anyway, there’s the for…of syntax in ES6 now and it works with NodeLists just fine.

                        1. 1

                          Javascript is nothing if not consistent, right? ?

                      2. 1

                        The title of this made me laugh, but accurate post!

                        1. 1

                          On that last point, the Chrome debugger just became a whole lot better with v60: https://developers.google.com/web/updates/2017/05/devtools-release-notes#step-into-async. This is going to reduce the effort of debugging async JS code by so much.

                          1. 1

                            The main problem with front end development was never the browser, but rather the endless layers/kilobytes of abstraction meant to make everything automatic.