This is sort of a "does anyone else?" type question, but I think it can create some interesting discussion.

We have become accustomed to having many things for free online. Search, social media, news, videos, games etc. The price of course is ads and our personal data. But spending money on these kinds of services that exists for free sometimes feels like a hurdle to overcome. I recently gave the paid search engine Kagi a try, and I spent way too much time pondering whether it was worth the $5. Yet I can spend ten times as much on random physical purchases or a round drinks with only a few seconds of decision making.

Even though we have lived with digital products for decades now, having something tangible and physical between your fingers still feels better. With some exceptions, because most people are paying for streaming services but renting movies in the video store have always cost money, so we are used to that - unlike stuff like search and email which many of us have gotten used to being available for free.

Can this ever change outside very tech-minded people? Because services that rely on subscriptions rather than dataharvesting and ads do exist, but with the exceptions of maybe the big streaming services, few get wider appeal and the masses flock to the so-called free services instead. I find it almost depressing that we have all these brilliant and innovative tech companies around the world doing amazing things, but a good deal of it all ends up with the goal of showing more ads. It is hard to compete with free, but is it possible to challenge the current most successful business model of "paying" with ads and data?

Have you been visiting just too many different social media platforms lately, checking them out to see what the deal is? Well, same here. It feels like I've been a guest every night in different houses for the past month and I must say: I am exhausted.

But it's not over, far from it.

And I'm here to give you a heads up: we've witnessed platforms dying in the past, I'm guessing most of us have been a part of some sort of digital exodus before but I have a feeling that this one is going to be more painful.

Mainly because we've created so much data over the years and the majority of it got collected by centralised platforms. There are very few ways to take it with us and move elsewhere, it's all locked in.

Backing up your data now would also be a good idea, before some CEO comes with up the plan that it should be a paid feature.

I just want to say that this is all to be expected because the social web is in a transition period, and that golden bookmark doesn't exist yet. However, I think there are some contenders for it. What I want to ask is: where will you go next?

I've got some ideas, feel free to add your preference if I'm missing anything.

• Threads: Meta's Twitter clone that will be out some time this summer. It will be a federated (ActivityPub-enabled) platform.
• Bluesky: Jack Dorsey-backed Twitter clone. This one is also federated but it uses AT Protocol.
• Mastodon: The Twitter clone. It's got a fairly large userbase now, with lots of instances to choose from.
• Blog: Maybe it's not a bad idea to set up shop on a platform like Micro.blog (which is ActivityPub-enabled and has got community features built-in) and lead a quiet digital life.
• Threadiverse: Reddit-alikes.

I'm having some trouble getting the local developer environment set up on Apple hardware, specifically it seems because Virtualbox, which is used as the provider, is not properly functioning on Apple hardware.

Is there anyone here who has managed to get it up and running?

I'm no luddite. I'm a tech consultant who likes shaving microseconds off API calls.

But for social media, dear tildellows, please consider embracing a slower web. I mention this as I hear a few people for example missing push notifications for messages, etc.

Consider that nobody on social media websites needs to reach you instantly.
Consider that there is nothing happening on such sites that you need to read ASAP.
Consider that you will never be able to keep up with the world, and that trying to stay at the edge of some information will just mean you're missing out on some other edge.

Read your town's local news, which is a lot more likely to impact you. And it's ok to respond to your DMs after a couple days.

Someone mentioned elsewhere that they signed up for Tildes “years ago during the beta”. That reminded me: Tildes hasn’t reached beta-testing yet.

Officially, Tildes is still in alpha-testing phase.

The login page says “Tildes is currently in invite-only alpha...” And the Contact page says “To request an invite to the Tildes alpha...”

We’re still in alpha-testing. Alpha-testing of software usually happens on an incomplete product before it is released to the customer.

This is a very important point. Tildes is not feature-complete yet: there are literally hundreds of feature requests yet to work on before Tildes will be what people want it to be – and even that list is far from complete. In Agile software development terms, Tildes is a minimum viable product, or, in other words, “a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development”.

Tildes works as it is, but it’s a bare-bones forum: you can post, and comment… and that’s about it. It’s a proof of concept. There are a few minor tweaks here and there, which give the impression that Tildes is more complex than it is, but they’re misleading. There are plans to make Tildes a more complex website but, right now, most of that complexity of Tildes exists only in people’s imaginations (and there have been some very imaginative people contributing to that list of future features!).

Most questions about “Why doesn’t Tildes do X?” or “Can Tildes do X?” can be answered simply by saying “Tildes is incomplete and X hasn’t been built yet.” There are some questions about missing features which can be answered by saying “Tildes was never intended to do X”, but those are far and away in the minority. Most flaws, drawbacks, and problems with Tildes exist because Tildes is still a proof of concept, rather than a finished product.

It’s also worth noting that Tildes’ current feature set is absolutely not up to the task if the user base and site activity increase too quickly. There’s too much manual tinkering required at the moment to make things work properly: for one thing, there are no significant moderation tools on Tildes (that’s almost all done manually at the moment). There are still a lot of features yet to be built - and we don’t even know what some of those features are yet!

To pre-empt the people who will rightly point out that Tildes is 5 years old: Tildes’ feature set was intended to grow gradually over time, in line with a gradual growth in users, activity, and the need for those features to exist. However, Tildes has not undergone much growth over the past few years, so the existing features were sufficient to manage the existing activity. Basically, the site didn’t need a lot of fancy features to handle the low traffic here.

This sudden surge of new users might change that. But it will take time to build more features. That was always the intention, and it hasn’t changed now.

Until then: Tildes is still in alpha-testing. It’s an unfinished product. Set your expectations accordingly.

EDIT:

If you're one of the many people who seem to be replying to this topic, saying "it's okay, I like this simple bare-bones site as it is"... then you're probably not part of my original intended audience for this topic. This topic was aimed at all the people who are arriving here, being taken aback at how simple Tildes is, and wondering where the advanced features are.

However, we can still take the "set your expectations accordingly" message and apply it to you: "Tildes is an unfinished product, so you can expect it to change in the future. It won't be like this forever."

Either way, "set your expectations accordingly" is the message here, whether you're expecting more features and not finding them, or whether you're expecting simplicity and enjoying what you see. Either way, you should know that things will change around here. Maybe slowly. Maybe quickly. Maybe they'll get better from your point of view. Maybe they'll get worse from your point of view. But, change they will.

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?

I think most of us probably agree that browsing the net and taking part in online communities used to have more of an allure, and that in recent years the online experience has been really negatively affected by corporate and cultural trends. At the same time, I have a feeling that many of us probably disagree about when the "golden age" was, and probably disagree even more strongly on what made the golden age so great. So I am curious, what was the golden age of the internet to you? What time or era did you get the most enjoyment and fulfillment out of being online, and what about that era made it so?

I was wondering if anyone else around here consistently reads any of the many webcomics out there. I really love reading XKCD, CommitStrip, Questionable Content, Alice Grove, and Mare Internum.

If you'd like to have a discussion about art styles, writing, the communities around the comics, how in the world Randall Munroe manages to continually come up with ideas for comics that make XKCD even more relevant for everything, or whatever else you might want to talk about, I'd love to talk with you about it.

Most of the world seems to be settled around Chrome and Safari these days. I remember using Firefox a long time ago myself but then everyone started switching to Chrome and that also turned out to be a natural path of least resistance for web developers like me who had to test web apps in local environment.

This switch happened in circa 2015-16 if I recall correctly, many other browsers have evolved since then and people are looking at alternatives. The Android Kiwi browser, for example, is a great alternative for power users on mobile who need plugins but Chrome won't allow that. Other alternatives have evolved too like Brendan Eich's Brave browser which seems to be promising. Anyone here tried that yet?

I have half a mind to go back to Firefox but I recently learned about how Mozilla Corp is also funded by Google and that turned me off. Wouldn't you rather want to deal with the Devil directly instead of the Devil's assistant or sidekick!

And then there are also those who use Garibaldi, Midori, etc. but I can't go that purist way. I'm way too dependent on the digital way of life and sites like amazon and flipkart won't work in those browsers. What do you think should be the right path ahead from here?

I figured that more than complaining about the dearth of random and weird websites, I might ought to contribute something. I almost went to MassArt for new media installations. In those days I was a web monkey with a solid design bent and very orthogonal thinking. I still have a smidgeon of the thinking, we'll see what I have left of my design skills, but my tech skills are hopeless. Back then my tools were freehand, dreamweaver, bbedit, photoshop, flash, Perl, Solaris, mySQL. My last website was done with rudimentary css.

I would like to get right to the design and expression phase, I don't have an inclination to dive into coding. I also don't want to worry about security. I'll throw a few bucks down.

I'm still comfortable in photoshop, but would like a more fun tool. I cannot stand illustrator, and would love to have a vigorous chat with the folks at Adobe who chose to promote it and shelve freehand. Better yet, an even more vigorous chat with the moron at the FTC who approved Adobe's buyout of macromedia. You can bet that will be on the website. Is there any equivalent to freehand? I saw the post about a free, online illustration tool that came through recently, that might be a smidge rudimentary. What about dreamweaver? And how to publish? I don't care to learn about content management, scripting, databases, etc. if I can avoid it.

Bonus if there are AI tools to help.

Yesterday, Adsense support sent an email to their users regarding their upcoming policy changes. This primarily affects how subdomains are monetized. Going forward, your subdomains inside the primary domains in the "Sites" section (www, etc.) won't be allowed, any existing ones will be removed and their rules will be merged with the primary domain (such as example.com).

Furthermore, what constitutes a "Site" will also change henceforth. You can only add a primary domain (such as example.com) and the subdomains which are listed on the public suffix list (such as github.io, blogspot.com, etc.). Thus, your own subdomains (such as xyz.example.com or www.example.com) won't be allowed in Adsense.

I don't know what they will achieve by doing this considering they already vet and audit each site before approving them for adsense? In any case, other alternatives to Adsense exist such as Propeller Ads, CJ Affiliate, etc. for those affected by this move but I don't know their efficacy.

I'm a full stack dev and my current use of JavaScript language is limited to making the best (read trivial) use of jquery for DOM manipulation in my web apps which primarily use PHP or Python (Flask/Django) as backend.

Now, have you watched that popular thriller movie called Inception which is based on a radical sci-fi concept that an idea or thought can be implanted into someone remotely?

Just like that, I often find myself facing this strange idea that JavaScript is supposed to be just a toy running inside the web browser. No idea where exactly this idea came from! Each time I try to learn JS or think of getting deeper with things like npm, react, etc., this idea just pops up and kinda stops me from doing anything!

Is there any way to get rid of this idea somehow?

Title says it all. Bootstrap+jquery has been my default route and path of least resistance when it comes to web development. Perhaps because I'm coding since a long time and belong to the old school when modern libraries like react weren't yet invented yet?

I had tried to meddle with Angular.js 1.0 back in those days but was soon disillusioned! It was cool and cutting edge but highly opinionated. It tried to do so many things under the hood that I soon quit the effort and the word "Angular" was stigmatized in my mind ever since! I don't know how different today's typescript based Angular is but that stigma or phobia prevents me from even looking at that direction!

React is another cool technology which everyone is talking about and I'm sure it has some merits. But I'm not sure exactly what React brings to my development workflow which jquery doesn't already do. Can you tell me some specific advantages or pros of react over jquery which can motivate me to learn the former and let go of the latter? What should I do?

I'm working on an app idea, it's going to be "API first" in design which means there is a clear separation between the backend and frontend. Former will be accessible through a REST API and the latter can be simple HTML without me having to delve too much on it. The idea is that the end users or clients will write their own front-end interacting with this REST API in future.

Firstly, I want to know where to start. Writing a REST API seems quite easy and simple for me as a backend engineer but I've never implemented a "pure API" app in practice. Do you just validate the headers, do the crunching and return back a JSON response? What all must you take care of here?

Finally, authentication and session handling is something very important here, isn't it? If I make use of session feature in the REST API (like PHP sessions or Django sessions, for eg), authentication will be pretty easier. I don't have to worry about encryption as SSL/TLS would be already doing that for me through the browser. But then what is the downside of this method? Why do so many people use JWT tokens then?

Coming to JWT tokens, is that the only way of encrypting/validating REST APIs, or are there others? My biggest concern here is scaling and performance. I'm willing to implement the most efficient path here, the one that gives the most performance using least resources.

I say that after throwing some caution to air because I understand that every new thing has some initial resistance or pushback due to the "past comfort zone" effect.

But having said that, I feel the aesthetics of the old site was much better than the new one. But then again, I'm from the old-school world who also prefers old reddit to the new one in browsing experience, so my opinion could be biased! But even considering the modern web design, don't you think the black icons on the top right have a somewhat odd look? And the "21 languages" feels a bit verbose, the I10N icon already conveys what that dropdown is about? And finally, that scrollable sidebar on the left looks a tad ugly?

I just hope this is just a beta stage or something of Wikipedia's new version and a better one will evolve soon! But that's just one humble unpopular opinion, me thinks!

As I recall, about 2-3 years ago I had experimented with what is called the npm install xyz through some tutorials, etc. The objective was to improve my tooling or toolchain at least with things like css/js minification, etc. along with Bootstrap customization. The idea was to then move on to other newer learnings like react, etc.

But I was soon disgruntled by the whole process! Neither bootstrap turned out to be an easy horse to tame, and NPM was like this astronomical universe of packages that keep on downloading into your folders! I soon lost taste of the whole thing and kept using my tried and tested stack of PHP scripts and using stock Bootstrap through CDNs.

But today, I want to give it another shot. Has NPM improved than earlier days? What is the best way to go about building a toolchain using it? Are there any useful guides that make the whole process easier to digest?

I happen to host my blog https://prahladyeri.github.io/blog statically, built using Pelican and served on Github Pages. Plebs like us can't afford a backend server infrastructure, so we must rely on external services like Disqus for comment hosting.

So far, Disqus was the only fellow in town who allowed us to host comments on a free plan. Though there were some issues (bloat, adware, etc.), people seemed to be generally happy with it so far.

But now, a new fellow named giscus commenting system has entered the town, it's basically powered by github. Since I already host my blog on github pages, this should be a natural choice for me, right? Many bloggers seem to be migrating to this new system and I might too soon. The downsides however are as follows:

1. It won't allow me to export existing comments from the old disqus system. Understandable to an extent as those exact author usernames may not be on the Github platform?
2. Disqus interface seems to have improved all of a sudden in last few days! There no longer seem to be any ad and even the comment interface seems to be less heavy or cluttered now. It might sound a bit conspiratorial in nature but could this be the result of rising competition in the form of Giscus!

I'm a lazy status-quoist by nature and might well end up retaining disqus if they don't deviate too much from where they are now. But I'll keep an eye out on Giscus too and its progress. What do you guys suggest?