Front-End Developer Handbook | Hacker News Reader

Front-End Developer Handbook

frontendmasters.com

220 pointswyclif70 comments

"A developer who can code the front-end, back-end, API, and database isn't as absurd as it once was (excluding visual design, interaction design, and CSS). Still mythical in my opinion, but not as uncommon as it once was."

I see this attitude expressed a lot among people who identify as "front end" developers and it seems like psychological projection to me. I would count myself and a number of close friends and associates as these mythical "full stack" developers so (in my circle) I don't think it is uncommon at all.

One thing I have noticed (again, in my circle) is that "front end" developers tend to start learning with front end development and are commonly self taught, while "back end" guys are more likely to have a degree and start with something enterprisey like .NET or Java. From what I've seen, back end guys have a much easier time moving to front end than vice versa.

Agreed. Just look at this article: The Death of Front-end Developers (https://medium.com/@jerrylowm/the-death-of-front-end-develop...)

The author states: "Even without the divide on the front-end I still hear lots of people claiming they’re full stack developers — I guarantee they’re not."

I don't understand his perspective here. If you work on the front and backend then you are a full-stack developer. If on the other hand, a full-stack developer claimed to be an expert on both the front and backend...then I would be wary.

I was a backend dev who can now also do frontend :)

Yeah I hate the we're going to redefine full stack developer to mean world renown expert on front end and back end. And then say there are no full stack developers.

When there are plenty of products that get shipped everyday by "full stack developers". Who don't necessarily identity as exclusively a front end or back end dev.

Fully agree. I work on a small team (3 devs + 1 designer) and all three devs are, to some degree, full-stack. We all have areas of relative strength and weakness, but all can and do work across the full stack.

It also seemed pretty absurd to me that the author suggested the only reason any kind of full-stack developer is conceivable is JS on the backend, as if the main issue is needing to know more than one language.

I think part of the attitude is that there's a lot of very cheap and inexperienced front-end devs who claim to be full stack to impress potential clients. Many freelancer directories are full of these people, and clients often end up paying more in the long run when they have to hire someone else to fix all the problems that start popping up.

This last sentence made me think, it's probably because people who start learning from the backend have an understanding of the whole stack from the bottom up, whereas those from the frontend start with a much more distant abstraction and gradually discover the underlying layers of the system.

Agreed - almost every developer I know can code full stack. They are typically better at some parts than other, so they choose to specialize, but the full ability is there. I see it even more often outside of the startup world - in Enterprise IT, you normally not only know the full stack, but multiple products at each level to support all the products that end up running inside a large company. Again, you are not an expert in everything, but you gain a broad knowledge base. And such a knowledge base, held by almost all enterprise IT coders, is hardly mythical.

This is my first encounter with negative sentiment around the phrase "full stack engineer" and I would caution newcomers to the industry to take OP's advice with a heavy dose of salt.

My experience has been that if I do not accurately represent my skills in an interview screening as a full stack engineer, I am less likely to make it to the next stage of the interview process.

Most importantly, be honest about your strengths and weaknesses.

Are you able to fully configure webpack? Do you know how to animate with CSS? Do you know Greensock? Three.js? Babel? The differences between ES5,6,7? Co.js? ES generators? Webassembly?

Being able to hack out a little Js and css to make an Enterprise dashboard imo does not a front end or full stack developer make.

I have one of those 'college degree' thingys and I'll tell you something....imo CORRECT front end development is way more challenging than back end development.

That's a nice set of buzzwords but nothing complicated. Babel is just a transpiler. ES versions are like any other programming language with versions, use Babel to solve. ES generators are just yield functions that have been around for decades and finally getting to JS. What about webassembly? It's just a compilation target for other languages and delivery format for the browser.

And why is configuring webpack always mentioned as a complicated thing? If you can code all the above then why cant you make a simple javascript app return an object following a schema with an input, output and list of loaders?

Of course! Databases are just more complicated spreadsheets! And puppet is just scripts that configure servers. And encryption is just a few math equations that mask data.

Man when you put it that way I just realized how trivial all technology is!

Really anyone can do it without years of experience and training!

Who knows why the salaries are so high!

I'm not sure what the point of your comment is, but the large number of 3 month bootcamps that create frontend devs does seem to show that anyone can do it.

I'm calling out the fact that the things you mentioned and the concepts behind them are not unique to frontend and certainly not even that complex. All it means is that the frontend landscape is finally catching up to traditional backend languages and dev practices. We've had compilers, multiple language versions, and environment targets for a long time. We've had functional programming, event sourcing, actor systems, immutable data, and materialized views for a long time. We've used DSLs and full programming languages to create config objects and execution paths for a long time. We've had async and multithreaded programming for a long time.

None of this is new or suddenly challenging, which goes to the original point of this thread that backend skills tend to move much easier to current frontend dev than the opposite direction because of what's involved. I'm not sure how much backend experience you have, if any, but naming assorted buzzwords and claiming that configuring webpack is complex only seems to reinforce my comments.

Actually making things happen with the technologies is alot different than being able to spout general principles on how they work on the internet.

Your trivialization of these technologies makes me think you're possibly a first/second year computer science student who's never actually worked with any of them and mainly read a modern javascript overview page on the web or a rundown in a textbook. Or just a troll!

Ok... but again, what does that have to do with frontend vs backend which is what this thread is about?

The concepts define the complexity, and my point is that they are nothing new so why would frontend be harder when it's only catching up to backend environments? No amount of buzzwords changes that.

There is no "correct" front end development. You need to say no or stop to all the noise coming from everywhere.

You're saying there's no best practices? No lessons learned from a decade of front end development. That seems inaccurate to me.

Incidental vs. essential complexity.

"A whole lot of developers adopt static type checking for mostly subjective reasons or band wagon emotions. Some sell out completely to Typescript and the Microsoft way of doing things while others take on a slower approach with Flow. One thing is for sure, most developers don't need types, they are simply complicating already complex problems and solutions. Like most things, most of this trend is subjective dogma not objective value."

Wow, biased much. I love JavaScript and ES6. But anything that I work with a team on or expect to live beyond a month or so, I love types for. Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system. And if you need to eject you can with Any. I used to prefer pure JS (or Python), certainly quicker to prototype, but also more difficult to grow and maintain. Tradeoffs in both directions. Such an amateur statement makes me question the rest of the document.

> "Some sell out completely to Typescript and the Microsoft way of doing things"

> "this trend is subjective dogma not objective value"

Ironically, the author own phrasing is not objective and somewhat hypocritical. S/He described the use of Typescript as "selling out and the Microsoft way of doing things". S/He's trying to leverage anti-Microsoft sentiment to boost her/his argument. Feels more like a smear campaign then an objective opinion.

To be fair, the anti-Microsoft sentiment didn't just pop up out of nowhere. I've been burned by Microsoft's bullshit so many times that I will go out of my way to deny them any semblance of power, lest they try to leverage it for some new anti-consumer vendor lock-in scheme.

How's that old saying go? Fool me once, shame on you. Fool me 47 times, shame on me.

Anti-MS sentiment is related to its business practices and perhaps dev community itself, not tooling.

I've never seen a person who actually is familiar with Typescript say anything negative about it, and it has huge uptake in the open source community.

Oh Microsoft has also been involved with tooling, you know how they sold that SOAP crap. They made it complex by purpose, so you had to buy tools to work with SOAP.

Ref Book: The New Kingmakers

"It’s hard to feel too sorry for SOAP’s creators, however — particularly if what one Microsoft developer told Tim O’Reilly is true: “It was actually a Microsoft objective to make [SOAP] sufficiently complex that only the tools would read and write this stuff,” he explained, “and not humans.”"

Ha... there are def many things they've been involved in that were questionable from that perspective, but I'd still put that under the domain of business practices.

I guess my take is overall they earned high marks from the dev community despite whatever misses they may have had over the years.

I'm not a Microsoft hater but I also haven't needed their software for my job in quite some time. I am however a Microsoft Project hater (don't ever try the auto-level resources function). But someone was demonstrating (Terraform I think) using Visual Studio Code and I fell in love with the editor. It's now my primary IDE, it's Microsoft and it's completely OSS.

To be fair?!

I was addressing the phrasing and lack of objectivity of the Typescript statement. At no point did I discuss the merits of anti MS sentiment.

Yes I agree with you that MS has burnt people in the past. At the same time it's not binary so 100% of MS != evil.

apple is the new Microsoft, and people keep throwing money at them...

also, even though the MS anti-sentiment didn't pop up out of nowhere, it's not relevant in the static-vs-dynamic typing discussion...

won't get fooled again :)

Completely OT:

Unfortunately I can't hear that song anymore without picturing the opening scenes of CSI Miami.

He/Him. The author has a clear preference[1], please use it.

[1] http://codylindley.com/

> Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system.

If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with giant methods that are impossible to make sense of.

The interview question I’ve been asking lately is about object design. I tell them not to put things into one big method—that it needs to be readable for junior devs. They always ignore me. The ones who struggle the most are the ones who try to do it in a staticly types language (which I’m sure you agree is crazy to use in an interview for a tiny problem). Their mental model forces them to think about types first, and they then can’t think about anything other than that and just making the thing work.

If you aim to keep your objects and you methods small enough that anyone can read them and make sense of them, then you don’t need static types and refactoring becomes easy. There are plenty of developers of mediocre talent who never use types and are able to build huge features and projects quickly and with high maintainability and flexibility because they write code that sticks to good object oriented design principles.

A class I work on regularly has become so big that everyone, especially the more senior, more talented engineers at my company are too afraid to touch, let alone try to refactor. It’s stayically typed.

I can't relate to this line of thinking at all.

Your one big method interview example - so you think had they not been able to reply on static typing for refactoring in their previous work they would have gravitated toward cleaner code? That just seems wildly speculative as a counter to me. A fair amount of projects don't get the refactoring they need in the first place, so developers working on those don't get the experience to begin with. Developers who write large functions often have reasons like "if you use multiple functions you have to jump around to see whats going on." If i'm attacking a straw man, its unintentional.

Anyway having unit tests in a projects would encourage smaller units more, you can have tests easily in static languages - so you get the best of both worlds - smaller units and the ease static typing brings to refactoring.

The go-to sources on writing good code in c#/java land are proponents of keeping methods and classes small as well - that's where i learnt from. (Not to start any wars on over use of design patterns)

Your comment assuming we'd all agree choosing a static language is a bad choice for a small example is also very strange to me. When i'm under pressure id go with what i'm most familiar with, likely C#. Though, with JS and PHP being my dynamic alternatives, i may just be sounding like a very bad programmer to you ;)

I've seen plenty of very long functions in javascript (and c#), and dont think it has anything to do with static typing.

Sounds like you're permanently stuck living in amateur hour... I have never seen anyone past high school level CS try to pull the shit you describe. Those aren't problems of static typing, they're problems of poor dev talent.

I don't know why you're conflating using a type system with writing large classes.

At question is whether the benefits of static typing outweigh their costs. From my experience (purely anecdotal) static typing provides a false sense of security that encourages bad practices, thus turning the benefits of types into costs themselves.

To me, that sense of security is not false (even 90% reliable is better than 0%). And to suggest that type systems are a contributory factor to developers writing functions/classes that are too large is completely unsubstantiated.

Looking back and forth between code and docs just to remember the shape of returned objects is annoying and probably the worst for productivity.

I imagine most people using vanilla JS have significant amounts of objects memorized.

IDEs like webstorm can ostensibly be quite helpful if you use jsdoc style annotations.

However, in my experience, once a code base is big enough, you can open almost any file and find documentation that's out of date, incorrectly copy-pasted, or some other major issue. TS, on the other hand, at least forces you to stay correct, which is ultimately what convinced me to switch.

> jsdoc style annotations

Which are a form of type annotations. Case in point: the typescript compiler can actually parse those, in .js files, and yield appropriate warnings on errors. See the //@ts-check annotation.

It'd be a lot less effort to just use TS imho.

Edit: I meant jsdoc-style, not "style annotations".

IF there any docs!

Types are not the only game in town, schema style solutions (like Clojure(Script)'s spec) have many things over static type systems.

You can use both, ala tcomb or io-ts

There were so many overtly biased and misleading statements in just the first page that the whole work lost credibility.

Hmm, complicated? I think JS’ type rules are much more weird and complex than the average static type checking solution.

I had an epiphany recently when I realized that I had spent about 40-50% of my time on a recent project writing type checking conditionals and unit tests that would have been obviated by using a type system. I am considering typescript for my next project.

Context means everything. Is the author working on a startup with weekly sprints and a small dev team, or an enterprise app with 400 devs and a legacy codebase in a waterfall environment?

The author strikes me as someone who has a very narrow breadth of experience.

Agreed.

There are trade-offs between choosing typed and non-typed languages. It’s not wrong to prefer one or the other. But to accuse the other side of selling out or not having objective reasons for the choice is naïve.

Don’t assume that everyone who disagrees with you is stupid. It only demonstrates that you lack an important skill of critical thinking: the ability to consider others’ perspectives and understand them.

The title should be Web Front-End Developer Handbook.

Native desktop, mobile, TV and infotainment systems are also front-end.

I don't understand why you're getting down voted, but this is absolutely correct and more specification is needed when it comes to "front-end".

I come from a traditional front-end background (for web) and I send many front-end jobs for my company RemoteLeads as well. Front-end is the most fragmented programming job category and I'm sure it's the one that gets the most applicants.

Companies will say they're looking for a front-end developer with JavaScript experience. In reality, they need an engineer. They need someone who understands Computer Science principles and can express that in JavaScript. But, because "JavaScript experience" can mean anything they'll get a lot of applications from Front-end Designers who are more on the HTML / CSS end of the spectrum.

And now with things like React Native it's getting even more complicated.

Ultimately, it's because knowing HTML, CSS, and JavaScript makes you such a powerful developer and you can do a lot.

To combat this the title has to be more specific. What do you need accomplished? Engineering? Design? It's not just front-end, be more specific.

Jerry Low put it best in his article titled The Death of Front-end Developers (https://medium.com/@jerrylowm/the-death-of-front-end-develop...)

I read the Jerry Low article and comments.

On the front-end, I feel like you can group people into two categories:

- Front-end/UI designer - UI specialist with HTML, CSS, wireframing and some JS skills

- Front-end developer - JS engineer typically leveraging JS frameworks and Bootstrap

In the comments section of Jerry's article, it feels like there are a bunch of HTML + CSS specialist who need to re-position themselves as UI designers. They are being displaced by front-end devs who can leverage Bootstrap to do the bulk of the UI. They can work with a UI designer to put together the workflow and tweak the UI.

Jerry also states: "Even without the divide on the front-end I still hear lots of people claiming they’re full stack developers — I guarantee they’re not."

Definitions are complicated, it feels like they should be static when the definition of what a front-end developer does is always changing as technology comes up with different mediums like smartphones, watches, VR, etc.

I've thought about this a lot and I would say something like this:

A front-end/UI designer is concerned about the _user_ interface with the application, that is, how a user interacts and utilizes an application.

A front-end developer is concerned about the _client_ interface with the application, such as what browsers support what and how you can work with that, screen sizes and how to best utilize them(can't have a full word processor and keyboard in a smartwatch), how do you flow data through the client in a way that it doesn't hog the system's memory or makes everything slow, tradeoffs between server-side and client-side rendering, caching, optimization, optimistic UI, unstable connections, progressive enhancement and graceful degradation, and much more.

Of course, this doesn't mean a front-end developer/designer won't have to dabble in both roles eventually.

I appreciate the fact that Jerry Low's article is not quite as vicious as the title makes it out to be. A bit clickbaity the title, but the actual article makes a good point to separate the design portions of front-end dev from the wiring up the servers and databases portions of it.

Technically you're correct, but... web browser is the default front end.

Technically command line programs are also front end.

And many infotainment and desktop frontends are just web UIs...

It is surely not the default frontend on many business that still rely on native apps, on mobile devices, device displays, air gaped networks, factory automation and robot control systems, ....

Yes, but the web browser is ubiquitous so it's naturally going to sponge up defaults.

If someone's mad that people don't auto-assume they design robot neural interfaces when they call their self a front-end designer, then they're just fighting their own ego.

That is just like saying that we should all start calling our compilers transpilers, given that the word misuse is so ubiquitous among JS devs.

This is why I prefer the title UI Developer. It abstracts away the particular technology of the moment, and recognizes the commonality of all human-computer interface development.

Congrats to putting this together; I like it.

At the risk of preaching to the choir here, however, I feel like these days Web dev publications don't sufficiently focus on foundations (HTML, CSS) and jump to JavaScript-heavy solutions a little bit too early for my taste.

As a consequence, I frequently see Web dev newcomers ask questions such as "What framework should I use for (basic website)" when of course for the requirements at hand a simple static site will do, and thus is preferable. See [1] for an example.

It might be all very clear to older devs (like me) who have seen the Web evolve during the last (almost) 25 years. But I'd imagine for 20-somethings or younger the "trifecta" of HTML/CSS/JS as they are today will be a giant puzzle when presented as a whole, having aggregated many features and workarounds that can only be understood in the discourse of the time. In particular, JavaScript is IMHO a terrible beginner language, the design rationales and compromises only apparent to someone with a little bit of compiler writing background, and in the context of its original purpose.

[1]: https://www.reddit.com/r/webdev/comments/8bi1bc/creating_my_...

http://bettermotherfuckingwebsite.com/

It looks like a book at first glance but is really an outline with a list of references to other locations to read more about each of the topics. Useful but no new or interesting content on its own.

Do other devs tend to agree with the idea of full stack being a myth? "A developer who can code the front-end, back-end, API, and database isn't as absurd as it once was (excluding visual design, interaction design, and CSS). Still mythical in my opinion, but not as uncommon as it once was."

I've been FS for most of my career, mostly the result of working in smaller dev teams where you had to own product from top to bottom. I'm willing to admit not being an expert in all the areas and perhaps that's the catch. I also have to disagree with the timing idea, if anything, I feel I was more an expert in the past (despite JS being my top skill) before the exponential increase in JS tooling and framework complexity hit the scene. So, 10+ years ago, I was writing FS application. VBS on the back-end in ASP classic, build out the schema in T-SQL(Sybase), build out our own psuedo-mvc in VBS to server JSON for XHR requests from the client that we then wrote with the help of PrototypeJS. I knew ES3 like the back of my hand and often had to contribute to SQL queries a couple hundred lines long. VBS wasn't that hard (just annoying) and ASP classic pretty straight forward. Now even though JS is everywhere, things are much more config and library dependent and the shift has been a challenge for me.

I'm with you, what do you call someone who can build and ship the back and front end of a working application, if not a full stack developer?

Because its pretty obvious a bunch of these people exist,

Most small/middle companies hire people with a CS degree who can create a data model, some APIs in any language and then build a JS web app calling those APIs. Well, at least that’s how companies work in France. Not sure what’s mythical about these profiles, they are the most commons from my experience.

Not sure I'd call this a book. It's a colossal link dump.

There could be a sibling publication containing links to 1000 MOOC courses calling itself "The Renaissance Man Handbook".

Noticed that "Learn Node.js" is a single short page. These days, I think frontend devs are increasingly working with complex build and test flows that require deeper familiarity with Node.js, for example, npm, Webpack, etc.

"Here's a guide for you to make 75K a year, learning all of this will take 10 years." LOL

Can you show me where this was said or inferred in the article? I'm a front end engineer and I make, well, a LOT more than 75k.

The picture inserted from payscale or salary.com

Reply on news.ycombinator.com