[Robin]: Jonathan Snook wrote an interesting piece earlier this month about why he found it so difficult to learn React:
When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.
Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”
I think this is the problem with any large codebase where it’s difficult at first to see all the various seams between technologies. It’s difficult to see how the old code is threaded into the new code and it’s difficult at first to know what the right thing is to do under these circumstances.
Every new codebase feels like a maze; components are threaded together and rely on one another for no apparent reason, data will get piped down through several components at once – all in separate files – and it gets hard to see the shape of the web-like code structure.
And what looks relatively simple in the UI and in the browser could be phenomenally complex under the hood.
How do we get over this feeling when we start to get lost inside a codebase? Well, I think we have to be a lot more patient with ourselves. Getting to grips with a complex system is going to take a lot of time and energy. The more time we spend getting angry at ourselves for not understanding things, then the harder it will get to focus and to learn.
Jonathan continues:
It was difficult to come in thinking I was a senior developer and instead feeling like a junior. I often spent more time than I should have on my own just trying to understand things, frustrating myself in the process. I’d go a day or two or three of making no progress before reaching out to someone to explain something I didn’t understand but feeling like I should, feeling like I wasn’t good enough.
I’ve worked at my current gig for more than three years now and I still have a ton of questions about how things work and the curious ways in which they do. I think we should not only be more patient with ourselves, but we must also be kinder to those that are just getting started.
There are certain words we can avoid when writing or talking about technology; obviously, basically, simply, of course, etc. And this isn’t out of some half-hearted way to be nice or overly sensitive or something – it’s because learning about technology and web design is hard enough without us being jerks about it all.
Obviously.
? From the Blog
CSS-Tricks is twelve years old!
We’re celebrating our twelfth fourth of July! Chris jotted down a couple of notes about how the site is faring with readership, a few thoughts about advertising, and also about the latest redesign:
The aesthetics of it still feel fresh to me, 6 months later. There are no plans at all yet for what the next version will be. I imagine this one will last a good couple of years with tweaks along the way. I’m always working on it. Just in the last few days, I have several commits cleaning things up, adding little features, and optimizing. That work is never done. v18 might just be a more thorough scrubbing of what is here. Might be a good release to focus on the back-end tech. I’ve always wanted to try some sort of MVC setup.
(Tim Severien’s fireworks pen is also pretty dang nifty.)
Menus with “Dynamic Hit Areas”
Dropdown menus! They can be super tricky to make sure they’re accessible and easy to use and in this post Chris takes a look at the issue:
The second you need to implement a menu that uses a hover event to display more menu items, you’re in tricky territory. For one, they should work with clicks and taps, too. Without that, you’ve broken the menu for anyone without a mouse. That doesn’t mean you can’t also use :hover. When you use a hover state to reveal more content, that means an un-hovering state needs to hide them. Therein lies the problem.
You’ve probably experienced something like this in the past and I know just how frustrating it can be to try to select an item before the whole menu disappears.
Hey, let’s create a functional calendar app with the JAMstack
Chris Nwamba wonders what it takes to build a Google Calendar-like interface with all the benefits of the JAMstack and then does just that. In this fantastic article, he digs into how he built everything from the front-end in React to the database with GraphQL and the durable functions.
My plan was to build something that looked like Google Calendar but only demonstrate three core features:
• List all existing events on a calendar
• Create new events
• Schedule and email notification based on the date chosen during creation. The schedule should run some code to email the user when the time is right.
It’s sort of wonderful that all of this is possible to do with just one person. I think that’s why Chris has been so gung-ho about how serverless gives front-end developers superpowers. In short, serverless changes everything because we’re now so much more capable to build things that would have taken a team of a dozen to build and implement a decade ago.
That’s why the combination of these technologies is miraculous.
Web Unleashed
How do you keep pace with today’s fast-moving updates in front-end development? One way is to head to Web Unleashed 2019. Join other developers for this two-day conference that pulls together more than 50 presentations, panels, live-coding sessions and round tables featuring an impressive line-up of speakers, including our very own Chris Coyier who will be talking about our changing roles thanks to tools that are making us more powerful than ever.