Front-End Developer Handbook
frontendmasters.com
Front-End Developer Handbook
1–10 of 73 posts
Re: Front-End Developer Handbook
#2The title should be Web Front-End Developer Handbook.
Native desktop, mobile, TV and infotainment systems are also front-end.
Re: Front-End Developer Handbook
#3It 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.
Re: Front-End Developer Handbook
#4The title should be Web Front-End Developer Handbook. Native desktop, mobile, TV and infotainment systems are also front-end.
Technically you're correct, but... web browser is the default front end.
Technically command line programs are also front end.
Re: Front-End Developer Handbook
#5The title should be Web Front-End Developer Handbook. Native desktop, mobile, TV and infotainment systems are also front-end.
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...
Re: Front-End Developer Handbook
#6The 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...)
Re: Front-End Developer Handbook
#7"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.
Re: Front-End Developer Handbook
#8"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 no…
Types are not the only game in town, schema style solutions (like Clojure(Script)'s spec) have many things over static type systems.
Re: Front-End Developer Handbook
#9"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 no…
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.
Re: Front-End Developer Handbook
#10Congrats 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_...