HN user

wa1987

94 karma
Posts0
Comments47
View on HN
No posts found.

Please stop spreading this misnomer.

That's a fairly… direct way of putting it :-)

Anyway:

1. What are the key differences in terms of usage and use cases?

2. Why isn't Deno a 'wholesale' replacement for Node?

3. In which respect are the vastly differently inner workings relevant in regards to usage of both products?

There’s no need to in my situation. 99% of the files are dependencies installed through Composer (PHP) while building the Dockerfile. The few directories I need to work on directly are bind mounts and don’t have much impact on overall runtime performance.

On a Mac, there is a major performance hit whenever you do disk IO in a bind mount (i.e. voluming a directory of the host system into the container). Working without bind mounts is extremely limiting. [..] If you’re using Docker on a Mac and you’ve never tried it on Linux, you owe it to yourself to try it on Linux.

Or use named volumes. I'm running a dockerized WordPress dev environment on my MacBook with average TTFB's of 40 ms.

Agreed. I find myself using a pretty small subset of the language which definitely doesn't include the class keyword. Doubt I'll ever find it useful.

Often times operations are order-independent. Specifying those as sequential `await`-s does not make a lot of sense in those situations. I guess less fine grained control is desirable under such circumstances :-)

There's also other useful utilities such as Promise.all(), Promise.any() and Promise.race().

If a static site generator put my images in the wrong place and required a gigantic JSON file to be loaded by the client for no reason I would not think twice to get rid of it.

Incorrect DOM-output is likely caused by common mistakes (e.g. conditional rendering based on `typeof window !== 'undefined'`) which screw up rehydration. Dealt with it in the past and seen a lot of developers struggle with it. This article describes it well:

https://joshwcomeau.com/react/the-perils-of-rehydration/

Gigantic page-data.json files are caused by querying more data than necessary to render a given template/component. Let's say you define a component named `EmployeeCard` that renders a name and photo given an `employeeId`. Now you need to query all employees and render the right one using `.find()`. All this data (including base64 thumbnails) ends up in page-data.json, even if you need to render a only single employee.

This is solved by querying only the relevant employee(s) in the template and provide the data (name + photo) directly to the `EmployeeCard` component as props.

I've developed quite a few websites using Gatsby (mostly backed by various GraphQL API's such as WPGraphQL and Strapi) and while there's lots to learn, it's been an enjoyable experience so far.

For sure! Whipped up a quick pen:

https://codepen.io/willem-aart/pen/oNxwRXY?editors=1100

This is impossible to achieve with CSS Grid.

One might alternatively approach this 'cluster layout' using inline-block elements. However, these elements would then be separated by space characters and the width of the space would be added to any applied margins. These issues could possibly be resolved by resorting to hacks such as setting font-size: 0 on the parent. Not pretty.

On the other hand, when using flexbox, space characters between flex childs are ignored which makes it a good fit for this kind of layout.

Agreed. I'd much prefer something along these lines as opposed to using an overly long name:

`

/* product of luminance and dot product of surface normal and light direction divided by scattering constant */

const prod = ...

`