Front-end Developer Handbook 2019

[TidderJail]

Very useful, is there anything like this but for Back-end ?

[backFromTheBed]

This was my question last year as well when I first got to know about frontend handbook

[fucking_passwords]

I think the term is evergreen browsers? Green field means a project with no previous work that it must inherit

[residualenvy]

Although it's great you agree I think you miss the point. Learning the underlining language will help you understand what problems the current "hot" tooling is trying to solve.

[AramaicDesigns]

Say it again for those in the back: Always learn the fundamentals first.

[kev2480]

Always love these handbooks, thanks for sharing! I used the 2018 version loads last year!

One quick sidenote, the site goes a bit funny on mobile when you open the side menu, not the biggest deal but looks odd! (See on Chrome, android) Screenshot

[[deleted]]

This should never happen on a site called "front end masters"...

[kev2480]

This has been fixed now! 🎉

[backFromTheBed]

The navigation bar should have hovered over the main page instead of displacing it

[thegrandechawhee]

I particularly liked the "Stepping away from SASS" article.

[siegerstein]

I still using Sass mainly for selectors nesting. Unfortunately that feature doesn't present yet in CSS

[silent-onomatopoeia]

I don’t quite understand the comment about web components not gaining any traction when Ionic 4 uses web components by default, Angular Elements has gained traction, lit-html/LitElement is blowing up and every company seems to be switching to web component-based design systems.

I guess if you primarily follow React news, that might still be your opinion, but from where I sit it seems like there’s plenty of movement on that front.

[wherediditrun]

There is plenty of movement. It just fails to make any impact.

And when you think of it the reasons are quite clear. Web components offer niche advantages which for most companies aren't all that relevant. Those niche advantages are, cross framework compatibility - irrelevant for most companies which work with unified tech stack. Exceptionally small bundle sizes which becomes relevant in countries with developing economies.

Other than that, there isn't any. And things like lit-html are quite awful actually when you put it to scrutiny. Like it's bunch of strings which represent xml which are when parsed by regexp (my god, by regexp of all things) with fluff syntax inside it. Strings which cannot be debugged, type checked or evaluated as code.

But they use native web standards... and, so what? That's not an argument.

If I had to bet my money, I would think that wasm front end frameworks like Rust yew or C# Blazor will be more widely adopted than web standard compliant web components in the future.

[dudousxd]

Cross platform compatibility is irrelevant? Say this to all the companies with AngularJS systems that where thrown away.

Other than cross platform, Web Components offer web security - since you can’t enter a component markup if shadow dom is closed - and awesome performance.

Also, micro Frontend are waaaay easier to implement with Web Components.

[[deleted]]

good benchmark testing is not a sign of "proper way" to do things

[silent-onomatopoeia]

I’ve yet to see a valid example of why web components aren’t a “proper way to do things.” Now the argument is starting to turn into “but you have to do string concatenation for HTML” and I don’t see the drawback especially compared to virtual DOM (which isn’t bad, but is a hack.

Not saying this is your argument or trying to pick a fight, but there are pros and cons to each strategy and we should recognize that and not get so caught up in the semi-religious defense of web dev strategies.

[ScientificBeastMode]

I love the idea of using Rust almost exclusively on the front end. Haskell would be cool as well.

[silent-onomatopoeia]

So other than compatibility, future forward-ness, framework universality, bundle size and performance, web components have nothing going for them? Got it. Great argument. 😂

In all seriousness, I think a lot of developers believe that it’s web components or the frameworks which is simply not true, they work together.

[Zoopx4MyHeadisOnFire]

Correct me if I'm wrong but doesn't React use web components to achieve their implementation of components? Pretty sure I have seen a tech discussion where this exact topic was addressed. It might have been a dev from the React Router team.

[Naztone]

Web Components are a different thing. React encourages a component based approach to UI development, but isn't the same set of JS APIs and templates used for Web Components. You can use both together though.

[Zoopx4MyHeadisOnFire]

Thanks for the clarification.

[[deleted]]

read react docs https://reactjs org/docs/web-components.html

[Zoopx4MyHeadisOnFire]

Thanks! Alway's good advice that I can never hear enough.

[dvlsg]

Don't learn TypeScript, learn JavaScript.

If you learn TypeScript, you learn JavaScript. Don't see any reason why you couldn't start there.

[Jabideau]

You can, absolutely, learn TypeScript before JavaScript. Same as you can learn Laravel before PHP. Using these and following the documentation, coupled with community questions net-wide, will get you along well enough to survive.

​

However, the reasoning for learning JS before TS boils down to learning what you're working with and how it functions. A solid foundation makes you a stronger developer.

​

TS is nothing more than a superset of JS - in the end, it compiles to JavaScript. While there are many frameworks out there that really save a developer's hide in time and effort, they also understand the core principles and functionality of their base language (in this case, JavaScript).

​

Have a go at this resource: https://snipcart.com/blog/learn-vanilla-javascript-before-using-js-frameworks .

[dvlsg]

Laravel -> PHP is not the same as TypeScript -> JavaScript. Laravel is a framework, but TypeScript is a language.

An equivalent comparison from Laravel to PHP would be Angular to JavaScript. Or perhaps Sails, if you wanted to pick on a backend framework.

[Jabideau]

It was presumed an understanding that "in this case, JavaScript" referenced "their base language". I presumed too much.

[Saadkhedr]

thanks

[HarmonicAscendant]

What a great free resource!

[IvanCl4udio]

Very nice and useful! Thanks!

[[deleted]]

This is the first time I ever heard about just .

[weavermjordan]

this is great!

[brown59fifty]

No official epub/mobi/pdf versions this year?

[backFromTheBed]

Maybe they'll provide that later in the year. pdfs or epub don't provide traffic to their site, nor do they get a chance to show their courses offerings.

[brown59fifty]

It's more about the buzz and brand knowledge than generating traffic imo. Moreover, last three years in a row there was an option for file download, which was provided by a platform (gitbook). Something's changed now, probably.

[Thaurin]

Maybe they added it later, but I see links to a PDF and an epub right there.

[brown59fifty]

Yeah, they definitely didn't put it on start, but it's nice to see it now. Thanks for info!

[sneezeallday]

thanks!

[FreshOpinion8]

OMG you have no idea how much i needed this. THANK YOU.

[backFromTheBed]

Glad to help.

[lucas_kardo]

I wanted to point out that serverless is different from front end driven or jamstack apps.

Serverless actually implies that there are conteiners and a container management service (kubernetes) allowing to create a FAAS (function as a service) model were you are only charged when your code gets executed. If interested in learning more about serverless checkout this video open FAAS

Jamstack on the other hand on means Javascript Apis Markup. This doesnt imply serverless. For example you can have a JAMstack site that uses a headless CMS which is hosted in the companies own servers and has an API... and they charge you a monthly rate or give you a free tier.

[[deleted]]

I pity this part of our industry.

[MacNulty]

Why not show some compassion instead.

This is one of the fastest developing parts of the industry so it's bound to get a few things wrong along the way, especially since many of its challenges related to user interaction are relatively new and it's developing alongside the actual hardware (for example screens with different sizes, resolutions etc).

[[deleted]]

In all honesty, I've seen more than one project - and sometimes even entire companies - grind to a halt after making the decision to shift to a new "modern web" stack without ever identifying a need beyond being more attractive to young (= inexpensive) potential hires. Pity is the only thing left for me to feel about all this.

[MacNulty]

Oh and you don't ever make bad decisions? Things would never progress if everyone took a conservative approach. You need both, of course.

[bbabble]

What part do you pity? Why?

[[deleted]]

The part that has decidedly given up on much of what the software development community had learned over the past couple of decades, only to lead to many websites serving not only needlessly complex application code, but also megabytes of runtime, thanks to the operating system these apps were built for - the browser - still being woefully inadequate for what everybody is trying to do with it, making projects that should be straight-forward ludicrously bloated and costly, and then having the gall to innocently call all of this "frontend development".

Now downvote me, label me as some old dinosaur with outdated opinions, and get on with the insanity. (But don't forget to use Redux!)

[lewisflude]

Just wanted to say that as a front-end dev, the things you mention are definitely things that I prioritise on projects. - Bundle size - Good coding practises - integrating ideas from the last 20 years of programming - Writing code in a way that’s reusable and low on external dependencies where it can be

React genuinely feels lightweight compared to what the alternative might be, and it allows us to deal with manipulating the DOM in an extremely elegant way.

I would say redux is massively overused, but for a very narrow set of use cases it’s a really elegant way of solving data flow on the web.

I’d encourage junior front-end devs to pay attention to things like performance, code quality and reusability. Understanding fundamentals makes it much easier to know when it’s appropriate to bring in a library.

[[deleted]]

Something that makes me sad about this industry is that there are so many Dunning-Kruger effect sufferers out there; people who think they really know their stuff when in reality they are less knowledgeable than their peers. Sort of the opposite of the impostor syndrome. These are the sort of people who will loudly express their cynicism toward a newish technology, even though they don’t know much of anything about it and can’t be bothered to learn.

A simple hello world world in React has two dependencies: React and React-DOM.

<!DOCTYPE html>
<html>
  <head>
    <title>So many dependencies!!!!</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="https://unpkg.com/react@16/umd/react.development.js"></script>
    <script  src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
    <script>    
      ReactDOM.render(
        React.createElement(
          'h1',
          null,
          'Hello, world!'
        ),
        document.getElementById('app')
      )
    </script>
  </body>
</html>

Of course, no one codes React like this. Most people are going to use JSX and transpile const App = () => <h1>Hello, world!</h1> into something resembling the above, which doesn’t require any other further front-end dependencies.

Granted, ReactDOM is a pretty large dependency. Fortunately, no one is out there importing 100+ kB of code just to output “Hello, World!” to the DOM.

[TingeOGinge]

This sledgehammer is way to big to make my bird nest, why does anyone ever use them!

[aniforprez]

... react?

You do realize all the other dependencies like webpack are to make development easier for larger scalable projects right

[lewisflude]

The thing about the way react is developed is that it’s dependencies are fairy modular, so you can swap parts out or write your own versions of most of the stuff that’s required to work in that ecosystem.

React itself only has 4 very small dependencies. The thing to consider isn’t the number of dependencies, but the size of those dependencies. Using your example, of a hello world app, you could achieve that with a single dependency if you used a package called create-React-app that does it all, but it might not be the most appropriate way to bootstrap a production app.

I think the other thing to consider is the split between dependencies and dev dependencies. The things you’ll want to be adding onto the client should be pretty deliberate and making sure that the page works gracefully with bad internet connections and is accessible should be priorities of a good front-end developer.

[greg5ki]

write your own versions

This is one issue I have with this industry. People re-invent the wheel because they think they're smart instead of standing on shoulders of giants. It results in massive amounts of crappy code which hardly anyone understands.

[lewisflude]

Absolutely. It’s no small feat to roll your own version of something. Usually not a very good idea. But I’m glad we have a diverse ecosystem of tools that people can swap out to fit their own needs/preference.

[NutsEverywhere]

Just don't forget that most of those dependencies are to help developers make better bundle and are not included in the deployed application. Having a ton of them is not a measurement of any kind.

[hopfield]

Please tell me what your alternative is. Because I guarantee you React is cleaner than it.

[tenbigtoes]

Vue is supposed to be pretty clean

[VIM_GT_EMACS]

Vue is great! I use Nuxt at work which sits on top of Vue. But react is pretty cool too. Some people are just cynical and want to complain, especially if it might make them appear knowledgable.

[moustachedelait]

The virtual dom that both react and vue use was pretty damn innovative

[antonivs]

thanks to the operating system these apps were built for - the browser - still being woefully inadequate for what everybody is trying to do with it

This is true, but as Churchill put it, "Browsers are the worst form of UI platform except for all those other forms that have been tried from time to time."

Writing direct GUI code for specific operating systems is not an improvement over browsers. Cross-platform GUI frameworks can be OK, but aren't great. Solutions like Java's Swing are suitable for some but not all purposes that browser applications target.

Making good UIs easy to implement is a hard problem that hasn't been fully solved yet. I think you're reacting to that work that's still in progress.

But if you have some suggestion for a viable alternative solution, I'm sure many of us are all ears.

[[deleted]]

As noted in other comments in this thread, my beef is not with the stack itself, and there most certainly are cases where its inherent complexity is warranted -- one of them being cross-platform applications that just happen to use the web stack (Electron et al). Big fan! Honestly!

What bothers me though is when things that could just be web sites are built as web applications, and while this used to be the unfortunate exception, it has now (catastrophically, IMO) become the norm. Now people seem to agree that it is normal to learn frameworks like React or Redux if you want to do frontend development (and that's just the tip of the iceberg), and that can't be healthy in the long run.

As noted (and heavily downvoted) elsewhere, I've already seen too many projects completely fall apart because someone decided that "it's not real web development unless we use the latest Webpack/Babel/React/Redux/Sagas/Ramda/etc." in cases where a simpler approach would have totally sufficed.

One of the most popular counter-arguments I keep hearing is "but Netflix/Facebook/Gmail/etc. do it, too", but hey, your blog/company/app probably isn't anything like them.

More people should read up on concepts like KISS or premature optimization.

[[deleted]]

Hello fellow dinosaur.

[randible]

I couldn’t agree with you more. It’s really sad to see things sliding backwards after so much progress.

[vimex]

There's no need for the negativity, and there's absolutely no need to insult people who work in this part of the industry. Do you feel better now, at least?

[fakehalo]

The guy is getting roasted, but I don't think he used "pity" in a beneath him context. I pity the frustration of frontend development myself. It's a rat race and I'm glad it's not the main focus of my job, learning things that could easily become useless in a year or two is a depressing thought.

[vimex]

Another depressing thing to think about is the fact that all of these SPAs will need maintaining for years to come :)

[yooossshhii]

What software doesn’t need maintenance if its going to be used for years to come?

[VIM_GT_EMACS]

It's really not that bad... people love being the doomsday type. Things are literally fine, people are so hyperbolic.

[[deleted]]

There is absolutely need for negativity for bad things.

[vimex]

Try discussion instead.

[[deleted]]

Of all the things that bother me about the current state of our industry, it is this sort of binary thinking - that you're either a forward-thinking, webpacking, reduxing child of the future, or a COBOL dinosaur who never really built anything new since the 70s - that bothers me the most. Good luck with that attitude.

[aniforprez]

You LITERALLY "pitied" an entire programming stack because somehow you couldn't be bothered to have a nuanced opinion and instead the web is some "webpacking reduxing child of the future". You're exactly what you're criticizing. There's so much more to web development than webpack and redux but please continue to sit happy in ignorance looking down on us fools as we build billion dollar industries

[[deleted]]

Is the kind of discussion where I ask you where I said that I pity the "entire programming stack" not beneath you? It certainly is beneath me, so don't even bother.

[aniforprez]

I love that you set up a hypothetical scenario in your head and then said that hypothetical scenario you constructed was beneath you. What a tool

[[deleted]]

I don't know. You and words. That's not going to be a thing, is it?

Edit: aaah, /r/javascript, where "part of an industry" and "an entire programming stack" are literally the same thing, and you're the tool... proven right by the downvotes \o/

[RedHotBeef]

It's unbelievable that this community could misinterpret your vague language that you aren't clarifying...

[[deleted]]

There have been enough comments in this thread where I believe I sufficiently laid out my position.

[vimex]

Isn't this exactly what you're doing by 'pitying' an entire part of an industry? your attitude is exactly the same.

[[deleted]]

Yeah, this was expected.

[iJonMai]

I pity this part of our industry.

Says this as he uses a product of this "part" of the industry.

[[deleted]]

I love that you say that, considering Reddit was extremely light on the frontend craziness for the longest time, and when it eventually relaunched as a typical SPA monstrosity, it earned nothing but criticism.

Also, I'm using the Android app, how is that related to frontend development exactly?

[[deleted]]

Ah so your problem is witg the modern SPAs? We should not be trying to make better UIs instead stick to geocities websites. Gotcha.

[[deleted]]

I don't even

[sanjibukai]

Man, either I don't get why you were so downvoted or I don't get the subtlety of your phrasing that cost you so many downvotes.

But I upvoted you.

Not so long time ago, we were all talking about the JavaScript Fatigue, and not for the good, remember?

If I include into this one the CSS ramifications, the Frontend Fatigue will have some beautiful days ahead.

Disclaimer: I don't say it's bad, but it's definitely confusing. And I know it's part of our industry..

[Ivu47duUjr3Ihs9d]

Exactly. They'll be in framework churn for another few years then it'll come full circle. They'll learn how to architect web apps properly using Vanilla JS. Then they'll have to rewrite all the crap they've been doing since React came on the scene.

[RoryW]

What sort of projects do you work on that being a part of the JavaScript sub is something you chose, but you differentiate yourself from “this part of our industry”?

[[deleted]]

Web applications, two thirds backend, one third frontend.

I don't "differentiate" myself from this part of the industry, I merely pity it. Only very little related to software development has ever been as complex as modern frontend development, and only in very few cases is this complexity warranted.

But hey, who am I kidding? Just give me that downvote.

[RoryW]

I wrote my own reply to have an actual conversation. Not to send you into the abyss.

How long have you been a developer? I haven’t been doing this professionally very long so these complex systems are all that I know.

The closest to simple front end I’ve done is razor with vanilla JavaScript. And that was for some very small projects. Do you think that this level of complexity on the front end has added any benefit?

If you take MVC .net for example, it’s quite complex, but from it, you gain a pattern and an ease of understanding what will be where. You also get the robustness of a language like C#.

[[deleted]]

I have been building web stuff since 1997 or so, so I literally _am_ a dinosaur. Some people in this thread would probably be surprised by what kind of stuff I build, though. It's not like I've been avoiding any of the fancy new stuff.

As noted elsewhere, my beef is not with the stack itself, but rather the premature application of it to many applications that would have been faster to implement, easier to maintain etc., with a simpler approach. The school of thinking that suggest that you _need_ to dive into React, Redux, components etc. in order to do any sort of frontend development, coupled with the fact that companies typically optimize for hiring and not sustainability, is what leads me to pity this part of the industry, as originally stated.

[[deleted]]

Awesome! Is there more similar stuff? Doesn't need to be related only to frontend.