Tag: Frontend

Why you should hire a front-end developer

Matt Hobbs says you should hire a front-end developer because…

  • “A front-end developer is the best person to champion accessibility best practices in product teams.”
  • “80-90% of the end-user response time is spent on the front end.”
  • “A front-end developer takes pressure off interaction designers.”
  • “If you do not have a front-end developer there is a high risk that the good work the rest of the team does will not be presented to users in the best way.”

Direct Link to ArticlePermalink


The post Why you should hire a front-end developer appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,

Register for An Event Apart’s Front-End Focus Online Conference

(This is a sponsored post.)

An Event Apart has been doing these single-day online “Online together” conferences. You can check out the last couple, which are available on-demand (buy it, watch it when you want) for a limited time:

The next event is one that anyone reading CSS-Tricks will really want to check out. It’s called “Front-End Focus” which is literally what we write about here all the time. Register today for the event! It takes place August 17 and features a schedule packed with amazing talks from amazing speakers, like design principles from Jeremy Keith, future-proofing CSS from Ire Aderinokun, and modern CSS tricks from Una Kravets, among several others.

Direct Link to ArticlePermalink


The post Register for An Event Apart’s Front-End Focus Online Conference appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , ,
[Top]

Increment Issue 13: Frontend

Increment is a beautiful quarterly magazine (print and web) published by Stripe “about how teams build and operate software systems at scale”. While there is always stuff about making websites in general, this issue is the first focused on front-end¹ development.

I’ve got an article in there: When frontend means full stack. I’ll probably someday port it over here and perhaps add some more context (there were some constraints for print) but I love how it turned out on their site! A taste:

We handle this growing responsibility in different ways. Even though we all technically fall within the same big-tent title, many frontend developers wind up specializing. Often, we don’t have a choice. The term “unicorn” once described the extremely rare person who was good at both frontend and backend development, but these days it’s just as rare to find people skilled at the full spectrum of frontend development. In fact, the term “full stack” has largely come to mean “a frontend developer who does a good amount of the stuff a backend developer used to do.”

The whole issue is chock full of wonderful authors:

And the article that is the most right up my alley, Why is CSS . . . the way it is? by Chris Lilley. It’s somehow astonishing, gutwrenching, understandable, and comfortable to know that CSS evolves like any other software project. Sometimes thoughtfully and carefully, and sometimes with a meh, we’ll fix it later.

Once a feature is in place, it’s easier to slightly improve it than to add a new, better, but completely different feature that does the same thing.

This explains, for example, why list markers were initially specified in CSS by expanding the role of float. (The list marker was floated left so the list item text wrapped around it to the right.) That effort was abandoned and replaced by the list-style-position property, whose definition currently has the following, not very confidence-inspiring inline issue: “This is handwavey nonsense from CSS2, and needs a real definition.”

That’s a damn fine collection of writings on front end if you ask me.

A big thank you to Sid Orlando and Molly McArdle who helped me through the process and seem to do a great job running the ship over there.

  1. The issue uses “frontend” throughout, and I appreciate them having a styleguide and being consistent about it. But I can’t bring myself to use it. 🔗 The term “front-end” is correct when used as a compound adjective, and the term “front end” is correct when used as a noun.

The post Increment Issue 13: Frontend appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

“The title ‘Front-End Developer’ is obsolete.”

That title is from the opening tweet of a thread from Benjamin De Cock. I wouldn’t go that far, myself. What I like about the term is that ‘Front-End’ literally means the browser, and while the job has been changing quite a lot — and is perhaps fracturing before our eyes — the fact that the job is about doing browser work is still true. We’re browser people. This was a point I tried to make in my “Ooooops I guess we’re full-stack developers now” talk.

I really like Benjamin’s sentiment though. There is a scourge of implementations of things on the web that are both heavier and worse because they re-implement something that the browser offers better and “for free.” Think sliders: scrolling behavior, snap points, fixed/sticky positioning, form controls, animation, etc.

Our industry seems to have acknowledged that backend and frontend developers require very different skills (even though they often use the exact same language), and yet it’s struggling to see there’s too much bundled into the term “front-end developer”.

That’s the tricky part. That’s at the heart of The Great Divide. There’s an awful lot of front-end developers where their job solely focuses on JavaScript. You could call them “JavaScript Engineers” or “JavaScript Developers,” and that feels OK. However, I’m not sure what you call someone who’s a great front-end developer, not particularly focused on JavaScript, but is on other aspects of the front end.

The modern frontend developer is most often than not a “Jack of all trades” mastering JS (or even just a framework) and barely tolerating HTML/CSS as a necessary evil. That’s understandable. I strongly think it’s a different specialization, and it’s too much for a single person.

Yep, it’s OK! The divide isn’t a bad thing; it’s just a thing. Front-end teams need JavaScript specialists and CSS specialists and accessibility specialists and performance specialists and animation specialists and internationalization specialists and, and, and, and. They don’t have to all be separate people. People can be good at multiple things. It’s just exceptionally rare that people are good at everything, even when scoped only to front-end skills.

The post “The title ‘Front-End Developer’ is obsolete.” appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Front-End Challenges

My favorite way to level up as a front-end developer is to do the work. Literally just build websites. If you can do it for money, great, you should. If the websites you make can help yourself or anyone else you care about, then that’s also great. In lieu of that, you can also make things simply for the sake of making them, and you’ll still level up. It’s certainly better than just reading about things!

Here’s some resources that encourage you to level up by building things for the sake of leveling up, if you’re up to it.

Frontend Mentor

It looks like this recently launched, and it’s what inspired this post. This idea of giving people front-end work to do is enough to build a business around! Some of them are free, and some of them are not.

HackerRank

Other businesses have centered themselves around this too. HackerRank is all about getting jobs and hiring, so they’ve got a very strong agenda, but part of the way they do that is putting you through these skill tests (solving challenges) which are meant to asses you, but you can certainly learn from them too.

Others like this: Codewars, ChallengeRocket, Codesignal, Topcoder (Jeepers, VCs must love this idea.)

Coderbyte

Coderbyte has paid plans too, and they’re designed to leveling up your job interviewing skills with challenges.

Classic situation: sometimes the site is the product and you’re the customer, and sometimes hiring companies are the customer and you’re the product.

Build Dribbble shots

Here’s the classic move: find something you like on Dribbble, rebuild it. The @keyframers often do it. Tim Evko’s Practice site used to pick a shot for you (along with random GitHub issues and random coding challenges), but the Dribbble part appears broken at the moment. The other stuff still works!

Matt Delac used to do a series along these lines. Indrek Lasn also does it in Medium posts.

Front-End Challenges Club

Andy Bell did a Front-End Challenges Club for a while, and while I think it’s on break, you can view the archives.

CodePen Challenges

CodePen Challenges run every week are are a prompt (along with ideas and resources) for building whatever you like. Low key.

100 Days of CSS Challenge

Matthias Martin created 100 days of CSS challenges. They are all there for you to see, including entries from other people — but the point is for you to give it a shot yourself, of course.

Daily UI

Daily UI challenges gives you a new challenge every day that starts when you sign up (and it’s free). Lots of people complete the challenge with code.

Frontloops

Frontloops charges $ 19 for 30 challenges, which includes information, advice, assets, and a solution.

CSSBattle

If your idea of a fun challenge is mimicking a design in as few bytes of code as possible, CSSBattle will appeal to you.

Writing things as tersely as possible is often called “Code Golf” and there is a challenge site for that too.

Ace Front End

Ace Front End has challenges that focus specifically on vanilla HTML, CSS, and JavaScript.

I just happened to notice that the first challenge is a drop down navigation menu, and it doesn’t handle things like aria-expanded. I’m not entirely sure how big of a problem that is and I don’t mean to pick on Ace Front End — it’s just a reminder that there could be problems with any of these challenges. But that doesn’t mean you can’t learn something from them.

Codier

Codier has public challenges that include solutions posted by other users.

rendezvous with cassidoo

Cassidy’s weekly newsletter includes a challenge in every issue.


Rina Diane Caballar quoting Tim Carry in Extending the Limits of CSS:

Carry’s advice is to start with a real-world object—the interface of a gaming console or a calculator, for example—and to try to recreate it using only CSS. “A great way to push the boundaries with a language is to make something that the language wasn’t meant to be doing in the first place,” he says.

The post Front-End Challenges appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

An Annotated Docker Config for Front-End Web Development

Andrew Welch sings the praises of using Docker containers for local dev environments:

Here are the advan­tages of Dock­er for me:

• Each appli­ca­tion has exact­ly the envi­ron­ment it needs to run, includ­ing spe­cif­ic ver­sions of any of the plumb­ing need­ed to get it to work (PHP, MySQL, Post­gres, whatever)
• Onboard­ing oth­ers becomes triv­ial, all they need to do is install Dock­er and type docker-compose up and away they go
• Your devel­op­ment envi­ron­ment is entire­ly dis­pos­able; if some­thing goes wrong, you just delete it and fire up a new one
• Your local com­put­er is sep­a­rate from your devel­op­ment envi­ron­ment, so switch­ing com­put­ers is triv­ial, and you won’t run into issues where you hose your com­put­er or are stuck with con­flict­ing ver­sions of DevOps services
• The cost of try­ing dif­fer­ent ver­sions of var­i­ous ser­vices is low; just change a num­ber in a .yaml file, docker-compose up, and away you go

Here’s an, uhm, very different perspective I’m anonymously posting that I snagged from a group Slack:

I have spent basically the whole day fucking around with Docker bullshit.

This has now cost the client literally thousands of dollars in me not getting any actual work done. The setup was created by the dev team, who are great, but the brittle, unstable nature of this is, well, bullshit.

I get the motivation but everyone knows that Docker is horribly slow on the Mac. It has for several years and yet it’s still in use. I just don’t get it.

Is there any way that developing with Docker on a Mac can not suck? Asking for a friend. Who is me.

Diff’rent Strokes.

Direct Link to ArticlePermalink

The post An Annotated Docker Config for Front-End Web Development appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Our Learning Partner: Frontend Masters

I’d like to think there is a lot to learn on CSS-Tricks. But we don’t really offer much by the way of courses. You’re probably reading this because you just generally read this site, and you land on CSS-Tricks otherwise mostly because you are looking for an answer to some front-end question.

Courses are a really great way to learn though. I’ve done many over my years as a developer, particularly when learning something fairly outside my bubble of things I already know. For example, I don’t reach for TypeScript yet because I don’t really know it and am definitely not comfortable with it. You better believe I’ll be taking a course on it when the time comes that I want to use it on a project.

Where will I find that course? Frontend masters, of course. They are clearly the most high-quality in-depth courses on all things front-end development. They’ve got a course on TypeScript, of course.

So I’m so so glad to announce that Frontend Masters is our official learning partner. I like having an official place to send people to when it’s clear their learning style is video courses, like so many people’s is.

One not-so-little aspect I love about Frontend Masters: the courses are taught in a live environment. So it’s not a head talking into a screen, the courses have the natural energy of a live teaching situation, because they are.

How you’ll see our course recommendations here on CSS-Tricks is through some contextual ads next to articles. Say you’re reading Geoff’s recent article about the dense keyword as part of CSS grid layout. Well, that article is about layout, and Frontend Masters has a comprehensive course on modern CSS layout from Jen Kramer. So as you scroll down that post, you’ll see our course recommendation there, as well as at the bottom of the article.

Try it free

Access to all of Frontend Masters is a paid membership. Access to literally everything they have is $ 39 a month or $ 390 a year, with special pricing for teams. But, they have some free stuff if you want to dip your toes and see for yourself if it’s any good.

On-the-go

I feel like this is worth mentioning too. Frontend Masters itself is a website you log into to watch the videos and that’s a great experience. But it’s not the only way. They also have great native mobile apps (iOS / Android), if you prefer that experience.

The post Our Learning Partner: Frontend Masters appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

A Recap of Frontend Development in 2019

I noted Trey Huffine’s 2018 version of this article in The Great Divide.

To put a point on this divide a bit more, consider this article by Trey Huffine, “A Recap of Frontend Development in 2018.” It’s very well done! It points to big moments this year, shows interesting data, and makes predictions about what we might see next year. But it’s entirely based around the JavaScript ecosystem.

My point was (and still is) that front-end development is more than the JavaScript ecosystem. However, I certainly admit the movings-and-shakings of the JavaScript world is a big deal and probably generally more interesting to watch for most devs.

What happened this year outside of JavaScript land? Well it’s weird. Things move slower, so it’s harder to pin things — even to years — quite as easily. For example, there was plenty of talk and usage of prefers-reduced-motion in CSS, but we kinda “got” that in 2017. Lots of people have gotten excited about variable fonts this year, but that’s also been years in the making. Subgrid recently dropped in Firefox, so I guess that’s a 2019 thing, but we’ll see slow adoption of it for years to come. For more of this exciting (but not necessarily brand new) stuff, check out Adam Argyle and Una Kravets Chrome Dev Summit 2019 presentation.

HTML is evolving at an even slower pace. Occasionally, something will feel new. I got excited about <dialog> this year, even though it first appeared in 2014, but the experts are saying we probably shouldn’t use it. Elements like <details> are getting more exciting as Edge-goes-Chromium because they’ll be getting more cross-browser support, but it’s no picnic. There’s just not much exciting to talk about in HTML, at least to me, aside from sort of philosophical approaches to it, like JAMstack.

The two most exciting HTML things to me: native lazy loading and no-jank fluid image loading.

But back to Trey’s post, the highlights are:

  • React is huge. jQuery isn’t falling.
  • Hooks was a huge release and change for React, and React is generally pushing fast on lots of big stuff.
  • TypeScript continues to grow.
  • Vue 3 is a long time coming and a bit controversial.
  • Svelte 3 is a small player but has lots of interest.
  • Angular 9 is almost here and has a strong base.
  • JavaScript itself continues to have yearly releases. ES2019 has nice stuff and ES2020 is even better.
  • Flutter is challenging React Native for cross-platform development, an impressive feat since there are so many more React devs than Dart devs.
  • JAMstack, PWAs, GraphQL, and CSS-in-JS are all growing in usage and developer sentiment.
  • VS Code is dominant.

Trey also picked out some really great blog posts and presentations from the year at the end, so don’t miss those!

If you dig predictions, then you might be interested in Sean Goresht’s big one for 2020.

Direct Link to ArticlePermalink

The post A Recap of Frontend Development in 2019 appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

A Recap of Frontend Development in 2019

I noted Trey Huffine’s 2018 version of this article in The Great Divide.

To put a point on this divide a bit more, consider this article by Trey Huffine, “A Recap of Frontend Development in 2018.” It’s very well done! It points to big moments this year, shows interesting data, and makes predictions about what we might see next year. But it’s entirely based around the JavaScript ecosystem.

My point was (and still is) that front-end development is more than the JavaScript ecosystem. However, I certainly admit the movings-and-shakings of the JavaScript world is a big deal and probably generally more interesting to watch for most devs.

What happened this year outside of JavaScript land? Well it’s weird. Things move slower, so it’s harder to pin things — even to years — quite as easily. For example, there was plenty of talk and usage of prefers-reduced-motion in CSS, but we kinda “got” that in 2017. Lots of people have gotten excited about variable fonts this year, but that’s also been years in the making. Subgrid recently dropped in Firefox, so I guess that’s a 2019 thing, but we’ll see slow adoption of it for years to come. For more of this exciting (but not necessarily brand new) stuff, check out Adam Argyle and Una Kravets Chrome Dev Summit 2019 presentation.

HTML is evolving at an even slower pace. Occasionally, something will feel new. I got excited about <dialog> this year, even though it first appeared in 2014, but the experts are saying we probably shouldn’t use it. Elements like <details> are getting more exciting as Edge-goes-Chromium because they’ll be getting more cross-browser support, but it’s no picnic. There’s just not much exciting to talk about in HTML, at least to me, aside from sort of philosophical approaches to it, like JAMstack.

The two most exciting HTML things to me: native lazy loading and no-jank fluid image loading.

But back to Trey’s post, the highlights are:

  • React is huge. jQuery isn’t falling.
  • Hooks was a huge release and change for React, and React is generally pushing fast on lots of big stuff.
  • TypeScript continues to grow.
  • Vue 3 is a long time coming and a bit controversial.
  • Svelte 3 is a small player but has lots of interest.
  • Angular 9 is almost here and has a strong base.
  • JavaScript itself continues to have yearly releases. ES2019 has nice stuff and ES2020 is even better.
  • Flutter is challenging React Native for cross-platform development, an impressive feat since there are so many more React devs than Dart devs.
  • JAMstack, PWAs, GraphQL, and CSS-in-JS are all growing in usage and developer sentiment.
  • VS Code is dominant.

Trey also picked out some really great blog posts and presentations from the year at the end, so don’t miss those!

If you dig predictions, then you might be interested in Sean Goresht’s big one for 2020.

Direct Link to ArticlePermalink

The post A Recap of Frontend Development in 2019 appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

What it means to be a front-end developer in 2020 (and beyond)

I wrote a piece for Layout, the blog of my hosting sponsor Flywheel.

Stick around in this field for a while, and you’ll see these libraries, languages, build processes, and heck, even entire philosophies on how best to build websites come and go like a slow tide.​​

You might witness some old-timer waving their fist from time to time, yelling that we should learn from the mistakes of the past. You could also witness some particularly boisterous youth waving their fists just as high, pronouncing the past an irrelevant context and no longer a useful talking point.

​​They’re both right, probably. As long as nobody is being nasty, it’s all part of the flow.

I’ve spent this whole year thinking about how I think the term front-end developer is still pretty meaningful, despite the divide in focus. The widening of the role just brings about more opportunity.

Direct Link to ArticlePermalink

The post What it means to be a front-end developer in 2020 (and beyond) appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]