mg

Beautiful.

Single file, 187 lines of JavaScript, no dependencies, does one thing and does it well.

I wish there was a way to search for libraries like this one. Almost every time I look for some piece of open source software, I end up writing it myself because all the solutions I find are overcomplicated and try to do too many things.

The brain uses 20% of the human body's energy.

As machines become intelligent, maybe AI will account for 20% of global energy consumption?

How long is a while and what is it, that most people do all day?

A quick Google search for "most common job" came back with

    Cashier

    A cashier works in a retail environment and
    processes transactions for a customer's purchase.

I wouldn't be surprised if robots can do that on their own in 10 years.

    I guess the "deep transformation of how we work"
    part is what I don't really understand.

At the moment, it looks like we'll either become completely obsolete in the context of work, or we'll morph into cyborgs with vastly greater knowledge and processing capabilities than we have today.

I'm not advocating, just trying to look into the future.

Superhuman AI seems to be a building block of it. And deep transformation of how we work will come with it.

So I raised the question of the timeline.

That's all.

The question is how fast.

I remember in the late 90s, me and some friends discovered the internet and went "Woah! Letters, books, shops, work, study, gaming ... pretty much everything will take place in this virtual realm soon!".

We were right. Except for the "soon".

When the first internet café opened, we started spending a lot of our time there, meeting lots of interesting people. Everything outside the internet already seemed anachronistic to us.

What I didn't expect back then was that even replacing letters with email (which already worked!) would take another painstaking ... 20 years!

Today, my work is already massively transformed via neural networks. Pretty much everything I do starts with an interaction with a neural network. Usually a question to an LLM. And then LLMs or other networks are involved all the way up to finishing the task. Thinking about how I worked before these large neural networks came up makes me shiver. How cumbersome. How anachronistic.

But when I talk to people outside the tech sphere, most are not using LLMs or other neural networks at all.

Everything humans do will be deeply transformed. Even more so than via the internet. Will it take 20 years again? Or is technological progress accelerating and this time it will take only 10 years? So far, my feeling is that it will be a bit faster, but not twice as fast.

But maybe it will be even more surprising. One future I can imagine is that people don't even need to adapt. Maybe we will see software simply do all aspects of a job. One can already imagine it for driving cars or making movies. It is harder to imagine it for managing a company, for example. But who knows. LLMs are already surprisingly good at creating chains of thoughts. Maybe we'll find ourselves in an unexpected future in a few years already, where human involvement in anything is just a burden to the process.

In my experience:

PHP is always blazing fast, with no additional setup to make "Reload page, see results" work.

Python needs additional setup. Either by monitoring the filesystem and pessimistically recompiling the application every time a file changes. Causing resource consumption every time you hit save in your editor. Or by having the web workers that serve the requests die after 1s of inactivity or so. Which makes the next pageview slow again, even if no code changed.

I think PHP's advantage is because of 3 things:

1: Recompiling changed files is built in.

2: With PHP you can set your project up in a way that only the code necessary to answer a single request is updated. With Python and Django, all the code for all requests is updated and even code paths that are actually never used.

3: PHP keeps each file compiled to bytecode in memory and only recompiles files that have been changed. Although you might accomplish something similar in Python if you let it pollute your filesystem with cached bytecode files.

There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete.

But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.

To get to know Laravel, I forced myself to build a project with it for a few weeks and I did not like it.

I found myself getting sucked in into a complex project structure and dealing with all kinds of strangeness like "artisan commands", "the autoload cache" etc.

With Django, I can build a web application in a single file that has "import django" on top and take it from there:

https://news.ycombinator.com/item?id=40788329

These days, I am super torn about what language to use for new web projects.

PHP:

    - Easy to deploy: Upload files, done.
    - Easy to develop: Reload page, see changes.
    - Lots of HTTP tooling built in.
    - Fast.

Python:

    - Great language.
    - Great code reuse system: Modules.
    - Nice framework: Django.
    - Less breaking changes in recent years.

Hetzner seems unaffected?

    ping hel1-speed.hetzner.com

Gives me 52ms from Germany which should be about normal?

Is there a metric which lets us track how far/close we are to do something useful with quantum computers?

And when we look at that metric and extrapolate its progression over the last years, when do we expect QCs to hit datacenters?

I guess blurring it is similar to reducing the resolution or to looking at the image from further away.

It's interesting that the neural net figures out the circles, but not the words. Because the circles are also not so easily apparent from looking closely at the image. It could also be whirly lines.

I gave it a sentence, which I created by placing 500 circles via a genetic algorithm to form a sentence. And then drew with an actual physical circle:

https://www.instagram.com/marekgibney/p/BiFNyYBhvGr/

Interestingly, it sees the circles just fine, but not the sentence. It replied with this:

    The image contains no text or other elements
    that can be represented in Markdown. It is a
    visual composition of circles and does not
    convey any information that can be translated
    into Markdown format.

You could also use vim in a loop. Say you want to replace "hello" in all files in the current dir with "world" and confirm every replace, then you would do:

    for f in $(grep -l 'hello' *); do vim -c ':%s/hello/world/gc | wq' "$f"; done

Or if you want to use some more vim magic, this simpler command will do the same:

    vim -c "argdo %s/hello/world/gce | update" -c "qall" *

"argdo" will do the replace command for each file, the additional e modifier in gce will ignore files that do not contain the search string and the second command "qall" is to quit vim after the work is done.

    which costs time

No sure this holds true anymore.

When you go to a site like reddit.com which uses HTTP/2, you see a gazillion of requests for JS files, many starting at the same time and ending at the same time.

I think that is because newer HTTP versions can put multiple requests in the same data packet. And even HTTP/3 is now supported by over 90% of browsers.

From my perspective, the biggest flaw in FireFox is that it does not support the File System Access API.

Because with it, we can offer users to hold their data natively on their devices. Instead of storing everything in the cloud.

Chrome on the desktop supports it. Here is a demo:

https://googlechromelabs.github.io/text-editor/

A text editor that works just like a native application.

And mobile support is also in the making:

https://issues.chromium.org/issues/40101963

I can't wait to use this in my web applications. Finally a way to build proper tools in the browser.

The "Origin private file system" that this story links to is just like the infamous IndexDB. Something that the user cannot backup, cannot use in other software and that is only kept around for as long as FireFox feels like.

Couldn't the browser simply internally turn this:

    function f1() {
        x = await fetch('something');
        ...
    }

Into this:

    function f1() {
        fetch('something').then(x => {
            ...
        });
    }

The difference would be that you still can call the function without await.

So this would be possible:

    async function f1() {
        f2();
    }

    function f2() {
        await fetch('something');
        ...
    }

Instead of having to async each and every function and await each and every function call:

    async function f1() {
        await f2();
    }

    async function f2() {
        await fetch('something');
        ...
    }

Which is what TFA complains about and what indeed is a pain in the ass.

What problem would arise if synchronous functions could use await?

A quick fix to the problem would be to allow synchronous functions to use await.

Linux, Apache, MariaDB, PHP, Python, HTML, CSS, JavaScript.

Some pages still use JQuery, but I wouldn't use it in new projects. Browsers are a joy to work with these days, no more need for any libraries.

Yes, Linux, Apache, MariaDB and PHP or Python are pretty good choices I would say.

For a large project (with years of manpower baked in) I would expect about a day of maintenance work per year. Assuming you have good test coverage.

WordPress might indeed be a good choice for a CMS.

How well does self-hosted WordPress (without plugins) behave when updating? I would think that even major releases can be updated with a simple click and don't break anything?

The one thing I learned from running https://www.gnod.com (20 years) and https://www.productchart.com (10 years):

Keep your stack flat.

Most projects of my web developer friends died after months or a few years. None survived for decades. And the reason was always stack rot.

Multiple parts of their stack became outdated and so hard to update that they quit.

I doubt that people will know what to do with the "2D barcode" in 100 years. Someone who is willing to investigate will figure it out. But it is not something that will be convenient.

I for example wouldn't know what to do with a barcode even today.

Without clothes, houses, heating and running water, fertilizers, tractors and specially bred crops, Earth would be pretty alien to us today.

I wonder what technologies we will have at our disposal in 500 years.

Depends on the import tree. The way I understand it, this:

    import { x } from '/a.js';
    import { y } from '/b.js';

Does not take longer than this:

    import { x } from '/a.js';

Because the message to the server "Give me b.js" goes out in the same network packet as "Give me a.js" and the data of b.js comes back in the same packet(s) as the data of a.js.

Good point!

I wonder what I would have to look for in my codebase in terms of what could break when dqsA starts returning an array instead of a NodeList?

AFAIK modern HTTP versions like HTTP/3 can request multiple files in a single network packet. So it is basically free to do "another request". As the data request goes out and the data comes in in packets with other "requests".