It’s never too late. Pick you a tiny project, carve out small slice of time, work on it a bit, pause it, work again, and so on. You might slowly get back into the habit you enjoyed.

I was just using both as an example, I apologize for not being clear.

Yes a menu is just a list of links, but most people want drop-down or hamburger menu’s now, and that requires either some CSS or some JS. Again, go looking and all the examples will be in JS, unless you go searching specifically for CSS examples.

This is true of just about everything you want to do in HTML/Web land, the JS examples are super easy to find, the CSS equivalents are hard to find, and plain HTML examples are super hard to find.

Anyways, I basically agree webauthn isn’t really ready for production use, but again, both of these were examples, and webauthn just because it’s something I’m currently playing with. You can find lots of new web tech that is essentially JS only, despite it not needing to be, from a technical perspective. This is what I’m saying.

I haven’t written a technical book (yet), but I have read the books Matthew Butterick wrote using Pollen and they look nice enough that I would probably try to use Pollen before homebrewing something.

So, you want to load and view documents that are rendered from declarative source code rather than imperative source? I can get behind that!

JavaScript can even detect if you zoom on text or on a certain image and tell it to Google so that they can advertise better glasses or something

You’re worried that high resolution micro-interaction data (mouse hover, scroll linger, etc) may reveal that I need eyeglasses? :) It may reveal that, but I’m more concerned that it would reveal my favorite color, or favorite body type. This type of data collection is my pet peeve. It’s nobody’s business which images or text I linger over in my idle time!

In the distant past of the late nineties, I used to teach fellow travelers that .txt, .jpg, .gif, and .html files are safe and .exe, .com, and .bat files were unsafe. It was a bright line and it helped users be responsible for their own online safety. That browser vendors decided to allow executable scripts inside otherwise declarative documents obliterated that bright line.

I’m not sure what people are using in general, but the author is using Monodraw for some of his diagrams.

I refer to the work put in to make sure the vms didn’t optimize code away into constants or other such “cheating” optimizations. I suspect most real programs do stumble into readily optimized paths, then don’t change over there course of running.

Sounds like a very different project

sure, if you never touch a knife you won’t commit a knife crime, but encouraging everyone to stop using knifes isn’t a good idea. Implementing ads and trackers without javascript is trivial as well.

Either way, I agree with you on the point that you shouldn’t use JS when it’s just as easy and nicer for everyone involved when you can skip it. But some web sites really are ‘web apps’, they have interactivity that makes it very inconvenient to not use js.

Yep!

Last year, EFF began some experiments with a variant of OpenWRT that prioritizes good out-of-the-box open wireless support, in combination with simpler and more secure UI than the OpenWRT defaults. Initially we had hoped that that firmware project would […]

– https://www.eff.org/deeplinks/2015/04/toward-better-open-wireless-routers [2015]

You’re oversimplifying. There are many schizophrenic people in the U.S., and most of them are not racist. Compulsions, even schizophrenic ones, don’t come from the ether, and they’re not correlated with any particular mental illness. Also, terry’s compulsions went far beyond paranoia.

So, Bee2. I understand why you want a better docker compose, but why make your own rather than use or enhance vagrant?

I’m successfully using vagrant + make as a single-machine docker orchestrator. Because it’s all just ruby, it’s relatively easy to add in whatever I need into the vagrantfile.

I think people typically use LaTex for these sorts of diagrams. You can also use a tool like plantuml to generate a certain class of diagrams.

One of the biggest problems I had when writing technical books was how to include code into the manuscript.

We started by copying and pasting the code, but this is error-prone, untestable, and hard to update. I don’t love writing my books in executable “notebooks” because they tend to enforce a linear coupling of the text and code – but learning any non-trivial program is a graph traversal, not a top-down reading of the code.

So instead we used a pre-processor to import code by line numbers (e.g. import lines 5-10 from foo.js here). This helps a ton in that the code is on disk, we have no copy-and-paste errors, and we can test it. The problem, of course, is that if you refactor the code or add a line, all of your line numbers are off for the rest of the chapters.

So I took the path this author avoided and wrote a new tool: cq. The idea behind cq is that you use CSS-like selectors to semantically extract code blocks. How it works is that it parses the code into an AST and then you can extract the code blocks you need semantically rather than by line number. (It currently works w/ JavaScript, ES6, TypeScript, and Python.)

It’s been hugely helpful in our book writing process because we can update or reformat the code and the code blocks in the manuscript automatically stay in sync!

I have tons of examples in the README here.

(While I’m here, I’d like to mention that I’m looking for an author to collaborate on a book for Golang and another on Rust. If you’re interested, DM me or read more details here)

Yeah, I mean, this is a tradeoff, but you’re not going to run an airliner that long without maintenance, anyway. It’s still ugly, though.

Sad to hear it, he was one of a kind. Is there any effort to archive his work and preserve the site? His family might not want to keep paying the hosting bill forever.

“prone”?

Size is just one metric. Ads, trackers, and popups all generally require JavaScript, and if you restrain yourself from using it you will naturally also not be using these things. Not using JavaScript also makes you exercise restraint in your design, letting the browser do what it’s best at (rendering pages) without straining your end-user’s resources.

I definitely find there’s a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it’s easy to get distracted from solving the actual problem by trying to do it the most “proper” way possible. This is also how you end up with design astronautics in enterprise Java as well where people obsess over using every design pattern in the book instead of writing direct and concise code that’s going to be maintainable.

Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. That goes a long way in avoiding the analysis paralysis problem.

And don’t forget that HTTP/2 is basically a binary version of HTTP, so now you have to do two translation steps! Also, because DoH is basically just the original DNS encoding, it only adds complexity. For instance, the spec itself points out that you have two levels of error handling: One of HTTP errors (let’s say a 502 because the server is overloaded) and one of DNS errors.

It makes more sense to just encode DNS over TLS (without the unnecessary HTTP/2 stuff), or to completely ditch the regular DNS spec and use a different wire format based on JSON or XML over HTTP.

I pretty much agree except for one point.

But making the router ecosystem change is a lost battle.

This assumes that the only battle field available is the market.

Law can easily fix the technological problem here.
And it could also fix more severe vulnerabilities, actually. ;-)