And as long as I'm asking ... nginx or Apache (or Caddy or whatever else you think is best).

I'm hosting a few web sites and services, but currently, everything is "out there" on VPSes. I want to bring it all in-house, go back to the old days of actually hosting websites out of my living room.

Towards that end, I am gradually upgrading and overhauling all the sites and services, fixing long-standing issues and inefficiencies in the config files, merging servers, etc.

I have never learned Docker. I've started to several times, worked with it a bit on a job once, used it a bit here and there; so I'm not clueless, but it would be a learning curve.

Also, I'm running one main service (Nextcloud) that officially, only supports Apache -- there absolutely are nginx setup guidelines and tutorials and such, but that's all unofficial, experimental setups.

And I'm running another major service (Synapse), on nginx.

And I want to merge the servers, and choose one web server to host both of them, and I don't know which way to go there.

Thanks for any feedback.

I remember way back in the day when YouTube was still in a Flash Player, you had the ability to dynamically overlay link buttons and clickable areas over videos at specific times/area and it was a lesser used but nice feature. There were a couple of videos that used it to sneak links to unlisted bonus content but it mostly helped when something was highlighted and clicking it would take you to relevant info. Think you could also use it for spesific playback controls.

I'm scoping out a small project and think it'd be cool to have a video with simmilar basic interactions and even fire off some scripts at different parts of the playback.

Since Flash died, I can't think of any web player that let's you create this sort of dynamic overlay/interface or implement logic to the media playback. I know Adobe Encore can be used to make this sort of stuff for DVD menus and I used to make training videos with old software that did similar things. But I don't believe those files are easily web compatible without Flash.

I'm sure a front-end wizard can layer a transparrent canvas and player and script their way to the same functionality and more. Or maybe use a web game engine and build a UI over video playback. But I'm curious if there's any service or library that does it already and saves me from another abandoned side-quest.

Unless I missed something obvisous, the only similiar functionality I've found in the common player libraries are overlaying adverts at set points in the display and you just set the scale and frequency.

We have this big project at work...an "all hands on deck" kinda thing that has us rank-and-file frontend devs working alongside our manager more closely than I'm used to. And it was fine, because I like the guy and he's been a decent manager. But this project is killing me.

On multiple occasions now I've written code, had it pass code review (often with his approval after a round of changes/guidance), and then every few days we get these massive re-write PRs from him where he completely rewrites large chunks of what we've done. It's leaving me feeling a few different ways:

1. Angry because how quickly your code gets replaced is a (imo, bullshit) metric used as a part of our annual reviews and promotion discussions
2. Doubting myself because in my head a good developer doesn't have their code rewritten that quickly.
3. Confused because features I thought I understood are constantly being rewritten leaving me wasting time trying to relearn how things work
4. Wondering what the point of writing code is if it's just going to be thrown in the garbage later in the week?

And like I'll be the first to admit I'm not the most proficient developer on our team. React and Typescript are relatively new concepts to me, despite a long career in web development. But I've been writing with it for about a year now and I had thought I was finally getting a good grasp on things. But now I'm wondering if I'm just an idiot? Is it imposter syndrome or have I actually somehow coasted through a 15 year career across various stacks and it's just now catching up to me?

Or is this just the nature of massive projects like this? We had a half-baked product scope to begin with and its getting daily changes with entire chunks of it not very well thought out by our PM. I can see how it would make sense that the more senior developer might see the need to refactor things when things are constantly changing and we're left writing code based on assumptions and half-written requirements. I'm also getting are comments on my PRs that request changes, but mid-comment he's like "I'll just take care of this because it's blocking me".

It's just really taking a toll on my mental health and how I feel about my job. I've been trying to find another job for a few months now, but I'm not having any luck. Job hunting sucks and when you're already demoralized as hell, it's hard to sell yourself to prospective employers.

Could really use some insight from other experienced devs, please!

I stopped blogging several years ago. Over the last few years, I've been writing plenty of private essays. However, very recently I have been considering starting to publish my writing and, well, start blogging again publicly. I have no desire to waste time on templates, look-and-feel, visual stuff, etc. I just want to write a bog-standard html file, and then publish it...I do value leveraging html elements that help with meta data (e.g. microformats, etc.), but don't care about how things look - and these elements that i value are all invisible to most users anyway. I would be fine with just crafting html by hand, deploying it via sftp or some boring deployment pipleine, and that's it. But, then, I started thinking: what about having an RSS/Atom feed? I used to consume content via an rss reader, but have not done so in years. But, I don't want to manually craft that feed file; nope, sorry. But, I've heard a comment or two from acquaintances that rss/atom feeds and syndication are really something that people - like my potential audience - might really desire. So, I should really consider having one. This means that either I have to craft several things manually (from the blog post itself, the list of archived posts, the feed file, etc.), or use a static site generator that will handle all this for me, etc. I don't want to get trapped down a rabbit hole where I am spending so much on the tooling, the scaffolding, twiddling with templates, or the publish process itself. I just want the minimal for writing and publishing, I want it to live on my domain name, and that's it. Am I crazy or extremely lazy for not wanting to generate an RSS/Atom feed file?

So, here's my ask of you all nice people: are feeds like RSS/Atom feeds even worth it? If so, does anyone have recommendations for a manual process where i can craft the blog post's html by hand, but somehow leverage a portion of a static site generator (or some minimal tool) to only automate the creation of the RSS/Atom feed file? Thanks in advfance for any constructive feedback!

P.S. - One thing that re-ignited my desire both to write more in public, and keep it alive with minimal fuss was my re-reading of Jeff Huang's excellent "This Page is Designed to Last" post: https://jeffhuang.com/designed_to_last/

I've copied the full tweet below (it's from August, I missed this news somehow):

We've been evaluating a number of C++ successor languages for @ladybirdbrowser , and the one best suited to our needs appears to be @SwiftLang 🪶

Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!

Why do we like Swift?

First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.

Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.

The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.

Strong ties to Apple?

Swift has historically been strongly tied to Apple and their platforms, but in the last year, there's been a push for "swiftlang" to become more independent. (It's now in a separate GitHub org, no longer in "apple", for example).

Support for non-Apple platforms is also improving, as is the support for other, LSP-based development environments.

What happens next?

We aren't able to start using it just yet, as the current release of Swift ships with a version of Clang that's too old to grok our existing C++ codebase. But when Swift 6 comes out of beta this fall, we will begin using it!

No language is perfect, and there are a lot of things here that we don't know yet. I'm not aware of anyone doing browser engine stuff in Swift before, so we'll probably end up with feedback for the Swift team as well.

I'm super excited about this! We must steer Ladybird towards memory safety, and the first step is selecting a successor language that we can begin adopting very soon. 🤓🐞

Nitter link:

https://nitter.poast.org/awesomekling/status/1822236888188498031

Original post:

https://x.com/awesomekling/status/1822236888188498031

Some of Kling's replies in that thread are also pretty interesting:

My general thoughts on Rust:
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
- Really impressive ecosystem
- Toxic community

In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop.

The September monthly report for Ladybird released the day after I posted this. It provides basically the same information:

This Month in Ladybird September 2024

The section about Swift:

Successor language search progress

Over the past year, our core contributors have been exploring potential safe languages to complement or succeed C++. We evaluated several options, including Rust, Swift, Fil-C, and others. While some languages offered compelling features, many fell short in either C++ interoperability or providing the level of memory safety we needed.

After extensive testing and discussion, Swift emerged as the top choice among our core developers, thanks to the new Swift 6 interoperability features and its growing cross-platform support. As a result, we’ve decided to adopt Swift as our C++ successor language.

That said, this will be an incremental shift. The existing C++ codebase is deeply embedded in the project, and a complete rewrite would be impractical. Instead, we’ll be gradually introducing new components in Swift, carefully integrating them with our existing C++ code over time. Look forward to a dedicated blog post on the topic soon.

Hey all! I've been thinking about buying a domain and building a personal website for myself -- at this point just a personal website with links to my socials, my CV, maybe any interesting projects I want to publicize. Maybe someday I'll decide I want to add a blog or build a webapp or something, but for now it'll be something simple and static.

My programming experience is very much not in the frontend side of things (I'm a data scientist and mostly use python day-to-day). I played around with HTML messing with my Tumblr theme enough back in the day that I'm reasonably sure I can build something solidly web 1.0, and I've toyed with stuff like Jekyll in the past. But I was wondering if I could use this as an opportunity to build up some basic skills that I could put on my resume for the future. But I have no idea what's out there that would be useful and quick to learn but wouldn't be massive overkill for a project like this.

I also have no idea how web-hosting works and who to go with if I want to build a personal website myself rather than relying on something like Wix or Wordpress. Most of the easily-Google-able advice is for different use-cases. Advice is either people who want something user-friendly with minimal coding like Wordpress or it's for something properly big and commercial, neither of which is me.

Anyway, I know we've got a lot of suitably tech-y people here on Tildes, so I'm hoping people here have good advice for this sort of use case. Thanks!

I have a couple of old Reddit accounts I’d like to delete as fully as possible. However one of them dates back to my teenage years and it’s some of the only writings I have from that time. Any recommendations on good simple ways to scrape all the comments off of it and save them? Then what’s the best way to completely erase a Reddit footprint these days?

Looking for as simple a solution as possible, I’m not tech illiterate by any means but it’s also not a real strong suit for me.

The history of the web is littered with with many a dead image/video hosting service. Echos of their existence plague older forums in the form of broken links and images. It seems like they all follow the same path, starting up as the new "simple" service that just hosts images, no fuss. But then as interest grows, so do costs, and the service owners have to scramble to monetize. Generally this is done by stuffing the place full of ads until everyone leaves. Alternatively the owners are stubborn and stick to their guns, until they inevitably have to shut down due to drowning in costs. When they do shut down, millions of assets are lost and the graveyard of broken images across the web grows some more.

https://gfycat.com/ is the latest notable victim of this.

With all the recent social media turmoil, there as been lots of exploration of alternative sites, and all of them have to overcome the problem of hosting media in one way or another.

Tildes obviously does this by avoiding it entirely which, while a very effective solution, is just handballing the problem elsewhere. Users will still want to post images and videos but they will just have to find alternative hosts. Over time those hosts will die and Tildes posts will be filled with dead links.

Mastodon has similar problems,the biggest cost of hosting a mastodon instance is the storage and bandwidth required to facilitate media posts. And there's a real danger of an instance incurring high costs if a particular post becomes popular and is hotlinked on a big centralised social media site.

It seems like a really tricky problem to solve, something peer-to-peer could sort of solve the costs created by traffic peaks but has problems when there is many small files viewed by few individuals each.

Are there any other solutions out there? Web3, IPFS? Or is it just not that much of a problem, do we accept that media on the web is ephemeral and will be lost after a while?

Hey there! Any web developers/designers out there that have resources on creating websites that are fully accessible? I am getting back into web development after a decade away and want to learn the correct way. Thanks for any tips!

I know quite a controversial and opinionated question, one that might easily get blasted with downvotes on a site like StackOverflow or even Reddit! Nevertheless, one which I believe is still relevant to ask and useful one even in 2023.

The problem with backend web technologies is that we are overwhelmed with choices. Whilst getting spoilt with choices seems like a useful thing sometimes, it might easily be an impediment in decision making too. Based on my experience, there are a bunch of useful stacks and I will work on any of them if you pay me to work as a freelance coder. Each has its own pros and cons but I'm yet to find the ideal one which according to me is something that should be easy to code and deploy while also better performing at the same time.

• ASP.NET: C# is the language I started coding web apps with in my last company and ASP.NET web forms was quite the rage back then. PHP was also gaining traction in the open source world and the webdev was mostly divided between the Enterprisey .NET aristocrats of Microsoft world and the poor PHP peasants of the FOSS world! One good thing about ASP.NET was performance. Since MS controlled the whole stack, they also put great efforts at making it work faster. The bad thing, of course, was dependence on a closed tech stack and a closed black box that generated JS functionality on its own.
• PHP: When I resigned from that company and started freelancing, I came to know about open source, linux, XAMPP, etc. That was when I realized that my own attitudes and thinking was more attuned to the FOSS peasant mindset than the wealthy aristocrat's! I didn't earn quite as much in freelancing with WP, Drupal, SuiteCRM, CodeIgniter, etc. but I found great happiness and contentment in being part of the open source process. Till date, PHP remains my favorite language for backend development and most of my web projects involve CodeIgniter or even pure PHP.
• Python: Flask is what got me interested in Python web development. The sheer minimalism and flexibility of that framework is what I found quite remarkable and quite a rarity in the frameworks world. And jinja2 template system was just fantastic. The other framework called django is more popular I think and I've worked on that too but Flask still remains my favorite. Flask is good in performance dept. too but I think it gets tricky once you start scaling with too many users.
• Java: I've never really bothered with Java web development except a few tutorial experiments on the Apache TomEE server. The multi-layered approach that Java takes not only has very steep learning curve but unless you're a very gifted programmer, it's practically impossible to beat the performance of interpreted PHP/Flask!
• NodeJS: Again, not much work here except brief hobby projects like http-live-simulator. The npm packaging system really turned me off initially with so many packages and issues with that system in the earlier days. Nowadays, I've heard that it's much usable but I've never gotten into it.

And now, we also have the evolving languages like Golang, Rust, etc. taking their baby steps towards web development too! Are any of them worth giving a try? If someone were to ask you for a backend tech stack recommendation while giving equal weightage to performance, developer productivity and ease of deployment, which one will you suggest?

A common theme in web development, and the crux of the so-called "Web 2.0" is scrolling through dynamic lists of content. Tildes is such an example: you can scroll through about 50 topics on the front page before you reach a "next" button if you want to keep looking.

There's a certain beauty in the simplicity of the next/previous page. When done right it's fast, it's easy, and fits neatly into a server-side rendered model. However, it does cause that small bit of friction where you need to hit the next button to go forward -- taking you out of the "flow", so-to-speak. It's slick, but it could be slicker. Perhaps more importantly, it's an interesting problem to solve.

A step up from the next/previous button is to load the next page of content when you reach the end of the list, inserting it below. If the load is pretty fast, this will hardly interrupt your flow at all! The ever-so-popular reddit enhancement suite does precisely that for reddit: instead of a next button, when you reach the bottom, the next page of items simply plops into place. If the loading isn't fast enough, perhaps instead of loading when they reach the last item, you might choose to load when they hit the fifth from last item, etc.

To try to keep this post more concrete, and more helpful, here's how this type of pagination would work in practice, in typescript and using the Intersection Observer API but otherwise framework agnostic:

/**
 * Allows the user to scroll forever through the given list by calling the given loadMore()
 * function whenever the bottom element (by default) becomes visible. This assumes that
 * loadMore is the only thing that modifies the list, and that the list is done being modified
 * once the promise returned from loadMore resolves
 *
 * @param list The element which contains the individual items
 * @param loadMore A function which can be called to insert more items into the list. Can return
 *   a rejected promise to indicate that there are no more items to load
 * @param triggerLoadAt The index of the child in the list which triggers the load. Negative numbers
 *   are interpreted as offsets from the end of the list. 
 */
function handlePagination(list: Element, loadMore: () => Promise<void>, triggerLoadAt: number = -1) {
    manageIntersection();
    return;

    function handleIntersection(ele: Element, handler: () => void): () => void {
        let active = true;
        const observer = new IntersectionObserver((entries) => {
            if (active && entries[0].isIntersecting) {
                handler()
            }
        }, { root: null, threshold: 0.5 });
        observer.observe(ele);
        return () => {
            if (active) {
                active = false;
                observer.disconnect();
            }
        }
    }

    function manageIntersection() {
        const index = triggerLoadAt < 0 ? list.children.length + triggerLoadAt : triggerLoadAt;
        if (index < 0 || index >= list.children.length) {
            throw new Error(`index=${index} is not valid for a list of ${list.children.length} items`);
        }

        const child = list.children[index];
        const removeIntersectionHandler = handleIntersection(child, () => {
            removeIntersectionHandler();
            loadMore().then(() => {
                manageIntersection();
            }).catch((e) => {});
        });
    }
}

If you're sane, this probably suffices for you. However, there is still one problem: as you scroll,
the number of elements on the DOM get longer and longer. This means they necessarily take up
some amount of memory, and browsers probably have to do some amount of work to keep
track of them. Thus, in theory, if you were to scroll long enough, the page would get slower and
slower! How long "long enough" is would depend mostly on how complicated each item is: if each one
is a unique 20k element svg, it'll get slow pretty quickly.

The trick to avoid this, and to get a constant overhead, is that when adding new items below, remove the same number of items above! Of course, if the user scrolls back up they'll be expecting those items to be there, but no worries, the handlePagination from before works just as well for loading items before the first item.

However, this simple change is where a key problem arises: inserting elements below doesn't cause any layout shift, but inserting an item above ought to--right?

The answer is: it depends on the browser! Back in 2017 chrome realized that it's often convenient to be able to insert items into the dom above the viewport, and implemented scroll anchoring, which basically ensures that if you insert an item 50px tall above the viewport, then scroll 50px down so that there's no visual layout shift. Firefox followed suite in 2019, and edge got support in 2020. But alas, safari both on mac and ios does not support scroll anchoring (though they expressed interest in it since 2017)

Now, there's two responses to this:

• Surely Safari support is coming soon, they've posted on that bug as recently as April! Just use simpler pagination for now
• Pshhhh, just implement scroll anchoring ourself!

Of course, I've gone and done #2, and it almost perfectly works. Here's the idea:

• Right before loadMore, find the first item in the list which is inside the viewport. This is the item whose position we don't want to move. Use getBoundingClientRect to find it's top position.
• Perform the DOM manipulation as desired
• Use getBoundingClientRect again to find the new top of that item.
• Insert (or remove) the appropriate amount of blank space at the top of the list to offset the change in client rect (note that if there's scroll anchoring support in the browser this should always be zero, which means this effectively works as progressive enhancement)

Now, the function to do this is a tad too long for this post. I implemented it in React, however, and combined it with some stronger preloading object (we don't need all the items we've fetched from the API on the DOM, so we can use before, onTheDom, after lists to avoid getting a bunch of api requests just from scrolling down and up within the same small number of items).

What's interesting is that it still works perfectly on chrome even with scroll-anchoring disabled (via overflow-anchor: none), but on Safari there is still, sometimes, 1 frame where it renders the wrong scroll position before immediately adjusting. Because I implemented it in react, however, my current hypothesis is I have a mistake somewhere which causes the javascript to yield to the renderer before all the manipulations are done, and it only shows up on Safari because of the generally higher framerates there

If it's interesting to people, I could extract the infinite list component outside of this project: I certainly like it, and in my case I do expect people to want to quickly scroll through hundreds to thousands of items, so the lighter DOM feels worth it (though perhaps it wouldn't if I had known, when starting, how painful getting it to work on Safari would be!).

What do you think of this type of "true" infinite scrolling for web? Good thing, neutral thing, bad thing? Would you use it, if the component were available? Would you remove it, if you saw someone doing this? Are there other questions about how this was accomplished? Is this an appropriate post for Tildes?