gnalck

Those who have reservations about the terms of AGPLv3 - would any of you prefer if it was licensed under BUSL1.1 (i.e., source-available or eventually-open-source) instead? I'm curious to see the perspectives of businesses as to whether AGPLv3 or BUSL-1.1 is a "bigger risk" when compared to the previous Apache 2.0 license.

My gut feeling is that those passionate about open source on the whole will tend to prefer AGPLv3, while businesses or those making decisions on the behalf of a business, may prefer BUSL-1.1. I think there are trade offs with either approach.

Fedora "just works" and has the some of the more sane defaults. Only tweaks one typically needs to do is add the RPM Fusion repos and, at some point, disable/tune-down SELinux when it is a bit too paranoid.

This is pretty neat! I was just looking around for a "modern, smaller" JQuery equivalent and did not come across this. The older equivalents in this space I saw were Zepto and Cash.

Out of curiosity, what do you think of Alpine.js and Stimulus.js, which come to mind when I think of smaller utility libraries for adding "sprinkles" of JS?

Whether or not JS-SSR with hydration is performant is an interesting topic, but sort of misses the forest for the trees, no? The thread you link to is about a post which speaks about whether that extra level of complexity is even necessary for many use cases (it isn't).

HTML + JQuery, which the hydration approach is compared with, is not used for performance reasons per se. It's used because its easier to reason about and the incremental interactivity that something like JQuery brings to HTML is better than writing your entire frontend in React for something as simple as a blog, for example.

Hey Matt - thanks for creating and maintaining Caddy all these years! Like others have said in this thread, it is so easy to set up and maintain that it really does feel like "magic".

In terms of speeding up adoption of Caddy 2, it may be useful to have a list somewhere of the concrete improvements between the two (as I'm sure there are many). A (very) brief look and search around only yielded this article[1] which referenced another link of improvements that now 404s[2].

Cheers,

[1] https://caddyserver.com/v1/blog/caddy-2-ready-for-developers

[2] https://github.com/caddyserver/caddy/tree/v2#list-of-improve...

Is the technology behind "incremental builds" being upstreamed into the open source project?

Is there a plan for how backend jobs would work in this "Rails for the Javascript age"?

I find that JAMstack is great until the need for recurring or out-of-band processes comes up. In Rails of course there are jobs that can be backed by Sidekiq or what have you, and additionally on a VM one can always set up a cron job to invoke some Rails tasks.

For JAMstack there is no clear alternative, as far as I can see. Manually setting up a recurring lambda function (granted, I have not yet done it) seems to be annoying enough that I would rather just deal with a VM instead.

Hey all,

Like many of you, my brother and I have been repeatedly frustrated by the current state of hiring processes for software engineering jobs. Many people hate whiteboard algorithms, while others, like myself, think that spending hours on a unpaid take-home problem is unreasonable. We were frustrated that most literature we find on company career pages are usually focused on the 'disruptiveness' or 'cultural uniqueness' of a company, yet many use cargo-culted interview processes that betray those very values. We wanted to have a website where companies can showcase themselves starting from their hiring processes first and foremost. So we created it.

Right now, we only focus on interview processes, but we want to eventually complement those with other things we think fact-focused engineers would appreciate knowing or filtering on. Like technologies used, benefits available, or whether the company is non-profit or not, to name a couple.

All of the companies currently listed were added by ourselves, and it is currently free to add additional company pages (via emailing us). We hope to monetize by helping small to medium sized companies build up these profiles, and by allowing companies to pay for directly listing job postings on their company page.

We are eager to hear your feedback! Cheers