Vox

Leitura de 16 min

Answering Front-End Interview Questions: Call vs. Apply and Integrating Multiple Stylesheets

Summary

In this episode of Developer Tea, host Jonathan Cottrell addresses two questions from the popular Front-end Developer Interview Questions repository on GitHub. He begins by explaining the technical difference between JavaScript’s call and apply methods, noting that both allow explicit control of the this context but differ in how they accept arguments: call takes arguments individually, while apply accepts them as an array.

Cottrell then tackles a more open-ended question about integrating five different stylesheets into a site. He emphasizes that the optimal approach depends on context, suggesting that merging sheets into one resource via build tools like Gulp or Grunt is often best for performance. However, if separation is justified—such as for admin vs. public pages—he recommends dynamically loading only the necessary CSS, using tools like Scoutfile to manage asynchronous loading and caching.

The discussion highlights the trade-offs involved, including Internet Explorer’s limit of 4,095 rules per stylesheet and the potential to remove unused CSS. Cottrell concludes by reflecting on the nature of technical interviews, stressing the importance of forming and defending informed opinions, a key skill for hireable web developers.

Recommendations

Tools

  • Gulp — Mentioned as a build tool that can be used to merge multiple CSS stylesheets into a single file for performance optimization.
  • Grunt — Referenced alongside Gulp as a build tool for merging stylesheets and optimizing front-end assets.
  • Scoutfile — A front-end tool discussed with Rebecca Murphy that asynchronously loads stylesheets and JavaScript files, allowing dynamic loading and long caching times.
  • Bless CSS — A tool with Gulp and Grunt modules that helps split CSS files to comply with Internet Explorer’s limit of 4,095 rules per stylesheet.

Websites

  • Front-end Developer Interview Questions (GitHub) — A GitHub repository under the H5BP organization containing a well-curated set of questions for front-end developer interviews, with contributions from 135 people.
  • OneMonth.com — An online learning platform offering courses in tech skills like Ruby on Rails, Python, and content marketing, with a discount mentioned for Developer Tea listeners.

Topic Timeline

  • 00:00:00 — Introduction to Front-End Developer Interview Questions — Jonathan Cottrell introduces the episode, focusing on answering questions from the Front-end Developer Interview Questions GitHub repository. He notes the repository’s popularity, with 135 contributors, and explains that questions often have multiple valid answers aimed at understanding a candidate’s thinking process rather than quizzing specific knowledge.
  • 00:02:01 — JavaScript: Difference Between Call and Apply — Cottrell addresses the first question: what is the difference between call and apply in JavaScript? He explains that both methods allow control over the this context when executing a function. The key difference is that call accepts arguments as a regular list, while apply accepts them as an array. A mnemonic is provided: apply starts with ‘a’ and takes an array.
  • 00:05:52 — Sponsor Break: OneMonth.com — A sponsor message for OneMonth.com, an online learning platform offering courses in coding and tech skills like Ruby on Rails and Python. The ad highlights a 25% discount for Developer Tea listeners using a specific URL.
  • 00:07:08 — Strategies for Integrating Multiple Stylesheets — Cottrell discusses the second question: how to best integrate five different stylesheets into a site. He suggests first clarifying the purpose of each sheet. If no good reason exists for separation, merging them into one file via build tools (e.g., Gulp, Grunt) is recommended for faster loading. If separation is justified, dynamic loading of only necessary sheets—using tools like Scoutfile—can optimize performance.
  • 00:10:04 — Caveats and Optimization Considerations — Cottrell covers caveats, such as Internet Explorer’s limit of 4,095 rules per stylesheet, which can be addressed with tools like Bless CSS. He also suggests auditing CSS to remove unused rules, speeding up load times and simplifying future development. The segment underscores the importance of making informed trade-offs based on project needs.
  • 00:11:38 — Conclusion on Forming Opinions in Interviews — Cottrell concludes by reflecting on the subjective and objective nature of interview questions. He stresses that being able to form, defend, and act on informed opinions is a crucial skill for web developers, making candidates more hireable. He encourages listeners to leave reviews and engage via Twitter or email.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-06-12T07:30:00Z
  • Duration: 00:13:15

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Team. My name is Jonathan Cottrell.

[00:00:03] Today I’m going to be answering a few front-end developer interview questions.

[00:00:10] If you’re not familiar with the front-end developer interview questions

[00:00:14] repository on GitHub, I would recommend that you take a look at it especially if you are

[00:00:19] either hiring or looking for a job as a front-end developer. It is a very well put together set of

[00:00:27] questions that a ton of people have contributed to. In fact there’s 135 contributors. I’ve talked

[00:00:33] about it on the show before. It is under the HTML5 boilerplate user on GitHub or the organization

[00:00:40] rather on GitHub. So it’s at github.com front slash h5bp. You’ll find it there. It has a ton of

[00:00:47] stars. It is quite popular and there’s a ton of really good questions on here including general

[00:00:54] questions as well as pretty specific questions and today we’re actually going to cover one

[00:00:59] general question and one specific question. I want to start by saying that most of these questions

[00:01:06] have multiple answers. There’s no one right answer and that’s also even more true because

[00:01:11] what may be right today may not be right next year or even as soon as tomorrow. So the questions on

[00:01:18] this repository are more to get an understanding of how you think rather than to quiz you or to

[00:01:24] get you to answer really specific information. Of course there are specific questions like I said

[00:01:29] previously that test your knowledge about a given subject but again those questions quite often have

[00:01:36] more than one simple answer. There are some questions that have essential content responses

[00:01:42] that you should know if you are looking for a job in this field but most of these have quite a few

[00:01:50] different answers. So this is mostly an opinion is what I’m saying. What I’m going to tell you is

[00:01:55] mostly an opinion. However this first question does have a pretty specific answer so you can

[00:02:01] walk away with some actionable knowledge from today’s episode of Developer T. If you didn’t

[00:02:06] already know the answer to this question. The question is a JavaScript related question and

[00:02:11] it’s very simply what is the difference between call and apply and specifically on the repository

[00:02:19] it’s the dot call and dot apply and that kind of gives you a little bit of an idea of what these

[00:02:25] are. These are actually methods that you can run on a function object. So you could say set a

[00:02:32] variable foo equal to a function and then run foo dot apply or foo dot call. Now why would you want

[00:02:40] to do this? Why would why would you want to call a a function this way rather than actually just

[00:02:45] calling the function like you normally would by saying foo with parentheses? Well it turns out

[00:02:51] that JavaScript has a very strange way of dealing with a keyword called this. The keyword this in

[00:02:57] JavaScript refers to the owning object. It may be similar to in other languages the keyword self.

[00:03:05] However if there’s not a particular function that owns the object that you’ve created

[00:03:10] then this refers to the global context or the parent context and it gets a little bit

[00:03:16] confusing if you aren’t controlling this more explicitly and that’s exactly what the dot call

[00:03:22] and dot apply methods allow you to do to pass in the first argument to both of those which is the

[00:03:28] context on which to execute that function. So if you had var foo equals function and then you do

[00:03:36] something inside of there with the keyword this you can control what that particular keyword

[00:03:42] refers to by using dot call. So foo dot call and the first function parameter would be the object

[00:03:51] that this refers to. So getting to the question at hand what is the difference between dot call

[00:03:57] and dot apply? Let’s imagine that your function takes two or three arguments. If you wanted to

[00:04:03] pass in arguments when you are using the dot call function you would pass them in as you normally

[00:04:09] would. So for example let’s say var foo equals function and there’s maybe argument one and

[00:04:15] argument two. Well then when you do foo dot call you would say foo dot call and then you pass in

[00:04:21] whatever the object that you want this to refer to is and then you would pass in argument one,

[00:04:27] argument two. Dot apply works very similarly except instead of passing in your arguments as

[00:04:33] regular arguments you pass them in as an array of values. You pass them in as an array which is a

[00:04:40] single argument technically speaking. So syntactically you would simply wrap those arguments in

[00:04:48] square brackets. Now when would you might use these differently? It totally depends on your

[00:04:53] context and there’s no specific right or wrong way to handle these things but if you are building

[00:04:59] up a dynamic set of arguments you would probably want to use dot apply. If you are using a set

[00:05:07] number of arguments you would probably want to use dot call. A simple mnemonic device to remember

[00:05:13] which one is which. Just remember that dot apply starts with an a and that’s the one that you pass

[00:05:19] in an array. So dot apply and in fact array ends with a y and so does apply. So the one that begins

[00:05:26] with an a and ends with a y is the one that you pass an array into. Dot apply takes an array and

[00:05:33] then dot call takes a arguments list, a regular arguments list like you would pass into a regular

[00:05:39] function call. And that’s it. That’s the simple difference between dot call and dot apply in

[00:05:46] JavaScript. So we’ll move on to the second question right after a very quick sponsor break.

[00:05:52] What if you could learn to build anything in one month? Well with onemonth.com you can. Just ask

[00:05:58] any one of the 20,000 students who have learned to code on onemonth.com by building real websites

[00:06:03] and applications complete with payment systems, security solutions, and full stack deployment.

[00:06:08] You can start without any prior experience in just 15 minutes a day for 30 days all online.

[00:06:14] That’s because onemonth hyper focuses on applied techniques that you use immediately in the apps

[00:06:19] you are building as part of the courses. Onemonth’s courses are the easiest way to learn new tech

[00:06:24] skills including Ruby on Rails, Python, content marketing, growth hacking, and more. And the

[00:06:29] best part is if you get stuck there’s always someone there to help you out while you learn.

[00:06:34] Yes that’s a real person not an automated computer. So enroll now at onemonth.com

[00:06:39] front slash developer T and get 25% off your first month. Now normally access to all courses

[00:06:45] cost 49. But with the special URL you get full access

[00:06:52] for just 37. That’s less than $3 a day or if you do a single course it’s

[00:06:59] just over $1 a day. Enroll now for 25% off your first month at onemonth.com front slash developer T.

[00:07:08] So the second question that I want to cover today is a little bit more ambiguous. It has multiple

[00:07:13] answers and that’s why I think it’s interesting. I think it’s a good question to ask a potential

[00:07:18] hiring candidate and I’m going to approach it the way that I would answer the question.

[00:07:23] So the question is this, if you have five different style sheets how would you best integrate them

[00:07:28] into a site? So the question is referring to having five separate style sheets that you

[00:07:35] have to integrate into a single site. Now I would start by asking a few questions in order to

[00:07:41] clarify the intentions of that particular style sheet or those particular style sheets. For example

[00:07:48] do all five style sheets apply to the entire site or is there a style sheet for the home page and

[00:07:56] maybe a secondary style sheet for the admin pages and another style sheet that applies to

[00:08:03] you know the the secondary pages that are public facing? What are the reasons for having those

[00:08:10] separate? If there aren’t any good reasons to keep those separate then I would most likely

[00:08:16] approach this problem by finding a way to merge all of those style sheets into a single style

[00:08:22] sheet using something like gulp or grunt or even a front end tool like code kit and the reason I

[00:08:29] would choose to do that is because it’s much faster to load a single resource than to load

[00:08:35] five separate resources on a given page. Now if there is a good reason to keep them separate

[00:08:41] then the real question is is there a way to dynamically load the ones that we need to load

[00:08:47] when we need to load them? For example very few people are going to see the admin interface so

[00:08:53] there’s not a good reason for me as a public facing user that will never see the admin interface to

[00:08:59] actually load that style sheet. It’s just extra weight that I don’t need to see. Some frameworks

[00:09:05] already have this built in. Of course you could solve this using a front end tool like the one

[00:09:11] that Rebecca Murphy and I discussed called scout file and what scout file does is it actually pulls

[00:09:17] in style sheets and other javascript files using javascript and it loads them in asynchronously

[00:09:25] from your website loading so it does it really fast and it allows you to set really long caching

[00:09:31] times on these front end files. If you had this kind of tool you can use javascript to determine

[00:09:37] which ones need to be loaded for a given page so for example you could have a scout file for

[00:09:43] only your admin pages that loads in your admin css and keep that in the header of your of your

[00:09:50] site or however you want to handle that but find a way of loading in these things dynamically of

[00:09:56] loading in only the things that you need to load in. Now there are a few caveats to this approach

[00:10:04] first of all if you are merging five style sheets it’s possible that that would end up in a very

[00:10:10] large css file and unfortunately there is a limit to the number of selectors or rules rather that

[00:10:19] internet explorer will load and that’s internet explorer version six all the way up through nine

[00:10:26] in fact it has a hard limit at 4095 rules per sheet now you can solve this simply by

[00:10:34] separating your sheets into two sheets and there are tools to do this specifically there’s one

[00:10:40] called bless css and that one has a gulp and a grunt module that you can use to automatically

[00:10:47] make sure that your css follow these follows these rules and loads properly in internet explorer.

[00:10:53] Now another question that I might ask is if all of that css was still necessary is it possible

[00:11:00] that some of that css is left over from a previous design or perhaps it was brought in as part of a

[00:11:07] framework or a plugin and it could be stripped out is very possible that some of the css is no

[00:11:14] longer being used and therefore can be removed entirely which would speed up the load time of

[00:11:20] those css files and perhaps more importantly would make development in the future much easier

[00:11:26] to accomplish because it becomes much easier to reason about the code when there is less code to

[00:11:32] reason about. I hope this has been a helpful exploration of these two questions and I hope

[00:11:38] that you can see the subjective nature of some questions when you sit down for an interview and

[00:11:45] the objective nature of other questions. Ultimately if you are being interviewed it’s important that

[00:11:51] you can form an opinion and be able to back up your reasoning for that opinion. There’s no shortage

[00:11:58] of opinions in web development and it is a skill to be able to form an informed opinion about a

[00:12:05] given subject. In the css loading example you have to take into account all different kinds of trade

[00:12:11] offs and move forward. It’s important to be able to make a decision based on your formed opinion

[00:12:17] and explain why your opinion is what it is to be able to back up whatever you choose to do

[00:12:24] given a set of circumstances. If you are able to form an opinion and act on that opinion

[00:12:30] that is a skill that makes you hireable as a web developer. I hope you’ve enjoyed this episode of

[00:12:36] Developer Tea. I hope it has provided some value to you. If it has please consider giving us a

[00:12:43] review in iTunes. This is the best way to help Developer Tea out. Of course I appreciate every

[00:12:50] moment that you listen to this show. This show is here for you and I am so happy that I have so many

[00:12:56] awesome people listening. You can always reach out to me on Twitter at at Developer Tea or email me

[00:13:02] at developertea at gmail.com and until next time enjoy your tea.

Visão de gráfico