Tag: Frontend

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

, ,

“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]

How We Perform Frontend Testing on StackPath’s Customer Portal

Nice post from Thomas Ladd about how their front-end team does testing. The list feels like a nice place to be:

  1. TypeScript – A language, but you’re essentially getting various testing for free (passing the right arguments and types of variables)
  2. Jest – Unit tests. JavaScript functions are doing the right stuff. Works with React.
  3. Cypress – Integration tests. Page loads, do stuff with page, expected things happen in DOM. Thomas says their end-to-end tests (e.g. hitting services) are also done in Cypress with zero mocking of data.

I would think this is reflective of a modern setup making its way across lots of front-end teams. If there is anything to add to it, I’d think visual regression testing (e.g. with a tool like Percy) would be the thing to add.

As an alternative to Cypress, jest-puppeteer is also worth mentioning because (1) Jest is already in use here and (2) Puppeteer is perhaps a more direct way of controlling the browser — no middleman language or Electron or anything.

Thomas even writes that there’s a downside here: too-many-tools:

Not only do we have to know how to write tests in these different tools; we also have to make decisions all the time about which tool to use. Should I write an E2E test covering this functionality or is just writing an integration test fine? Do I need unit tests covering some of these finer-grain details as well?

There is undoubtedly a mental load here that isn’t present if you only have one choice. In general, we start with integration tests as the default and then add on an E2E test if we feel the functionality is particularly critical and backend-dependent.

I’m not sure we’ll ever get to a point where we only have to write one kind of test, but having unit and integration tests share some common language is nice. I’m also theoretically opposite in my conclusion: integration/E2E tests are a better default, since they are closer to reality and prove that a ton is going right in just testing one thing. They should be the default. However, they are also slower and flakier, so sad trombone.

Direct Link to ArticlePermalink

The post How We Perform Frontend Testing on StackPath’s Customer Portal appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

Become a Front-End Master in 2020 With These 10 Project Ideas

This is a little updated cross-post from a quickie article I wrote on DEV. I’m publishing here ‘cuz I’m all IndieWeb like that.

I love this post by Simon Holdorf. He’s got some ideas for how to level up your skills as a front-end developer next year. Here they are:

  • Build a movie search app using React
  • Build a chat app with Vue
  • Build a weather app with Angular
  • Build a to-do app with Svelte

… and 5 more like that.

All good ideas. All extremely focused on JavaScript frameworks.
I like thinking of being a front-end developer as being someone who is a browser person. You deal with people who use some kind of client to use the web on some kind of device. That’s the job.

I love JavaScript frameworks, but knowing them isn’t what makes you a good front-end developer. Being performance-focused and accessibility-focused, and thus user-focused is what makes you a front-end master, beyond executing the skills required to get the website built.

In that vein, here’s some more ideas.

  • Go find a Dribbble shot that appeals to you. Re-build it in HTML and CSS in the cleanest and most accessible way you can.
  • Find a component you can abstract in your codebase, and abstract it so you can re-use it efficiently. Consider accessibility as you do it. Could you make it more accessible in a way that benefits the entire site? How about your SVG icon component — how’s that looking these days?
  • Try out a static site generator (perhaps one that isn’t particularly JavaScript focused, just to experience it). What could the data source be? What could you make if you ran the build process on a timed schedule?
  • Install the Axe accessibility plugin for DevTools and run it on an important site you control. Make changes to improve the accessibility as it suggests.
  • Spin up a copy of Fractal. Check out how it can help you think about building front-ends as components, even at the HTML and CSS level.
  • Build a beautiful form in HTML/CSS that does something useful for you, like receive leads for freelance work. Learn all about form validation and see how much you can do in just HTML, then HTML plus some CSS, then with some vanilla JavaScript. Make the form work by using a small dedicated service.
  • Read a bit about Serverless and how it can extend your front-end developer skillset.
  • Figure out how to implement an SVG icon system. So many sites these days need an icon set. Inlining SVG is a great simple solution, but how you can abstract that to easily implement it with your workflow? How can it work with the framework you use?
  • Try to implement a service worker. Read a book about them. Do something very small. Check out a framework centered around them.
  • Let’s say you needed to put up a website where the entire thing was the name and address of the company, and a list of hours it is open. What’s the absolute minimum amount of work and technical debt you could incur to do it?

The post Become a Front-End Master in 2020 With These 10 Project Ideas appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]