n0w

I don't disagree with what you're saying, but it's interesting that some people might want to make Linux software distribution more like Windows or macOS because of unfamiliarity.

The way you've described Linux software distribution sounds an aweful lot like software distribution on mobile devices. I think it should be pretty familiar to everyone by now. If anything I think Windows and macOS want to move closer to being like Linux in this regard.

Maybe the experience of using cli tools like `apt` or `yum` has made people overlook the ease of installing software on Linux. Anyone that has used openSUSE or Ubuntu should know better.

Why would `Authentication` be any different to `Cookie` in this regard? They're both HTTP headers. They both require server side support/implementation. Neither explicitly requires JavaScript.

The only difference I can see is that the browser has a native control for one of them, though that control cannot be customised by the site.

For me, one of the largest benefits is the Web API compatibility.

As a frontend dev by day, trying to write services/scripts in Node is constantly frustrating. Simple things like base64 encoding or making http requests have me heading off to the documentation and trying to remember "the Node way".

The other large part for me is the lack of npm. The npm ecosystem is one of my largest sources of daily frustration. I look forward to ESM everywhere.

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.

This resonates with me. I think we do our best work when we have the autonomy to apply our expertise.

But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic.

The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought).

I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks.

How do we enable engineers to do their best work but also allow our teams to be successful?

I had the same thought.

A direct port of tsc to a "faster" language doesn't guarantee a faster type checker. Sure it might be a bit faster, but my guess is that the large performance wins come from a different design that takes performance into consideration from the start.

Maybe the thought process is that a 1:1 rewrite will handle compatibility and feature completeness? I suppose you could optimise from there?

Are you not able to use the Drag & Drop API?

https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_a...

The later should already be possible.

I believe you can specify a docker image to be used for running a job so you can bake things like node_modules into the image.

As someone that has used Hasura very heavily in the past, I can see the operational benefit of not needing to manage one more service.

The talk about memory constraints seems a bit odd though. The extension is still going to require memory and without profiling the alternatives it seems odd to say: "we won't use any more memory with an extension". Especially when you say "these established/stable alternatives fulfill all our feature requirements". In practice I always found Hasura to be reasonably lightweight (I can't speak for PostGraphile).

I think there's an advantage to running this API layer as an additional service in front of the DB though. Then it can act as an API gateway to more than just your database.

Also, the generation of a "Relay style" schema is off putting for me. I'm really not a fan of the style and was one of the biggest advantages for me in using Hasura.

When your service can no longer process requests as fast as they come in, you've hit a wall. Until then the simple solution is to allocate more resources to your service (i.e. scale vertically).

I think this is a great analogy.

Creating a game of telephone between the stakeholders and the people developing software is often going to impede communication.

The flip side of this is that a lot of technical people lack adequate soft skills to be able to do this requirements gathering well (probably the same can be said about a lot of doctors and what defines a "good" doctor).

Based on the news release from Apple it looks like developers still aren't allowed to link to this from inside the app. It only allows for out of app communications (like email)?

Personally, I don't think it has anything to do with being embarrassed about dense logic. I think it's about a love of abstractions.

Many developers get trapped trying to recognize patterns and come up with perfect mental models for whatever problem they're trying to solve when the straight forward dense function is probably the simpler and more maintainable solution. I often fall for this trap myself and am constantly trying to be wary of it.

I definitely find `box-sizing: border-box` fits my mental model much better.

I rarely find a need to think about `positioning` though and I think the article doesn't give enough credit for `display: flex` and `display: grid`. I tend to reach for `display: flex` as a default and find it much more intuitive. Whether it's easier for a beginner is a different question though.

This will change as OS's embrace the idea more. Apps won't need to package a runtime when it's provided by the OS.

My guess is that this comes down to browser support. A canvas based solution probably has pretty wide support today while these new CSS features will be subject to the long tail of browser versions.

I'm on the fence about this. From personal experience I'll nearly always opt-out just because I can. However I think this kind of user tracking is a better way to inform product decisions than user interviews.

Asking a user for their opinion about something doesn't generally provide as much valuable insight as monitoring their usage of a product.

Line heights are still a pain for consistent spacing in the browser. I'm really hoping for more progress on CSS Inline Layout Module Level 3 and the `leading-trim` property.

https://css-tricks.com/leading-trim-the-future-of-digital-ty...

The page has a different (lighter) text colour for dark mode but the background colour doesn't change on dark mode, making it nearly unreadable.

The Firefox tools tell me it has a contrast of 1.43

This is pretty cool.

One thing I noticed is that Cmd-Clicking a variable only shows where it was defined. I think it would be pretty useful if you could also see the places it was changed.

I really respect this ideal.

All too often I've found people dealing with external users become calloused. We forget that questions with obvious answers (to us) may not be obvious others and that this doesn't imply that others are stupid.

I feel that it's our responsibility to design things to be as obvious to as many people as possible. I also think a default attitude of respecting the users of our products can go a long way to making this happen.

The argument about tolerable complexity definitely resonated with me.

However, I think the author may have failed to consider that the people using Gatsby/Next/etc. for their personal blog aren't necessarily doing so because they believe it is the best tool for the job. It's might be a good excuse to explore some new technology. Other times it could be the tool someone is most familiar with.

As for the solution, I believe existing tools like make could have solved the "rework" problem.

For reloading, I'm not sure I understand the leap from "I need to inject some JavaScript" to "I need to be able to parse a HTML document". If you're already replacing placeholders in the template with your content, why not another with some JavaScript?

There's also an interesting trend happening with development tooling like Snowpack and Vite. Instead of recompiling your assets when things change, why not let the HTTP server compile them on the fly? You don't need to worry about dependency graphs because the browser will request the assets it needs. Your development server can send events when a requested asset is touched and some injected JavaScript can handle the reloading.

I'm in the process of transitioning our production Hasura deployment to use Keycloak. So far things are pretty straightforward.

I think in an ideal world you would do API changes to a live system in much the same way as you do with a live Database Schema: Carefully, and in a backward compatible manner.

Location: Melbourne, Australia

Remote: Yes

Willing to relocate: No

Technologies: JavaScript, TypeScript, Vue.js, Svelte, GraphQL, Hasura, Postgres, Go, Node, Docker, Kubernetes, GitLab CI, Linux

Résumé/CV: https://nowylie.com/nicholas_wylie_resume.pdf

Email: nick@nowylie.com

This is the thing I think most people miss when they complain about the complexity of Kubernetes. If you already know how to use standard sysadmin tools it looks like a lot of additional knowledge to achieve similar outcomes. These people seem to forget that there is a lot of complexity in their sysadmin tools too.

I've never felt like any of this was "added" complexity though, just different complexity. Managing a full operating system inside a virtual machine or packaging an application for installation with dpkg/rpm/etc is not any simpler, it's just the complexity we have suffered with to date so we are more familiar with it.

I don't want to come across as disagreeing with you, but can someone explain the complexity they see in docker/containerization?

It's always seemed to me as nothing more than a way to package a (mostly) preconfigured piece of software.

It would be nice to have a JavaScript API that allows you to create a client certificate locally, generate a CSR, and install the signed certificate for automatic use when connecting back to the associated host?

In a world where we are trying to codify more and more of the operational side of our applications, I personally look at operators as a better alternative to the configuration management systems we use to configure generic operating systems today.

We're moving away from an imperative configuration/operational model to a declarative one. While these operators target applicatings running in k8s I could imagine them being created to manage applications running elsewhere as well.

I might have misinterpreted the overview, but the key server/service that provides authentication for users sounded like a central point in the system.