Contents tagged “JavaScript”

There are 43 contents with this tag:

  1. screenshot of Why We're Breaking Up with CSS-in-JS

    Sam Magura

    Why We're Breaking Up with CSS-in-JS

    Thanks for reading this deep dive into runtime CSS-in-JS. Like any technology, it has its pros and cons. Ultimately, it's up to you as a developer to evaluate these pros and cons and then make an informed decision about whether the technology is right for your use case. For us at Spot, the runtime performance cost of Emotion far outweighed the DX benefits, especially when you consider that the alternative of Sass Modules + utility classes still has a good DX while providing vastly superior performance.

  2. screenshot of Speeding Up Async Snippets

    Harry Roberts

    Speeding Up Async Snippets

    For all the resulting script is asynchronous, the <script> block that creates it is fully synchronous, which means that the discovery of the script is governed by any and all synchronous work that happens before it, whether that’s other synchronous JS, HTML, or even CSS. Effectively, we’ve hidden the file from the browser until the very last moment, which means we’re completely failing to take advantage of one of the browser’s most elegant internals… the Preload Scanner.

  3. screenshot of Hydration is Pure Overhead

    Miško Hevery

    Hydration is Pure Overhead

    The re-execution of code on the client that the server already executed as part of SSR/SSG is what makes hydration pure overhead: that is, a duplication of work by the client that the server already did. The framework could have avoided the cost by transferring information from the server to the client, but instead, it threw the information away.

  4. With JavaScript, how would you compute all sorted permutations of 1 to n elements from a given array?

    For example, with this source [1, 2, 3] and n=2

    How would you get this?

    [[1], [2], [3], [1, 2], [1, 3], [2, 3]];

  5. screenshot of React Bias

    Jeremy Wagner

    React Bias

    The juxtaposition of The HTTP Archive’s analysis and The State of JS 2020 Survey results suggest that a disproportionately small—yet exceedingly vocal minority—of white male developers advocate strongly for React, and by extension, a development experience that favors thick client/thin server architectures which are given to poor performance in adverse conditions. Such conditions are less likely to be experienced by white male developers themselves, therefore reaffirming and reflecting their own biases in their work.

  6. screenshot of HTML and CSS techniques to reduce your JavaScript

    Anthony Ricaud

    HTML and CSS techniques to reduce your JavaScript

    relying on solutions provided natively by browsers enables you to benefit at low cost from the expertise of the community creating web standards. These solutions generally have the advantage of using less code, thus reducing maintenance efforts for a development team (for example, no need to update the libraries used).

  7. screenshot of The (extremely) loud minority

    Andy Bell

    The (extremely) loud minority

    Always remember that although a subset of the JavaScript community can be very loud, they represent a paltry portion of the web as a whole. This means that when they say something like “CSS sucks”—what they mean is “CSS sucks for a small subset of less than 1 percent of the web”

  8. screenshot of Second-guessing the modern web

    Tom MacWright

    Second-guessing the modern web

    […] there is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

  9. screenshot of Hydration

    Jeremy Keith

    Hydration

    The layered approach of progressive enhancement echoes the separation of concerns in the front-end stack: HTML, CSS, and JavaScript—each layer expressing more power. But while these concepts are related, they’re not interchangable. Separating out the layers of your tech stack isn’t necessarily progressive enhancement. If you have some HTML that relies on JavaScript to be useful, then there’s no benefit in separating that HTML into a separate payload. The HTML that you initially send down the wire needs to be functional (at least at a basic level) before the JavaScript arrives.

  10. screenshot of The importance of elegance

    Johan Halse

    The importance of elegance

    If code is explicit and testable but hard to read and follow, then we’ve lost our most important property along the way. Code is first and foremost designed to be read by humans, not computers. Turning source code into CPU instructions is the compiler’s job, not mine […]

  11. screenshot of Metrics from 1M Sites

    Steve Souders

    Metrics from 1M Sites

    What catches my eye are the gaps between TTFB and the paint metrics, and between the paint metrics and First CPU Idle. These gaps are caused by JavaScript dominating the browser main thread. This happens after TTFB when all the blocking scripts are executed – these have to finish before any rendering can happen.

  12. JavaScript universel et architecture isomorphe

    On parle depuis quelque temps de « JavaScript isomorphe » pour décrire des architectures Web dans lesquelles on abandonne les principes historiques des Single Page Applications composées de coquilles HTML vides et moult JavaScript pour les remplir. Le JavaScript isomorphe a plutôt comme principe de produire des pages HTML pleinement fonctionnelles dès la sortie du serveur, mais chargeant elles aussi moult JavaScript pour prendre le relai —si possible— afin d'améliorer l'expérience utilisateur. Je propose que l'on parle d'« architecture isomorphe », une implémentation possible étant en « JavaScript universel ».

See all tags.