I mean I understand that this can happen, my point is that we should code things in a way where the huge majority your code will still work no matter if you have an old rhel box or the latest archlinux, just like today we can port doom to pretty much any platform without too much trouble.
> I only have the nagging question that if it’s so easy, why would the clients not do it by themselves?
I mean, that's exactly what's starting to happen, we have more and more clients to whom we propose a quote and their answer is "guess i'll just vibe code it" or come to use with an app that they vibe-coded and does the job, and they're content with it. So far it seems to work out just fine for them.
I was wondering "hopefully C++ allows you to pick across these axes so that you can build yourself the async primitives that work best for the problem at hand" and then: yes!
> We cannot attribute C++ to any particular design point in the taxonomy provided in Table 1 because each axis is configurable. Although elegant and neutral, the choice of full programmability makes each library an async dsl; knowledge transfer between projects within the same language becomes exceedingly difficult.
It is not if you think in terms of these axes and which solve your particular problem and not any particular specific design. Take for instance the simplest program one can imagine: a network video player. E.g. some server sends you RTP audio & video frames and you have to play them back correctly, with a nice GUI on top.
If you want to do this in a way that is as efficient as possible you need to be aware of all possible ways of async interoperation:
- connecting & receiving packets from the network in a classic network state machine where coroutines shine
- handling vsync vs not-vsync for displaying the video frame
- conforming to whatever async paradigm the hardware video decoding system you want to use is going to provide you with, e.g. Intel QuickSync vs VideoToolbox vs NVDEC...
- handling the synchronous model of audio playback driven in pull mode
- handling the synchronisation between audio / video, and thus the async patterns that support multi-threading as your audio thread can't be your video or GUI thread
- handling the async model of your GUI library for your play / stop button's callbacks.
There's zero chance that a single async model fits all of these equally well without tradeoffs, so you have to have the knowledge anyways.
Agree with your post except the adjective "simple" for a network video player.
Decoding video/audio and talking to the right OS APIs and GPU is far from simple. It is reasonable to implement a http1 client from scratch by hand. For decoding, you need libraries/dependencies. And suddenly you have to find the intersection of dependencies that play nice in your async model of choice.
> A human given a task that requires internet and given a system with no internet would most likely raise the issue to their superiors or otherwise go through official channels to have the tools available to do their job.
i'd be curious to see a study on this. I'd guess it'd be closer to 60/70% compliance and 30/40% "trying to hack things" for humans.
imagine picking some Vue framework over Qt when talking about "the stable road future kids walk down to become professionals". There's software written today in Qt that traces back all the way to the mid 90s and are still top-of-the-line for their business.
The project I'm working on has been based on Qt since Qt 4 era, has been through people vouching for JavaFx, Angular, JUCE, React, Electron, and a dozen other frameworks over Qt, and had entire competitors based on web tech come and wither. How many Vue software will still be written in Vue 20 years from now ?
Structurally, Qt is sometimes worse given the compatibility issues. There are desktops where Qt5/Qt6 software runs fine if you can get it to compile, but the GL interface has been broken on many platforms for over a decade.
If folks don't plan on maintaining things after a release cycle it no longer matters how one ports disposable code. On mobile the App life cycles are short. Quasar does exactly what Qt has been doing for years, but just abstracts the compilation pipeline for each MacOS/Win11/Android/iOS/Linux platform. For simple stuff it works fine, and generates solutions in under an hour.
>How many Vue software will still be written in Vue 20 years from now ?
Probably all of them in their bloated glory, as the build artifacts do not rely on a single unstable external fragile framework library heavily coupled to the operating system releases.
Personally I prefer wxWidgets for desktop, but it is not appropriate for every project. =3
> There are desktops where Qt5/Qt6 software runs fine if you can get it to compile, but the GL interface has been broken on many platforms for over a decade.
do you have example / bugreports of this ? for my app I run tests across a wide range of laptops, platforms and distros, across nvidia / intel / amd / llvmpipe / ... and it all works fine. hell, with the help of Claude I managed to port back the current dev branch of Qt6 back to Windows XP, with working OpenGL.
I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...
Please don't brush off parent's "slow connection". Many people are stuck with that.
A prime example: cookie dialogs. On a slow connection, page loads, large parts are rendered, and you start reading. After that, some script starts to present a cookie dialog, and everything freezes. Page doesn't scroll anymore, buttons don't work, sometimes a previously-readable page is darkened or otherwise obscured so you can't keep reading while this goes on.
Then a whole bunch of stuff is downloading, which (again: "slow connection") takes forever. Like 20s+. Halfway through you see "accept / reject / settings", but none of those buttons respond (except the dark pattern where "accept" often works faster or smoother than either "reject" or "settings". Aaargh!). When things respond again, consider yourself lucky when page re-renders as before.
Which also runs afoul of 1 of my pet peeves with user interfaces: DO NOT PRESENT A UI ELEMENT UNTIL CODE TO PROCESS ITS USE, IS PRESENT IN MEMORY & READY. Really simple right? Yet I see examples ignoring this oooften.
A 'slow' CPU, low RAM/swapping etc just makes this worse. Web developers tend to have fast machines & connectivity so they may not even be aware of this. Or think it's a non-issue even though it affects many users - existing or potential.
It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts.
Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.
Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.
But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past.
Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework.
Use the appropriate technology, everything doesn't have to be a SPA.
And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse.
If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.
In London in many apartment blocks one can only get wired internet via an old copper cable with speeds like 80mbit/s download in theory but in practice it can be below 30 with ping in 50ms range and much slower upload. And 5g does not help either as the signal can be very weak.
Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!
A phone line from before WWII works fine to make a call but absolutely sucks for DSL.
And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.
It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.
You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.
And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.
The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.
Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.
I was using a laptop with windows 10 and 4GB of ram and an anemic CPU a few times a month two years ago. Even with a fast network, a laptop with no ram is gonna be slow to browse, and bloated pages are gonna be slower.
It will certainly help to download the bloat faster, but you've still got to do all the hydration as OP put it.
Based on my experiences with windows 11, that laptop seems like it will be quite a bit worse than the one I was using, even though mine probably has a much worse cpu.
my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that
Try it yourself on a gigabit internet. Put CPU throttling in devtools to 10x slowdown (assuming you have a fast computer) and see how fast it is even with super fast internet.
what are they wrong for ? I'm seeing 100+ unreal blueprints, labview and n8n jobs (hundreds each) just in the city I live in and you really believe no-code is not a thing ?
really says a lot that someone can say this apparently absolutely seriously
reply