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.

I've been looking around online at compatibility for HTML5 browser streaming. It looks like straight up AV1 in a MP4 container is becoming absolutely fine for browser playback on devices.

Is anyone using this on webpages yet? The sooner we move to AV1, the sooner we can have high quality video stored at smaller file sizes, which is a massive bonus.

Right now my company video hosting is purely in MP4 with H264, moov atom to the front as per the requirement, and it plays back on everything with no fallback in a straight HTML5 video container. What's the chance of switching to AV1 and not having to worry about the fallback for the most part?

Edit: I should have used a better title. I used FFMpeg for MP4 and AV1 creation/encoding. This is more about HTML5 video container code and direct AV1 file playback.

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?

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.

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'm primarily a freelance backend dev and for the first time venturing on full-stack development of a non-trivial web app on my own, hence I needed some guidance.

I've got all the backend stuff in php/mysql covered, I just want to know what's the best way to create a dashboard (with left sidebar) considering various aspects like long-term code maintenance and support, robustness, etc. Looks don't matter that much as it's a CRUD app but obviously, better is more appreciated.

Based on my research until now, AdminLTE seems to be the most popular way of doing it among most devs although a few others like material and coreui also seem to have some street cred.

But another approach I'm considering apart from AdminLTE is to just use pure bootstrap and fiddle up my own sidebar using something like this. That way, I won't be tied to just one Bootstrap version which is used by AdminLTE (v4.6) and troubleshooting will be much easier through google search and StackOverflow. What do you guys think is the right approach?

I’m a solo freelance programmer and want to write an app for internal project management, somewhere I can add projects, milestones, tasks, etc. and track them as I work on them, occasionally remind me of things like take a break, lunch time, etc. and over time I can track on which category I worked how many hours, etc.

I’m actually confused between whether to build this as a Web or Windows Desktop app. I’m considering latter because it can run efficiently on my laptop in the system tray using least memory and resources, web-based on the other hand will force me keep running an apache server too which will be an overhead (unless I host it on Google Cloud or someplace which might be an option?)

The only reason for considering web-based is that eventually I’m planning to make this tool open source and with web-based, many others can find this useful too (including OSX/Linux users). At that point, I may consider expanding its schema to include multi-user connectivity, client login, etc. but that’s going too far at this point!

The idea is that this tool should be useful not just for me but other freelancers, students, etc. who might be in my shoes. From that perspective, what do you think is the right technology to use? Web based or Windows based?

(I’ve extensively worked on C#/WinForms projects before and I’m thinking Visual Studio Express for desktop development. If web-based, it’ll be php/mysql based)

I used to use a random FOSS Python program to manage my blog. The software honestly wasn't the best (partially my own fault for not setting it up super well) and I stopped using it, lost my blog's source code, and haven't updated the blog in a long time because of that. So I'm looking for a static site generator that is simple, well maintained, and no-frills.