Comment by ajacksified | Hacker News Reader

Comment by ajacksified | Hacker News Reader

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement more or are very fast learners.

To be an effective FE, you need to understand the whole stack - not just how to install a jQuery plugin, but also CSS, Javascript the language, html, where these technologies are going (html5, ecmascript 6), what the back end stack looks like, how data gets from the database to the browser, how the browser rendering engine works, pragmatic optimizations, functional and OO concepts, version control, browser quirks, the TCP stack, and deployment. No, you don't have to specialize in these things, but you need to be familiar or willing to get familiar.

And you're right, most companies don't understand what FE engineers need or what they should be.

Pretty spot on. I'm constantly bothered by people who are "Front End" Engineers and only want to slap some html/css around or only do DOM manipulation.

Sure, you should do that stuff better than me (back end), but knowing how you are getting your data, where it's coming from, etc will only make you better.

but knowing how you are getting your data, where it's coming from, etc will only make you better.

How will it make any difference if they aren't actually making changes to the backend?

Requires you to have to ask them less questions when you run into a blocker. Helps you debug issues.

it helps you help them design the interface or design an API.

Are you just missing the fundamental point of why anyone learns anything? You learn more so you can do more and make more effective/informed decisions.

Requires you to have to ask them less questions when you run into a blocker. Helps you debug issues.

Possibly.

it helps you help them design the interface or design an API.

Ugh, that's a disaster waiting to happen. Dedicated backend engineers are usually terrible when it comes to what the user really needs and how to display it.

Are you just missing the fundamental point of why anyone learns anything? You learn more so you can do more and make more effective/informed decisions.

No reason to be condescending.

My point is that a front end engineer can make plenty of informed decisions without needing to know the schema of the database or the code in the MT. Does the API return what is expected? Yes = bug in UI. No = bug in server. Does the UI need something the API doesn't provide? Talk to the backend dev to get that into the API. It should be that simple.

To be an effective FE, you need to understand the whole stack

I completely disagree. There are a lot of organizations that completely abstract the front end from the rest of the stack and have only UI developers work on a very focused piece.

It doesn't help a UI developer to know the DB schema or the middle tier components. They need to know where they can get the data they need and where to send updates. That's about it. It can be helpful if they know business flow (not necessarily logic).

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how the front end receives and displays the data; for example, to properly implement Backbone, you want a RESTful API. Is this available (or achievable if not)? You have to know your capabilities in order to appropriately choose a pattern or framework.

You're involved- or should be involved- in coordinating with back-end developers on the interface from the front-end and the back end. The implementation of that interface depends on the structure of the underlying system; different databases, such as document-based vs relational, can have subtle differences in how your interfaces are implemented and effect the flexibility of said interfaces.

You only need to coordinate inputs and outputs. If you need to coordinate more than that you've probably got a very coupled system. Especially with web services - REST, SOAP, etc. - who cares if the front end is connecting to a Java application or a .Net application? Who cares if what the FE dev is building is IOS, Android, JSF, Spring, Flex, etc.?

If it's done right, all the details can be (and should be) abstracted away from the FE.

My entire point is - who defines this REST / SOAP / "who cares" layer? If it's strictly back-end engineers, front-end interoperability is not represented. A FE engineer involved in the development and maintenance of this API layer ensures that concerns are effectively recognized - which requires an FE engineer who knows the whole stack. Yes, these details should be abstracted away from the strict implementation of the actual FE code, but that API has to be created in concert.

who defines this REST / SOAP / "who cares" layer

Definition of an API isn't about knowing the 'entire stack'.

A front end dev will need to understand the structure of the API and present needs to whoever is maintaining it but it doesn't matter what the API is coded in since that is most likely abstracted away via the different service interfaces.

Frankly, other than what they are developing the front end in, the only aspect a dedicated front end developer needs access to is the document describing the API so they can make changes there and get their needs to the API owner.

I'd argue in theory, no, but in practice this is often helpful.

For example, I was working on a multi-step activation system where I had to get the user in a certain state no a specific UI element showed up. That required spending 5-10 min. every time to set up that user, which would go away once you use that button, and development would have taken days.

That is, until someone showed me what the Activation schema + model looked like and how to just toggle the boolean or attach an expected relation. You could maybe argue that there should be an admin interface for manipulating model state, but nobody else really would need it: BE devs can already change the models, and business types don't care about this particular state of the user.

> .. how the browser rendering engine works,

since you mentioned, could anyone point me in the direction of good resources for learning exactly this?

I have enjoyed reading through this resource http://taligarsiel.com/Projects/howbrowserswork1.htm

Reply on news.ycombinator.com