Better grammar (#68)
This commit is contained in:
Yangshun Tay
GitHub
parent
892ef52b13
commit
5d924bd61b
|
|
@ -14,7 +14,7 @@ As much as possible, try to follow the existing format of markdown and code. Any
|
|||
|
||||
### Translations
|
||||
|
||||
Feel free to add translations for the questions and answers only. You might want to retrieve a translated copy of the questions from [the original repository] and start from there. Simply create an issue expressing interest in being a translator and you will be added to the repository. Translators have the responsibility of keeping the translated content up to date with the master copy. However, the `master` branch is protected from direct writes and translated work have to be go through the Pull Request and review process before it can be merged into the repository. This is more for organizational purposes as different translators tend to have individual collaboration approach (some prefer merging, some prefer rebasing). Going through a Pull Request process will make the commit history more organized and clean.
|
||||
Feel free to add translations for the questions and answers only. You might want to retrieve a translated copy of the questions from [the original repository] and start from there. Simply create an issue expressing interest in being a translator and you will be added to the repository. Translators have the responsibility of keeping the translated content up to date with the master copy. However, the `master` branch is protected from direct writes and translated work have to go through the Pull Request and review process before it can be merged into the repository. This is more for organizational purposes as different translators tend to have individual collaboration approach (some prefer merging, some prefer rebasing). Going through a Pull Request process will make the commit history more organized and clean.
|
||||
|
||||
### Code of Conduct
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
Unlike typical software engineer job interviews, front-end job interviews have less emphasis on algorithms and have more questions on intricate knowledge and expertise about the domain — HTML, CSS, JavaScript, just to name a few areas.
|
||||
|
||||
While there are some existing resources to help front end developers in preparing for interviews, they aren't as abundant as materials for a software engineer interview. Among the existing resources, probably the most helpful question bank would be [Front-end Developer Interview Questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions). Unfortunately, I couldn't find many complete and satisfactory answers for these questions online, hence here is my attempt at answering them. Being an open source repository, the project can live on with the support of the community as the state of web evolves.
|
||||
While there are some existing resources to help front end developers in preparing for interviews, they aren't as abundant as materials for a software engineer interview. Among the existing resources, probably the most helpful question bank would be [Front-end Developer Interview Questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions). Unfortunately, I couldn't find many complete and satisfactory answers to these questions online, hence here is my attempt at answering them. Being an open source repository, the project can live on with the support of the community as the state of web evolves.
|
||||
|
||||
## Looking for Generic Interview Preparation?
|
||||
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ In large projects, I would write a utility `.clearfix` class and use them in pla
|
|||
|
||||
### Explain CSS sprites, and how you would implement them on a page or site.
|
||||
|
||||
CSS sprites combine multiple images into one single larger image. It is commonly used technique for icons (Gmail uses it). How to implement it:
|
||||
CSS sprites combine multiple images into one single larger image. It is a commonly-used technique for icons (Gmail uses it). How to implement it:
|
||||
|
||||
1. Use a sprite generator that packs multiple images into one and generate the appropriate CSS for it.
|
||||
1. Each image would have a corresponding CSS class with `background-image`, `background-position` and `background-size` properties defined.
|
||||
|
|
@ -189,11 +189,11 @@ CSS sprites combine multiple images into one single larger image. It is commonly
|
|||
|
||||
These techniques are related to accessibility (a11y).
|
||||
|
||||
* `visibility: hidden`. However the element is still in the flow of the page, and still takes up space.
|
||||
* `visibility: hidden`. However, the element is still in the flow of the page, and still takes up space.
|
||||
* `width: 0; height: 0`. Make the element not take up any space on the screen at all, resulting in not showing it.
|
||||
* `position: absolute; left: -99999px`. Position it outside of the screen.
|
||||
* `text-indent: -9999px`. This only works on text within the `block` elements.
|
||||
* Metadata. For example by using Schema.org, RDF and JSON-LD.
|
||||
* Metadata. For example by using Schema.org, RDF, and JSON-LD.
|
||||
* WAI-ARIA. A W3C technical specification that specifies how to increase the accessibility of web pages.
|
||||
|
||||
Even if WAI-ARIA is the ideal solution, I would go with the `absolute` positioning approach, as it has the least caveats, works for most elements and it's an easy technique.
|
||||
|
|
@ -227,12 +227,14 @@ No... Sadly.
|
|||
### Can you give an example of an @media property other than screen?
|
||||
|
||||
Yes, there are four types of @media properties (including _screen_):
|
||||
|
||||
* `all` - for all media type devices
|
||||
* `print` - for printers
|
||||
* `speech` - for screenreaders that "reads" the page out loud
|
||||
* `screen` - for computer screens, tablets, smart-phones etc.
|
||||
|
||||
Here is an example of `print` media type's usage:
|
||||
|
||||
```css
|
||||
@media print {
|
||||
body {
|
||||
|
|
@ -249,11 +251,11 @@ Here is an example of `print` media type's usage:
|
|||
|
||||
### What are some of the "gotchas" for writing efficient CSS?
|
||||
|
||||
Firstly, understand that browsers match selectors from rightmost (key selector) to left. Browsers filter out elements in the DOM according to the key selector, and traverse up its parent elements to determine matches. The shorter the length of the selector chain, the faster the browser can determine if that element matches the selector. Hence avoid key selectors that are tag and universal selectors. They match a large numbers of elements and browsers will have to do more work in determining if the parents do match.
|
||||
Firstly, understand that browsers match selectors from rightmost (key selector) to left. Browsers filter out elements in the DOM according to the key selector and traverse up its parent elements to determine matches. The shorter the length of the selector chain, the faster the browser can determine if that element matches the selector. Hence avoid key selectors that are tag and universal selectors. They match a large number of elements and browsers will have to do more work in determining if the parents do match.
|
||||
|
||||
[BEM (Block Element Modifier)](https://bem.info/) methodology recommends that everything has a single class, and, where you need hierarchy, that gets baked into the name of the class as well, this naturally makes the selector efficient and easy to override.
|
||||
|
||||
Be aware of which CSS properties trigger reflow, repaint and compositing. Avoid writing styles that change the layout (trigger reflow) where possible.
|
||||
Be aware of which CSS properties trigger reflow, repaint, and compositing. Avoid writing styles that change the layout (trigger reflow) where possible.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -270,7 +272,7 @@ Be aware of which CSS properties trigger reflow, repaint and compositing. Avoid
|
|||
* Easy to write nested selectors.
|
||||
* Variables for consistent theming. Can share theme files across different projects.
|
||||
* Mixins to generate repeated CSS.
|
||||
* Splitting your code into multiple files. CSS files can be split up too but doing so will require a HTTP request to download each CSS file.
|
||||
* Splitting your code into multiple files. CSS files can be split up too but doing so will require an HTTP request to download each CSS file.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
|
|
@ -300,9 +302,9 @@ Use `@font-face` and define `font-family` for different `font-weight`s.
|
|||
|
||||
### Explain how a browser determines what elements match a CSS selector.
|
||||
|
||||
This part is related to the above about writing efficient CSS. Browsers match selectors from rightmost (key selector) to left. Browsers filter out elements in the DOM according to the key selector, and traverse up its parent elements to determine matches. The shorter the length of the selector chain, the faster the browser can determine if that element matches the selector.
|
||||
This part is related to the above about writing efficient CSS. Browsers match selectors from rightmost (key selector) to left. Browsers filter out elements in the DOM according to the key selector and traverse up its parent elements to determine matches. The shorter the length of the selector chain, the faster the browser can determine if that element matches the selector.
|
||||
|
||||
For example with this selector `p span`, browsers firstly find all the `<span>` elements, and traverse up its parent all the way up to the root to find the `<p>` element. For a particular `<span>`, as soon as it finds a `<p>`, it knows that the `<span>` matches and can stop its matching.
|
||||
For example with this selector `p span`, browsers firstly find all the `<span>` elements and traverse up its parent all the way up to the root to find the `<p>` element. For a particular `<span>`, as soon as it finds a `<p>`, it knows that the `<span>` matches and can stop its matching.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -371,9 +373,9 @@ TODO
|
|||
I shall throw in a comparison with `block` for good measure.
|
||||
|
||||
| | `block` | `inline-block` | `inline` |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Size | Fills up the width of its parent container. | Depends on content. | Depends on content. |
|
||||
| Positioning | Start on a new line and tolerates no HTML elements next to it (except when you add `float`) | Flows along with other content and allows other elements beside. | Flows along with other content and allows other elements beside. |
|
||||
| Positioning | Start on a new line and tolerates no HTML elements next to it (except when you add `float`) | Flows along with other content and allows other elements beside it. | Flows along with other content and allows other elements beside it. |
|
||||
| Can specify `width` and `height` | Yes | Yes | No. Will ignore if being set. |
|
||||
| Can be aligned with `vertical-align` | No | Yes | Yes |
|
||||
| Margins and paddings | All sides respected. | All sides respected. | Only horizontal sides respected. Vertical sides, if specified, do not affect layout. Vertical space it takes up depends on `line-height`, even though the `border` and `padding` appear visually around the content. |
|
||||
|
|
@ -399,8 +401,8 @@ A positioned element is an element whose computed `position` property is either
|
|||
|
||||
### What existing CSS frameworks have you used locally, or in production? How would you change/improve them?
|
||||
|
||||
* **Bootstrap** - Slow release cycle. Bootstrap 4 has been in alpha for almost 2 years. Add a spinner button component, as it is widely-used.
|
||||
* **Semantic UI** - Source code structure makes theme customization extremely hard to understand. Painful to customize with unconventional theming system. Hardcoded config path within the vendor library. Not well-designed for overriding variables unlike in Bootstrap.
|
||||
* **Bootstrap** - Slow release cycle. Bootstrap 4 has been in alpha for almost 2 years. Add a spinner button component, as it is widely used.
|
||||
* **Semantic UI** - Source code structure makes theme customization extremely hard to understand. Its unconventional theming system is a pain to customize. Hardcoded config path within the vendor library. Not well-designed for overriding variables unlike in Bootstrap.
|
||||
* **Bulma** - A lot of non-semantic and superfluous classes and markup required. Not backward compatible. Upgrading versions breaks the app in subtle manners.
|
||||
|
||||
[[↑] Back to top](#css-questions)
|
||||
|
|
@ -431,7 +433,7 @@ Both responsive and adaptive design attempt to optimize the user experience acro
|
|||
|
||||
Responsive design works on the principle of flexibility - a single fluid website that can look good on any device. Responsive websites use media queries, flexible grids, and responsive images to create a user experience that flexes and changes based on a multitude of factors. Like a single ball growing or shrinking to fit through several different hoops.
|
||||
|
||||
Adaptive design is more like the modern definition of progressive enhancement. Instead of one flexible design, adaptive design detects the device and other features, and then provides the appropriate feature and layout based on a predefined set of viewport sizes and other characteristics. The site detects the type of device used, and delivers the pre-set layout for that device. Instead of a single ball going through several different-sized hoops, you'd have several different balls to use depending on the hoop size.
|
||||
Adaptive design is more like the modern definition of progressive enhancement. Instead of one flexible design, adaptive design detects the device and other features and then provides the appropriate feature and layout based on a predefined set of viewport sizes and other characteristics. The site detects the type of device used and delivers the pre-set layout for that device. Instead of a single ball going through several different-sized hoops, you'd have several different balls to use depending on the hoop size.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -445,7 +447,7 @@ Adaptive design is more like the modern definition of progressive enhancement. I
|
|||
|
||||
I tend to use higher resolution graphics (twice the display size) to handle retina display. The better way would be to use a media query like `@media only screen and (min-device-pixel-ratio: 2) { ... }` and change the `background-image`.
|
||||
|
||||
For icons, I would also opt to use svgs and icon fonts where possible, as they render very crisply regardless of resolution.
|
||||
For icons, I would also opt to use SVGs and icon fonts where possible, as they render very crisply regardless of resolution.
|
||||
|
||||
Another method would be to use JavaScript to replace the `<img>` `src` attribute with higher resolution versions after checking the `window.devicePixelRatio` value.
|
||||
|
||||
|
|
|
|||
|
|
@ -46,8 +46,8 @@ In the back end, the HTML markup will contain `i18n` placeholders and content fo
|
|||
|
||||
* Use `lang` attribute in your HTML.
|
||||
* Directing users to their native language - Allow a user to change his country/language easily without hassle.
|
||||
* Text in images is not a scalable approach - Placing text in an image is still a popular way to get good-looking, non-system fonts to display on any computer. However to translate image text, each string of text will need to have it's a separate image created for each language. Anything more than a handful of replacements like this can quickly get out of control.
|
||||
* Restrictive words / sentence length - Some content can be longer when written in another language. Be wary of layout or overflow issues in the design. It's best to avoid designing where the amount of text would make or break a design. Character counts come into play with things like headlines, labels, and buttons. They are less of an issue with free flowing text such as body text or comments.
|
||||
* Text in images is not a scalable approach - Placing text in an image is still a popular way to get good-looking, non-system fonts to display on any computer. However, to translate image text, each string of text will need to have it's a separate image created for each language. Anything more than a handful of replacements like this can quickly get out of control.
|
||||
* Restrictive words/sentence length - Some content can be longer when written in another language. Be wary of layout or overflow issues in the design. It's best to avoid designing where the amount of text would make or break a design. Character counts come into play with things like headlines, labels, and buttons. They are less of an issue with free-flowing text such as body text or comments.
|
||||
* Be mindful of how colors are perceived - Colors are perceived differently across languages and cultures. The design should use color appropriately.
|
||||
* Formatting dates and currencies - Calendar dates are sometimes presented in different ways. Eg. "May 31, 2012" in the U.S. vs. "31 May 2012" in parts of Europe.
|
||||
* Do not concatenate translated strings - Do not do anything like `"The date today is " + date`. It will break in languages with different word order. Use a template string with parameters substitution for each language instead. For example, look at the following two sentences in English and Chinese respectively: `I will travel on {% date %}` and `{% date %} 我会出发`. Note that the position of the variable is different due to grammar rules of the language.
|
||||
|
|
@ -91,7 +91,7 @@ These days, using `data-` attributes is not encouraged. One reason is that users
|
|||
|
||||
### Describe the difference between a `cookie`, `sessionStorage` and `localStorage`.
|
||||
|
||||
All the above mentioned technologies are key-value storage mechanisms on the client side. They are only able to store values as strings.
|
||||
All the above-mentioned technologies are key-value storage mechanisms on the client side. They are only able to store values as strings.
|
||||
|
||||
| | `cookie` | `localStorage` | `sessionStorage` |
|
||||
| -------------------------------------- | -------------------------------------------------------- | -------------- | ---------------- |
|
||||
|
|
@ -113,8 +113,8 @@ All the above mentioned technologies are key-value storage mechanisms on the cli
|
|||
### Describe the difference between `<script>`, `<script async>` and `<script defer>`.
|
||||
|
||||
* `<script>` - HTML parsing is blocked, the script is fetched and executed immediately, HTML parsing resumes after the script is executed.
|
||||
* `<script async>` - The script will be fetched in parallel to HTML parsing and executed as soon as it is available (potentially before HTML parsing completes). Use `async` when the script is independent of any other scripts on the page, for example analytics.
|
||||
* `<script defer>` - The script will be fetched in parallel to HTML parsing and executed when the page has finished parsing. If there are multiple of them, each deferred script is executed in the order they were encountered in the document. If a script relies on a fully-parsed DOM, the `defer` attribute will be useful in ensuring that the HTML is fully parsed before executing. There's not much difference from putting a normal `<script>` at the end of `<body>`. A deferred script must not contain `document.write`.
|
||||
* `<script async>` - The script will be fetched in parallel to HTML parsing and executed as soon as it is available (potentially before HTML parsing completes). Use `async` when the script is independent of any other scripts on the page, for example, analytics.
|
||||
* `<script defer>` - The script will be fetched in parallel to HTML parsing and executed when the page has finished parsing. If there are multiple of them, each deferred script is executed in the order they were encountered in the document. If a script relies on a fully-parsed DOM, the `defer` attribute will be useful in ensuring that the HTML is fully parsed before executing. There's not much difference in putting a normal `<script>` at the end of `<body>`. A deferred script must not contain `document.write`.
|
||||
|
||||
Note: The `async` and `defer` attributes are ignored for scripts that have no `src` attribute.
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ Note: The `async` and `defer` attributes are ignored for scripts that have no
|
|||
|
||||
**Placing `<link>`s in the `<head>`**
|
||||
|
||||
Putting `<link>`s in the head is part of the specification. Besides that, placing at the top allows the page to render progressively which improves user experience. The problem with putting stylesheets near the bottom of the document is that it prohibits progressive rendering in many browsers, including Internet Explorer. Some browsers block rendering to avoid having to repaint elements of the page if their styles change. The user is stuck viewing a blank white page. It prevents the flash of unstyled contents.
|
||||
Putting `<link>`s in the head is part of the specification. Besides that, placing at the top allows the page to render progressively which improves the user experience. The problem with putting stylesheets near the bottom of the document is that it prohibits progressive rendering in many browsers, including Internet Explorer. Some browsers block rendering to avoid having to repaint elements of the page if their styles change. The user is stuck viewing a blank white page. It prevents the flash of unstyled contents.
|
||||
|
||||
**Placing `<script>`s just before `</body>`**
|
||||
|
||||
|
|
@ -146,9 +146,9 @@ An exception for positioning of `<script>`s at the bottom is when your script co
|
|||
|
||||
### What is progressive rendering?
|
||||
|
||||
Progressive rendering is the name given to techniques used to improve performance of a webpage (in particular, improve perceived load time) to render content for display as quickly as possible.
|
||||
Progressive rendering is the name given to techniques used to improve the performance of a webpage (in particular, improve perceived load time) to render content for display as quickly as possible.
|
||||
|
||||
It used to be much more prevalent in the days before broadband internet but it is still useful in modern development as mobile data connections are becoming increasingly popular (and unreliable)!
|
||||
It used to be much more prevalent in the days before broadband internet but it is still used in modern development as mobile data connections are becoming increasingly popular (and unreliable)!
|
||||
|
||||
Examples of such techniques:
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ If the client's resolution is 1x, 1.5625 is the closest, and `500w` correspondin
|
|||
|
||||
If the resolution is retina (2x), the browser will use the closest resolution above the minimum. Meaning it will not choose the 500w (1.5625) because it is greater than 1 and the image might look bad. The browser would then choose the image with a resulting ratio closer to 2 which is 1000w (3.125).
|
||||
|
||||
`srcset`s solve the problem whereby you want to serve smaller image files to narrow screen devices, as they don't need huge images like desktop displays do — and also optionally that you want to serve different resolution images to high density/low density screens.
|
||||
`srcset`s solve the problem whereby you want to serve smaller image files to narrow screen devices, as they don't need huge images like desktop displays do — and also optionally that you want to serve different resolution images to high density/low-density screens.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ For an in-depth explanation, do check out his [article on Medium](https://codebu
|
|||
|
||||
### Explain how prototypal inheritance works
|
||||
|
||||
This is an extremely common JavaScript interview question. All JavaScript objects have a `prototype` property, that is a reference to another object. When a property is accessed on an object and if the property is not found on that object, the JavaScript engine looks at the object's `prototype`, and the `prototype`'s `prototype` and so on, until it finds the property defined on one of the `prototype`s or until it reaches the end of the prototype chain. This behaviour simulates classical inheritance, but it is really more of [delegation than inheritance](https://davidwalsh.name/javascript-objects).
|
||||
This is an extremely common JavaScript interview question. All JavaScript objects have a `prototype` property, that is a reference to another object. When a property is accessed on an object and if the property is not found on that object, the JavaScript engine looks at the object's `prototype`, and the `prototype`'s `prototype` and so on, until it finds the property defined on one of the `prototype`s or until it reaches the end of the prototype chain. This behavior simulates classical inheritance, but it is really more of [delegation than inheritance](https://davidwalsh.name/javascript-objects).
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ console.log(foo === null); // true
|
|||
console.log(foo == undefined); // true. Wrong, don't use this to check!
|
||||
```
|
||||
|
||||
As a personal habit, I never leave my variables undeclared or unassigned. I will explicitly assign `null` to them after declaring, if I don't intend to use it yet.
|
||||
As a personal habit, I never leave my variables undeclared or unassigned. I will explicitly assign `null` to them after declaring if I don't intend to use it yet.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ Host objects are provided by the runtime environment (browser or Node), such as
|
|||
|
||||
### Difference between: `function Person(){}`, `var person = Person()`, and `var person = new Person()`?
|
||||
|
||||
This question is pretty vague. My best guess at its intention is that it is asking about constructors in JavaScript. Technically speaking, `function Person(){}` is just a normal function declaration. The convention is use PascalCase for functions that are intended to be used as constructors.
|
||||
This question is pretty vague. My best guess at its intention is that it is asking about constructors in JavaScript. Technically speaking, `function Person(){}` is just a normal function declaration. The convention is to use PascalCase for functions that are intended to be used as constructors.
|
||||
|
||||
`var person = Person()` invokes the `Person` as a function, and not as a constructor. Invoking as such is a common mistake if it the function is intended to be used as a constructor. Typically, the constructor does not return anything, hence invoking the constructor like a normal function will return `undefined` and that gets assigned to the variable intended as the instance.
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ console.log(person.name); // "john"
|
|||
|
||||
### What's the difference between `.call` and `.apply`?
|
||||
|
||||
Both `.call` and `.apply` are used to invoke functions and the first parameter will be used as the value of `this` within the function. However, `.call` takes in a comma-separated arguments as the next arguments while `.apply` takes in an array of arguments as the next argument. An easy way to remember this is C for `call` and comma-separated and A for `apply` and array of arguments.
|
||||
Both `.call` and `.apply` are used to invoke functions and the first parameter will be used as the value of `this` within the function. However, `.call` takes in comma-separated arguments as the next arguments while `.apply` takes in an array of arguments as the next argument. An easy way to remember this is C for `call` and comma-separated and A for `apply` and an array of arguments.
|
||||
|
||||
```js
|
||||
function add(a, b) {
|
||||
|
|
@ -348,7 +348,7 @@ In my experience, it is most useful for binding the value of `this` in methods o
|
|||
|
||||
### When would you use `document.write()`?
|
||||
|
||||
`document.write()` writes a string of text to a document stream opened by `document.open()`. When `document.write()` is executed after the page has loaded, it will call `document.open` which clears the whole document (`<head>` and `<body>` removed!) and replaces the contents with the given parameter value in string. Hence it is usually considered dangerous and prone to misuse.
|
||||
`document.write()` writes a string of text to a document stream opened by `document.open()`. When `document.write()` is executed after the page has loaded, it will call `document.open` which clears the whole document (`<head>` and `<body>` removed!) and replaces the contents with the given parameter value. Hence it is usually considered dangerous and prone to misuse.
|
||||
|
||||
There are some answers online that explain `document.write()` is being used in analytics code or [when you want to include styles that should only work if JavaScript is enabled](https://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html). It is even being used in HTML5 boilerplate to [load scripts in parallel and preserve execution order](https://github.com/paulirish/html5-boilerplate/wiki/Script-Loading-Techniques#documentwrite-script-tag)! However, I suspect those reasons might be outdated and in the modern day, they can be achieved without using `document.write()`. Please do correct me if I'm wrong about this.
|
||||
|
||||
|
|
@ -363,7 +363,7 @@ There are some answers online that explain `document.write()` is being used in a
|
|||
|
||||
**Feature Detection**
|
||||
|
||||
Feature detection involves working out whether a browser supports a certain block of code, and running different code dependent on whether it does (or doesn't), so that the browser can always provide a working experience rather crashing/erroring in some browsers. For example:
|
||||
Feature detection involves working out whether a browser supports a certain block of code, and running different code depending on whether it does (or doesn't), so that the browser can always provide a working experience rather crashing/erroring in some browsers. For example:
|
||||
|
||||
```js
|
||||
if ('geolocation' in navigator) {
|
||||
|
|
@ -466,7 +466,7 @@ These days, [CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) i
|
|||
|
||||
### Have you ever used JavaScript templating? If so, what libraries have you used?
|
||||
|
||||
Yes. Handlebars, Underscore, Lodash, AngularJS and JSX. I disliked templating in AngularJS because it made heavy use of strings in the directives and typos would go uncaught. JSX is my new favourite as it is closer to JavaScript and there is barely any syntax to learn. Nowadays, you can even use ES2015 template string literals as a quick way for creating templates without relying on third-party code.
|
||||
Yes. Handlebars, Underscore, Lodash, AngularJS, and JSX. I disliked templating in AngularJS because it made heavy use of strings in the directives and typos would go uncaught. JSX is my new favorite as it is closer to JavaScript and there is barely any syntax to learn. Nowadays, you can even use ES2015 template string literals as a quick way for creating templates without relying on third-party code.
|
||||
|
||||
```js
|
||||
const template = `<div>My name is: ${name}</div>`;
|
||||
|
|
@ -545,7 +545,7 @@ console.log(input.value); // Hello World!
|
|||
|
||||
### Why is extending built-in JavaScript objects not a good idea?
|
||||
|
||||
Extending a built-in/native JavaScript object means adding properties/functions to its `prototype`. While this may seem like a good idea at first, it is dangerous in practice. Imagine your code uses a few libraries that both extend the `Array.prototype` by adding the same `contains` method, the implementations will overwrite each other and your code will break if the behavior of these two methods are not the same.
|
||||
Extending a built-in/native JavaScript object means adding properties/functions to its `prototype`. While this may seem like a good idea at first, it is dangerous in practice. Imagine your code uses a few libraries that both extend the `Array.prototype` by adding the same `contains` method, the implementations will overwrite each other and your code will break if the behavior of these two methods is not the same.
|
||||
|
||||
The only time you may want to extend a native object is when you want to create a polyfill, essentially providing your own implementation for a method that is part of the JavaScript specification but might not exist in the user's browser due to it being an older browser.
|
||||
|
||||
|
|
@ -640,7 +640,7 @@ Advantages:
|
|||
* Makes it impossible to accidentally create global variables.
|
||||
* Makes assignments which would otherwise silently fail to throw an exception.
|
||||
* Makes attempts to delete undeletable properties throw (where before the attempt would simply have no effect).
|
||||
* Requires that function parameter names be unique.
|
||||
* Requires that function parameter names be unique.a
|
||||
* `this` is undefined in the global context.
|
||||
* It catches some common coding bloopers, throwing exceptions.
|
||||
* It disables features that are confusing or poorly thought out.
|
||||
|
|
@ -704,9 +704,9 @@ TODO.
|
|||
|
||||
The below is taken from the awesome [Grab Front End Guide](https://github.com/grab/front-end-guide), which coincidentally, is written by me!
|
||||
|
||||
Web developers these days refer to the products they build as web apps, rather than websites. While there is no strict difference between the two terms, web apps tend to be highly interactive and dynamic, allowing the user to perform actions and receive a response for their action. Traditionally, the browser receives HTML from the server and renders it. When the user navigates to another URL, a full-page refresh is required and the server sends fresh new HTML for the new page. This is called server-side rendering.
|
||||
Web developers these days refer to the products they build as web apps, rather than websites. While there is no strict difference between the two terms, web apps tend to be highly interactive and dynamic, allowing the user to perform actions and receive a response to their action. Traditionally, the browser receives HTML from the server and renders it. When the user navigates to another URL, a full-page refresh is required and the server sends fresh new HTML to the new page. This is called server-side rendering.
|
||||
|
||||
However in modern SPAs, client-side rendering is used instead. The browser loads the initial page from the server, along with the scripts (frameworks, libraries, app code) and stylesheets required for the whole app. When the user navigates to other pages, a page refresh is not triggered. The URL of the page is updated via the [HTML5 History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API). New data required for the new page, usually in JSON format, is retrieved by the browser via [AJAX](https://developer.mozilla.org/en-US/docs/AJAX/Getting_Started) requests to the server. The SPA then dynamically updates the page with the data via JavaScript, which it has already downloaded in the initial page load. This model is similar to how native mobile apps work.
|
||||
However, in modern SPAs, client-side rendering is used instead. The browser loads the initial page from the server, along with the scripts (frameworks, libraries, app code) and stylesheets required for the whole app. When the user navigates to other pages, a page refresh is not triggered. The URL of the page is updated via the [HTML5 History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API). New data required for the new page, usually in JSON format, is retrieved by the browser via [AJAX](https://developer.mozilla.org/en-US/docs/AJAX/Getting_Started) requests to the server. The SPA then dynamically updates the page with the data via JavaScript, which it has already downloaded in the initial page load. This model is similar to how native mobile apps work.
|
||||
|
||||
The benefits:
|
||||
|
||||
|
|
@ -716,7 +716,7 @@ The benefits:
|
|||
|
||||
The downsides:
|
||||
|
||||
* Heavier initial page load due to loading of framework, app code, and assets required for multiple pages.
|
||||
* Heavier initial page load due to the loading of framework, app code, and assets required for multiple pages.
|
||||
* There's an additional step to be done on your server which is to configure it to route all requests to a single entry point and allow client-side routing to take over from there.
|
||||
* SPAs are reliant on JavaScript to render content, but not all search engines execute JavaScript during crawling, and they may see empty content on your page. This inadvertently hurts the Search Engine Optimization (SEO) of your app. However, most of the time, when you are building apps, SEO is not the most important factor, as not all the content needs to be indexable by search engines. To overcome this, you can either server-side render your app or use services such as [Prerender](https://prerender.io/) to "render your javascript in a browser, save the static HTML, and return that to the crawlers".
|
||||
|
||||
|
|
@ -731,9 +731,9 @@ The downsides:
|
|||
|
||||
### What is the extent of your experience with Promises and/or their polyfills?
|
||||
|
||||
Possess working knowledge of it. A promise is an object that may produce a single value some time in the future: either a resolved value, or a reason that it's not resolved (e.g., a network error occurred). A promise may be in one of 3 possible states: fulfilled, rejected, or pending. Promise users can attach callbacks to handle the fulfilled value or the reason for rejection.
|
||||
Possess working knowledge of it. A promise is an object that may produce a single value sometime in the future: either a resolved value or a reason that it's not resolved (e.g., a network error occurred). A promise may be in one of 3 possible states: fulfilled, rejected, or pending. Promise users can attach callbacks to handle the fulfilled value or the reason for rejection.
|
||||
|
||||
Some common polyfills are `$.deferred`, Q and Bluebird but not all of them comply to the specification. ES2015 supports Promises out of the box and polyfills are typically not needed these days.
|
||||
Some common polyfills are `$.deferred`, Q and Bluebird but not all of them comply with the specification. ES2015 supports Promises out of the box and polyfills are typically not needed these days.
|
||||
|
||||
###### References
|
||||
|
||||
|
|
@ -758,7 +758,7 @@ Some common polyfills are `$.deferred`, Q and Bluebird but not all of them compl
|
|||
|
||||
### What are some of the advantages/disadvantages of writing JavaScript code in a language that compiles to JavaScript?
|
||||
|
||||
Some examples of languages that compile to JavaScript include CoffeeScript, Elm, ClojureScript, PureScript and TypeScript.
|
||||
Some examples of languages that compile to JavaScript include CoffeeScript, Elm, ClojureScript, PureScript, and TypeScript.
|
||||
|
||||
Advantages:
|
||||
|
||||
|
|
@ -771,7 +771,7 @@ Disadvantages:
|
|||
* Require a build/compile process as browsers only run JavaScript and your code will need to be compiled into JavaScript before being served to browsers.
|
||||
* Debugging can be a pain if your source maps do not map nicely to your pre-compiled source.
|
||||
* Most developers are not familiar with these languages and will need to learn it. There's a ramp up cost involved for your team if you use it for your projects.
|
||||
* Smaller community (depends on the language), which means resources, tutorials, libraries and tooling would be harder to find.
|
||||
* Smaller community (depends on the language), which means resources, tutorials, libraries, and tooling would be harder to find.
|
||||
* IDE/editor support might be lacking.
|
||||
* These languages will always be behind the latest JavaScript standard.
|
||||
* Developers should be cognizant of what their code is being compiled to — because that is what would actually be running, and that is what matters in the end.
|
||||
|
|
@ -832,9 +832,9 @@ TODO
|
|||
|
||||
### Explain the difference between synchronous and asynchronous functions.
|
||||
|
||||
Synchronous functions are blocking while asynchronous functions are not. In synchronous functions, statements complete before the next statement is run. In this case the program is evaluated exactly in order of the statements and execution of the program is paused if one of the statements take a very long time.
|
||||
Synchronous functions are blocking while asynchronous functions are not. In synchronous functions, statements complete before the next statement is run. In this case, the program is evaluated exactly in order of the statements and execution of the program is paused if one of the statements take a very long time.
|
||||
|
||||
Asynchronous functions usually accept a callback as a parameter and execution continues on the next line immediately after the asynchronous function is invoked. The callback is only invoked when the asynchronous operation is complete and the call stack is empty. Heavy duty operations such as loading data from a web server or querying a database should be done asynchronously so that the main thread can continue executing other operations instead of blocking until that long operation to complete (in the case of browsers, the UI will freeze).
|
||||
Asynchronous functions usually accept a callback as a parameter and execution continue on the next line immediately after the asynchronous function is invoked. The callback is only invoked when the asynchronous operation is complete and the call stack is empty. Heavy duty operations such as loading data from a web server or querying a database should be done asynchronously so that the main thread can continue executing other operations instead of blocking until that long operation to complete (in the case of browsers, the UI will freeze).
|
||||
|
||||
[[↑] Back to top](#js-questions)
|
||||
|
||||
|
|
@ -853,7 +853,7 @@ If you haven't already checked out Philip Robert's [talk on the Event Loop](http
|
|||
|
||||
### Explain the differences on the usage of `foo` between `function foo() {}` and `var foo = function() {}`
|
||||
|
||||
The former is a function declaration while the latter is a function expression. The key difference is that function declarations have its body hoisted but the bodies of function expressions are not (they have the same hoisting behaviour as variables). For more explanation on hoisting, refer to the question above on hoisting. If you try to invoke a function expression before it is defined, you will get an `Uncaught TypeError: XXX is not a function` error.
|
||||
The former is a function declaration while the latter is a function expression. The key difference is that function declarations have its body hoisted but the bodies of function expressions are not (they have the same hoisting behavior as variables). For more explanation on hoisting, refer to the question above on hoisting. If you try to invoke a function expression before it is defined, you will get an `Uncaught TypeError: XXX is not a function` error.
|
||||
|
||||
**Function Declaration**
|
||||
|
||||
|
|
@ -1020,7 +1020,7 @@ transformNamesToUppercase(names); // ['IRISH', 'DAISY', 'ANNA']
|
|||
|
||||
### Can you give an example for destructuring an object or an array?
|
||||
|
||||
Destructuring is an expression available in ES6 which enables a succinct and convenient way to extract values of Objects or Arrays, and place them into distinct variables.
|
||||
Destructuring is an expression available in ES6 which enables a succinct and convenient way to extract values of Objects or Arrays and place them into distinct variables.
|
||||
|
||||
**Array destructuring**
|
||||
|
||||
|
|
@ -1070,7 +1070,7 @@ TODO
|
|||
|
||||
### Can you give an example of a curry function and why this syntax offers an advantage?
|
||||
|
||||
Currying is a pattern where a function with more than one parameter is broken into multiple functions that, when called in series, will accumulate all of the required parameters one at a time. This technique can be useful for making code written in a functional style easier to read and compose. It's important to note that for a function to be curried, it needs to start out as one function, then broken out into a sequence of functions that each take one parameter.
|
||||
Currying is a pattern where a function with more than one parameter is broken into multiple functions that, when called in series, will accumulate all of the required parameters one at a time. This technique can be useful for making code written in a functional style easier to read and compose. It's important to note that for a function to be curried, it needs to start out as one function, then broken out into a sequence of functions that each accepts one parameter.
|
||||
|
||||
```js
|
||||
function curry(fn) {
|
||||
|
|
|
|||
Loading…
Reference in New Issue