In gamedev, "optimistic updates" are called "client-side prediction," and are a standard part of multiplayer games. IMO it's somewhat risky to apply the technique to web-apps, since each network request typically corresponds to some important operation, and optimistically updating the UI is lying to the user about whether that operation completed successfully.
IMO a good approach is to update the UI immediately but still show some indication that the operation hasn't completed. So in a chat app, for example, add the message to the list of messages, but with contrast reduced slightly to indicate that other people can't see it yet.
Operations are on average applied within a few hundred milliseconds, and almost never fail. Because of this we treat the success path as default, and indicate that your changes haven't been applied only if we detect that you're offline, or if it takes more than 4 second to apply the changes.
I see this comment over and over again, yet I know lots of Linear-enthusiastic people and none is suffering of this.
Meanwhile after a brief period of Jira being performant, it has felt into ruin again.
In any case, I've tried both, and Jira is on another whole level when it comes to map processes of different teams.
Linear is a good looking toy mostly catered to the average software engineering team, it just doesn't support the flow complexity needed by different business units.
Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.
> Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first?
Nope. As I mentioned, Borland was working on their own OOP C language. ZTC++'s success caused them to abandon it and do Turbo C++. I know this because of my conversations with Eugene Wang. And Turbo C++'s success caused Microsoft to do MSVC++, which was quite late to the game.
Before C++, the newsgroup traffic on C++ and ObjC was about the same. The C++ traffic took off after ZTC++ was released.
It matters in single-pass compilers. You can't allocate a variable in a register if its address is ever taken, but by the time a single-pass compiler knows that information it has already spit out all of the assembly for the function.
IMO the function coloring problem was solved with async/await. This article was posted before Javascript's async/await syntax cleaned up that ecosystem, so the author is only guessing when they say it doesn't fix the issue. It did fix the issue, and now function coloring isn't really a problem.
If async/await doesn't solve the coloring problem, then neither do threads. Why would you ever need to start a thread to invoke a function when you could just invoke the function directly? Because the function is a red function.
This article is about async/await. The function coloring problem arises when you have async functions. Regular functions can't call async functions. You have to hoist them into async functions in order to do that.
Threads do solve this problem because they are just regular functions being called by other regular functions. They don't require the entire function stack to be `async` in order to work.
It is not. It tries to address async/await part-way through, but it does so without the context of 10 years of successful async/await usage in javascript, the language it's criticizing.
> Threads do solve this problem because they are just regular functions being called by other regular functions. They don't require the entire function stack to be `async` in order to work.
This is fixating on syntax: it would be trivial for all functions to simply be `async` by default and for all calls to an `async` function to automatically `await`. This might "fix" the coloring problem as you describe it but I argue wouldn't meaningfully change anything.
Rust's memory safety is as much a social convention as it is a language feature. The language has something better described as "mutation safety," and it's the job of library developers to use that to design UB-free APIs.
I think many people understand this subconsciously, and that this is what drives some of the more performative security culture in Rust spaces (superfluous safety comments, shunning of certain crate authors, `forbid(unsafe)`, push-back against syntax sugar, etc.).
> the culture that... despite easy proof that isn't the case
> devs wrongly assume
> self inflicted complexity
> considered an advantage when argued by C folks
> when the same crowd points
> as the C crowd pretends it to be
You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.
Yes, you get to the heart of the problem - we turned what started of as a document viewer into a general purpose application platform.
Features paramount in a document viewer (broadly, "respect the user's local document viewing preferences") aren't desirable in a general purpose application platform.
A large number of companies/web developers don't think of themselves as offering the user a document to view on their own terms, but rather an "experience" that they want full control over (which means, most of the time: show ads and record user behavior).
If you're offering me a game, fair enough.
But if you're showing me my hotel reservation or electric bill, I want a document, not an ""experience"".
And management asked nobody, and then did it anyway.
Your preferences are unusual. Most people either don't care or prefer flashiness over consistency.
It's something I've come to realise about the why the world is the way it is. Yes, to a certain extent it is because of locally maximal power structures and hierarchies propagating - but it is also because, taken as a whole, people are really just like that. A single politician may be corrupt, but that does not mean that most people, if taking their place, would not be as or more corrupt. Management sucks, yes - but that doesn't mean that most engineers who become managers wouldn't act the same way. You and I may prefer consistency over flashiness, but the majority of the world couldn't care less. So flashiness and "experiences" win.
A nerd podcast that I listen to was talking about shells and touched on Spaceship for zshell. One of the hosts talked about how having multi-line prompts became possible in the 90s, how it isn't new, but how packaging it up is new and now it's a trend for some people.
I'd previously found it interesting enough to try out for half a day. I've been back to my regular boring prompt ever since. Humans are attracted to shiny things. I innately understand why stuff like this is popular, even if I don't understand it intellectually / psychologically (I tried it because it looked cool; it didn't stick; what's different? I don't know, but I could talk a lot about it without really having a structured point.)
Yes, we've broken the intent of the browser. I'm sure there are better examples, but for me it was Google Maps. Oh my goodness, have you ever seen such a thing? It had to be impossible, but they did it. And from there, nothing was safe.
I don't think we can put the genie back in the bottle. There are things we can believe shouldn't be allowed in the browser. But breaking them would break things that people rely upon. Only pushing further to native apps (which I actually like on my desktop computer, phone is a walled garden) would make it possible and that's annoying as hell) could make it possible. Rambling. Just woke up. Please forgive.
On the extreme end, a web app can do all of its own rendering in a canvas with WebGL/WebGPU. Some apps do exactly this: Figma, Google Maps, Google Docs. Just to name a few. (edit: Earlier I claimed PDFjs uses canvas, but it does not. I was confusing it with Google Docs [1].)
It's a thing you can do. But it is very bad for extensions and extension developers for the same reasons that Java applets, Flash, and Shockwave were bad for the web. These apps are difficult for end users to customize. It's a real bane to tinkerers. And it's a shame that "view source" has slowly grown completely useless over the decades.
Why are HTML5/JS games so much laggier and buggier than Flash games?
Maybe it's not due to differences in the technologies used. I can imagine it's because less people make these games and spend less time per game to optimize it. Years ago there were thousands of flash games of each genre, a lot of them very well made, likely optimized for speed, pure works of art. Now I see the same 100 HTML5 games on all the sites, maybe reskinned a bit. I don't think we'll ever have in terms of quality as what was available on Kongregate or Armor Games.
I might download an old browser with Flash and some games. Years ago there was a collection of a few TB of Flash games, hope it's still around. Maybe some games that required network will not work, but most didn't.
Why are HTML5/JS games so much laggier and buggier than Flash games?
I’m not sure that’s actually the case.
Steve Jobs argued in his “thoughts on Flash” letter that Flash was too buggy, insecure and resource-hungry for mobile platforms. I worked on Chrome around that time and the Flash plugin was definitely one of the biggest sources of problems.
I think all the stuff you’re complaining about is to do with business models and not really anything to do with the technology. I reckon if Flash were still around we’d probably be in much the same place we are now. People would be complaining about restaurant menus being written in Flash instead of plain old HTML, etc etc.
I played Flash games 10-15 years ago on a 15 year old computer. I've tried HTML5 games on a 5 year old computer with a good CPU and lots of RAM, yet the experience doesn't compare at all. I doubt I'm looking through things with rose-colored glasses. I think I remember some games lagging, like if you'd spawned 1000s of enemies in a Tower Defense-type game, but that was very rare.
It's still likely that older games had more users so were optimized while newer games for Desktop don't have even 1% of that userbase since most people use a smartphone for simple games.
Out of curiosity, does anyone like the way Google Maps hijacks scrolling? I use a trackpad. When I scroll, I'd want it to pan around on the map, not zoom in and out (which always feels awful as a scroll action and never stops where I want it to).
Click-drag to pan doesn't feel nice.
It doesn't really matter anymore, since 99% of maps use is on mobile now, but this was always a small pain point to me in the past.
If you mean you prefer pinch/spread for zoom-out/in, I prefer the status quo with trackpad 2-finger scroll for zooming.
Pinching/spreading with index and middle finger feels unergonomic. Using my thumb on the trackpad would also feel unnatural, as would putting my 2 index fingers on the trackpad.
2 finger scroll is something you can "fling" such that the zooming motion continues even as your fingers have been lifted off the trackpad. Trying to "fling" a spread-out motion with your index and middle finger is an awkward motion, and of course in a pinching motion, your fingers would just crash into each other, so you'd have to lift before they crash. Pretty awkward.
On the phone, I often prefer tap then drag up/down (i.e. touch, lift, touch, slide) to zoom in/out with a single finger. It allows me to "fling" the zooming motion so it continues after I've lifted my finger. It makes a phone's interface behave like a trackpad's scrolling-zoom.
in my ideal world, the browser would ask to confirm "allow example.com to modify scroll behavior?" for all the potentially bad uses of javascript, like how current browsers ask you to allow microphone/multiple downloads/etc
Ludum Dare 59 just wrapped up last week, and both first and second place were won by developers using "Agentic" coding tools, something the community there is still discussing:
For what it's worth, the non-AI-coded entries were still quite good relative to the winners, so it's not so obvious that AI use confers an unbeatable advantage.
I did vibe code jam 59 entry with friends, the spirit of the rules there's a lot more lax. We didn't even get to top 100, but that's mostly due to gamedesign errors, not tech. This is the first entry in years which was vibecoded 100%, and I have very mixed feelings about it. It's no doubt anymore - 1.5x-2x speedup, which makes not using it (if allowed) a complete no-go. But psychologically it's tough losing control, and changing workflow to managerial one substantially, it diminishes the craft.
Bots are usually very stupid and will bail on any captcha system they don't recognize, so anything you make that's custom and requires javascript will cull 99% of them. This may change at some point with LLMs but for now my websites at least are still holding strong.
IMO a good approach is to update the UI immediately but still show some indication that the operation hasn't completed. So in a chat app, for example, add the message to the list of messages, but with contrast reduced slightly to indicate that other people can't see it yet.
reply