The State of Front-End Dev

Last week, A List Apart held a live-streaming panel discussion on the current state of the front-end dev world. It was hosted by Chris Coyier and featured luminaries such as Rebecca Murphy and Una Kravets. Worth a look if you’re into front-end stuff.


I don’t have a web development background and I’ve already been through a couple of ‘layered’ architectural models to get this far. I’m listening to this and I’m not getting the feeling that there is still any agreed definition of ‘front-end’. Do peole who work in ‘this area’ agree?

1 Like

It’s a very broad church. :smile:

1 Like

I wouldn’t. I do both front and back end and it’s reasonably clear which is which.

If I’m doing HTML or CSS changes I’m doing front-end. If I’m laying out data or colouring in boxes or selecting JS plugins or activating JS plugins or testing forms… that’s front end.

If I’m doing SQL or Perl, interfacing with databases or creating endpoints or processing data or fixing forms or otherwise fiddling with the business logic, that’s back-end.

This is clear for me because I make sure to differentiate the two. If the HTTP client is expected to do work, it’s front-end; if the server does the work, it’s back-end. I don’t use any fancy JS libraries that blur the boundary because I generally consider that to worsen the user experience, except in those specific cases of true “web apps”, being so heavily browser-side code that having any back-end at all is almost nominal.

The fuzziest area is in between, e.g. those AJAX calls to REST APIs that have to correctly populate front-end data with back-end code.

Is it really that simple?

Consider the server side generation of an html page using perl and Template::Toolkit - is this activity front end or backend? And if you write a custom filter to format language, is it front end or backend, and if you internationalise the content for the templates, is this front end or backend?

If you create a microservice based solution, is the service responsible for the UI front end?

If I use a webjar in maven to maintain my jquery dependency, to what extent is that front end?

I know a guy who works quite deep in an n-tier stack. To him, everything in the direction of what the client sees from him is “Front End” - so I suspect that context and personal opinion has a little to do with the consideration of what is and isn’t Front End.



I understand what you’re saying but creating TT2 templates is two jobs. One job is understanding HTML and the other is understanding how to render the template. There is no reason one file can’t be in both camps. The server renders the TT2 code into HTML, so the TT2 part is a backend job; and the client renders the HTML, so the HTML is a frontend job.

At the last job it was common to have frontend developers create HTML files and for the backend devs to mark it up with PHP to actually make it dynamic.

If you use a webjar in maven to maintain your jquery dependency then you are doing backend work to support a frontend file. If you were actually writing the jquery code you’d be doing frontend work.

If I create a microservice based solution I have finally cracked and I should be sectioned.

The real problem here is the relevance of the terms “backend” and “frontend”. Javascript is definitely frontend work (because node.js doesn’t exist), but it requires a developer’s skill and knowledge. The fact the browser is dealing with the JS is irrelevant; it is (impure) functional programming, with a subject matter of user interface. The fact that the server is rendering the TT2 into HTML is irrelevant; it is barely-turing-complete procedural code.

The real distinction is how much do you have to understand how to write code in order to write the thing in question? This is not divided between front- and back-end, so who cares whether something is front- or back-end?

Some might suggest the same procedure is valid for the creator of perl based solutions :wink: ?

I came from a PHP job; everything I do is comparatively sane.

1 Like

I started GUIs with a 7-layer model (I’d have to look it up, it was a long time ago) and client processes running on ‘the server’ and display services running on the workstation, so was never quite sure what PC folks meant by ‘the middle layer’.

Where have the middleware and the message bus and the data-access layer gone? :smile: I hate fashion.

Oddly, I’ve already started writing a blog post on application portability. It starts with Cobol and currently ends with containers.

They’re called the Internet now.

I must look out that 7 layer diagram, to see if it still works.

I think we were already on IP when we had all that stuff. I guess middleware is called a framework now. It didn’t mean anything then either.

You mean All the frontend crap is at layer 7. The backend and middle tier nonsense too. The routing and the transport happens down the stack.

As for frontend, this is all you really need to know.

In my day a lot of this crap was called web design, and people intending to write user interfaces which do data binding in javascript were called lunatics.

Proudly sponsored by Bytemark