The Front End is Unknowable


(Michael Brett) #1

During a Twitter debate between PPK and Jake Archibald about Web vs Native (natch), Jake dropped this tweet that blew my socks off:

Frameworks explosion aside, do you agree with this statement?

And if the statement is valid, should it be that way?


(Jim Gumbley) #2

Wow! I can understand however where he’s coming from.

The problem as I see it is the HTML/DOM model is broken. I’m really excited about things like Facebook React.js which allow you to reason about the frontend in a modular way much more akin to the ‘immediate mode’ used in games - rather than munging state in unstructured JS around a retained and slow DOM which frankly is the key broken element for me.


(Daniel Hollands) #3

I agree with that statement.

I think we’re at the point where being a front-ender now involves a lot of work which traditionally would be handed by devs on the back end.

Case in point, back when I was working in Rugby as a dev, we booked some time with our top front-ender to help speed development of one project in particular. We needed him to look after the front end bits of an AJAX page, while we built the back end. He took one look at what we needed and said that he didn’t know the first thing about AJAX, meaning we, the devs, had to do it all.

I think the terms front-ender and back-ender, once perfectly suitable for the task of describing a role, are no longer suitable.

As I’ve mentioned a couple of times in this post, I refer to myself as a dev, which to my mind means my role revolves around the more logic-based aspects of coding, and is responsible for data manipulation (not so much data display). Seeing as front end frameworks such as angular now require logic and manipulation, these are perfect tasks for a dev.


(Michael Brett) #4

Hmm. I would have thought that him not knowing about AJAX would mean that (at the very least) he was going to have to google AJAX, not just shrug it off.

I’m not sure whether I agree with Jake’s assertion (though he is waaaay more qualified than me to make it). I think that the Front-End can be knowable, provided you have a real understanding of HTML, CSS and JavaScript. After all, isn’t that what we are producing when we use frameworks, templating engines, preprocessors and the like?


(Daniel Hollands) #5

I think he was expecting do so something fancy, like animate DIVs across the screen or something, when he saw it was monkey work, he decided he wasn’t interested… maybe :wink:


(Jim Gumbley) #6

https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-HTML

Interesting post from Tim Bray


(Michael Brett) #7

Good article, and the illustration underlined both Jake and PPK’s points for me.

The more I think about it, the more I am coming to the conclusion that if front-end is becoming too big to grok (as Jake maintains), it’s because we’re trying to hammer the web into an unnatural shape (PPK’s point).


(Andy Wootton) #8

I read this earlier then went on a LinkedIn Agile & Lean group where someone claimed that the front-end developers often sat around waiting for the back-enders before they could contribute. The Agilista’s response was that the FEs needed to learn to BE. This begs the question whether web development is still compatible with Agile.


(Stuart Langridge) #9

…and git, github, LESS, SASS, Service Workers, SVG, browser support, touch events, performance, the devtools, browserify, CommonJS, Chromia, device pixels, image compression, responsive design, responsive images, art direction, BrowserStack, APIs, webdriver, Selenium, and which order the parameters to insertBefore go in.

You don’t need to know everything about this stuff. But you do need to know something about all of this stuff to be good at being a front end developer. The days when you could be an expert in everything for the front end are past. That’s what Jake was saying.


(Michael Brett) #10

Yeah. I think Jake IS right when you look at the process for developing certain categories of web application.

However, I also think that PPK and other voices around the web have a point when they start to grumble about whether trying to keep pace with native is worth it, if the outcome is ever escalating complexity (for dubious gain).


(Omar Qureshi) #11

We did this to ourselves really, we made all these tools and now we don’t have the mental capacity to be able to store how they all work to a good level in our head, instead of just saying no.

There is an (unreasonable) expectation that a front-end developer should know all these things and to be quite honest I’m not sure how we get out of this mess.

Additionally, there is a further problem that to hack around limitations with CSS/JS (this includes development speed as well as actual feature limitations), we just throw in another tool rather than fixing the actual problem.

That real problem is browsers.


(Stuart Langridge) #12

What do you propose that browsers do differently, if it’s their fault?


(Omar Qureshi) #13

One example of something terrible was vendor prefixing

Instead of people just whacking in vendor prefixes which may or may not have worked slightly different and making us hate life for a VERY long time, why not just not bother with that at all, get all the browser vendors to talk about it for a good amount of time and come up with a non-terrible and consistent solution (one without prefixes)


(Omar Qureshi) #14

The pointer/touch events spec is another thing which looks like it’s going to shit with Apple not agreeing to it.

The resulting conclusion? Use another tool.


(Stuart Langridge) #15

What’s the alternative here? If you know a way of making Apple engage more with the browser community, don’t keep it to yourself!


(Omar Qureshi) #16

My solution involves duct tape and a sledgehammer, or at least some good old fashioned shame.


(Stuart Langridge) #17

Go for it. Shame Apple. See how far you get; see if anyone who currently buys Apple products considers this enough to stop them. Good luck.


(Ben Paddock) #18

This is what (stubbed) APIs are for.

Regarding the questions asked. I would agree with the statement, no single dev can know the entire frontend but he or she can know enough. The frontend ecosystem know means that there is an additional skill to learn. That skill is to be able to pick and choose the right thing(s) to use. That’s getting harder to do but it’s not stopping the world from turning.


(Stuart Langridge) #19

Totally agreed with @_pads here, and that was I think Jake’s point. I know enough about each of the things I listed to know where to look for more if I need to.


(Andy Wootton) #20

Since I wrote that, I’ve been doing some Lean research. Lean theory says that having people doing nothing is better than having them do the wrong thing which will have to be undone. I found this difficult to take in the first time I heard it, as I thought it came from Lean manufacturing where material in the process has a cost but it isn’t that. Until the back-end story is done, the front-end story may still be in doubt. I think the logic goes that their time would be better spent pairing with back-end devs to generalise their skills and improve quality.