1. 9
  1.  

  2. 3

    I think the main issue isn’t the frontend per se, as it’s mainly the presentation part of an app, which is clearly extremely important.

    The problem, in my opinion, is that frontend technologies are simply a chaotic mess, between supporting different devices, browsers, screen sizes, etc. All that is so completely different from how the backend is made nowadays, where it’s not necessary to know any of that.

    These differences is what puts the two parts into two completely different categories and people can prefer one or the other (both or none).

    The article mentions the evolution of frontend and packs up the backend to only what we have today.

    Backend is, again in my opinion, sweet to work with because it is mostly straightforward and if it runs on my side then I’m good to go. Deploying and testing it has never been easier, the same can be said for frontend (it’s easier today) but it is still way more complicated and annoying. If frontend improved in such a way that it also became straightforward to make and test, I think it would start getting more love by everyone (even the ones already loving it today).

    1. 1

      What’s front end engineering? Where is the line between design and engineering?

      1. 1

        I don’t design anything, and I also don’t work on backend systems*. If your job involves e.g. turning mockups and API calls into a feature in a browser, I’d say you’re doing frontend engineering.

        * … for the most part

        1. 1

          oh right, so you’re talking the specific layer between a UI/UX/graphic design person who is not doing any coding, and the immediate next layer of a front end programmer who is not doing any design, but taking ready-for-web graphics and doing lots of front-end-framework, javascript, etc. stuff to connect to the first layer of business logic?

      2. 0

        at least for me, the biggest impact that most engineering teams can have is on the front end, not on the backend

        The caveat is important, because I don’t think that’s true for all places (and I say this as a full-stacker who is more focused on front-end).

        Back-end is certainly moving towards being abstracted away (see Serverless) but I just think that makes being a full-stack dev easier with more time/focus spent on front-end, but I really believe it’s hard to not think about back-end when working on UIs these days

        1. 12

          Back-end is certainly moving towards being abstracted away (see Serverless) but I just think that makes being a full-stack dev easier with more time/focus spent on front-end, but I really believe it’s hard to not think about back-end when working on UIs these days

          I feel like this is something of a false representation of both frontend and backend that’s becoming pretty common. “backend” now means “CRUD interface to a database” to a lot of people, but there’s soooo much more to software than just serving up some webapp. The “backend” to say, a DNA sequencer, or radio telescope, or a CAD system, or tons of other things is never going to be abstracted away in any meaningful sense.

          1. 1

            Agreed, but I will say most articles are referring to front-end/back-end in the context of a web app. I will concede that for systems programming front-end means the UI layer and back-end may mean the DB or business logic layer, which is far more customized than the standard CRUD apps running on a web server.

          2. 7

            Back-end is certainly moving towards being abstracted away (see Serverless)

            Serverless doesn’t abstract the back-end away, though? It just means that you spend less time on infrastructure, but you still have business logic, now it just lives on a function-as-a-service platform rather than in (eg) your node or python application running on an EC2 instance.

            At the same time as that’s happening (I’d argue it’s not really happening that much, I think serverless is a very tiny segment, and not growing all that fast) there’s a move in the opposite direction with GraphQL bringing things that used to be the domain of the back-end code into the front-end code. It’s greatly expanding the scope of the front-end - now you have to understand the structure of your data and write queries (granted, you may not have to understand past the GraphQL server layer) as well as all the other things that go already into a web application. Previously you might have punted a lot of that responsibility to whoever was writing the endpoint you were using.

            1. 1

              Serverless doesn’t abstract the back-end away, though?

              It is abstracting away a lot of the back-end ORM boilerplate in favor of a much simpler function-based API. GraphQL is also a great thing I agree because it is sharing that responsibility with more developers

              1. 1

                I’m really having trouble parsing this. Could you provide an example?

                From my pov serverless, at best, makes backend deployment as easy/hard as frontend deployment (you don’t have to manage the os or install the browser(s) displaying your UI).