[xrd]

They had me at the combination of the words "scriptable" and "DNS." My monkey brain is susceptible to that clever trick.

I'm struggling to see what this could be used for, but the comments here help.

In summary:

  - an alternative to anycast.
  - an alternative to routing inside your app (your app could detect the IP, and have different behavior based on rules internally). This means you are always going to the same origin, which scriptable DNS would prevent, you could put things at the edge and reduce hops.

Why else would you use this?

[ehayes]

Years ago I did school IT, during the time when all websites moved to SSL-only. We used to filter websites easily with Squid and something called Dan's Guardian. When Google switched to SSL-only we had to change. We could have required everyone to install certificates, but instead we used PowerDNS with Lua to force all Google search related queries to answer with a Google-provided CNAME.

https://gist.github.com/hayesr/55b55d167f67f57fe5e56ec3ab1f8...

[ranger_danger]

>They had me at the combination of the words "scriptable" and "DNS."

Same, but then they lost me at Javascript.

[Zash]

May I interest you in some Lua instead? https://doc.powerdns.com/authoritative/lua-records/index.htm...

I run PowerDNS but haven't found a reason to play with this yet.

[jeroenhd]

Woah, I've been running PowerDNS for a while but never knew this existed. I can't think of a use for this just yet, but I love it!

[nerdponx]

I know that we all have our preferences of langauges, but is Javascript in 2022 actually any worse than anything else as a scripting language? What would you prefer instead?

[dzikimarian]

That's of course purely anecdotal, but recently I explored static site generators.

One of these was Hugo(written in go, which is pretty young ecosystem, I'm not very familiar with). Everything was pretty straight forward.

Other one was Gatsby v4 (seems like pretty mature JS project). Oh boy.

Docs suggest multiple ways to initialize new project, depending which page you open and without clear explanation of the difference. NPM will download ungodly amount of dependencies and then inform you happily, that you have 16 critical vulnerabilities. Plugins tend to create dependency hell.

In general each time I try to do something with JS I end up debugging issues that require some arcane knowledge, filtering outdated docs and dealing with general flakiness of everything.

While I get, that on frontend it might be hard to avoid, I don't get why someone does it to themselves, when having other options (purely subjective opinion - I spend most time on backend, so I'm probably biased).

[nerdponx]

Fair enough. I do agree that JS-based libraries, frameworks, and tools tend to have bad docs and questionable API designs, compared to equivalents that I've used in other languages. There is some cultural issue there that I don't understand.

But... this is an embedded scripting environment! You aren't using any of that stuff.

[dzikimarian]

Yes and no. You're definitely less exposed to JS ecosystem, but it's often the same issue with available examples, code snippets, docs.

I've similarly bad experience with for eg. plugins for VS Code. I wanted to add more supported syntax to org-mode plug in, at which point I found that their test suite is messed up.

Of course none of this is inherently fault of JS as a language, but current development culture around it promotes use of lots of silver tape, which makes me nervous, when I have to use anything JS-based.

[minitech]

This is more Gatsby’s design decisions (which I agree are terrible) than a JavaScript thing.

[mhink]

It comes down to a combination of factors, but the long and short of things when it comes to content-focused sites specifically is that companies want all of:

- A modern user experience with rich content - Authoring tools which are easy for non-technical users to understand - Fast content delivery times - Low operational costs

The problem is that getting all of them at once requires a bunch of fiddly integration problems. These problems are compounded if you throw e-commerce into the mix as well, in which case your marketing department is gonna want all kinds of analytics to try and suss out what users are doing, when, and why.

So, a lot of the weirdness and complexity has to do with making projects adaptable enough to handle a variety of different use cases while still offering at least a little bit of lift (vs. rolling the entire thing oneself).