I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?

They are like PDFs in that they do not render the same with different software or on different devices.

Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.

Yeah it’s strange that the project does not mention using redis, or even SQLite with a vector DB extension.

Just curious, why do you want to migrate from mongo (document database server) to sqlite (relational database library)?

That migration would be making two changes: document-based -> relational, and server -> library.

Have you considered migrating to Postgres instead? By using another DB server you won't need to change your application as much.

Thanks for the feedback. The document model in mongo was slopped together by a junior engineer, so perhaps an unorthodox approach. It is basically flat, and already used in a pseudo-relational manner via in-app join to the existing sqlite store. This blog post inspired me to think, what if we just chucked all the json from mongo into sqlite and used the generated indices? Then we can gradually "strangler fig" endpoint by endpoint

This sounds roughly on-track, but I agree with GP; Postgres would probably be better (also has great JSON(B) support).

I was with you until this part:

> Thus any attempt at estimates is as futile as gambling to win, tasks are only ever done when they're done, and "successful estimators" are kings of retconning.

> It's all make-believe.

Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them.

This argument proves too much:

"Bloodletting is not futile or make believe. It is useful even if the patient does not always survive. That's why physicians continue to use it."

"Trial by ordeal is not futile or make believe. It is useful even if sometimes Inquisitors reach mistaken conclusions. That's why Inquisitors continue to use it."

"Lottery-number-picking systems are not futile or make believe. They are useful even if some players never win. That's why players continue to use them."

It is a fully general argument which, if correct, would demonstrate that no practice that had continued for a period of time could ever be ineffective or counterproductive.

In my experience, they have negative usefulness in general.

I did work at one company that used an Agile/Scrum process, and though we didn't estimate actual time, we did estimate effort to complete tasks. That worked pretty well: we had an idea which tasks would be easy and which would be hard, and used that in sprint planning to more effectively use developer time.

But the key is no one was held to an estimate, since it was only that: an estimate. If something took 2x as long as predicted, oh well: we just adjusted our planning and worked around it, delaying other tasks for instance.

The problem I see is when managers demand an estimate, and then turn the estimate into a deadline and try to hold developers to that estimate no matter what.

The amount of tap dancing and philosophizing some developers are willing to do to dodge estimates is hilarious.

It’s a skill… a basic part and critical part of engineering. IME the common thread between objectors is that they haven’t made a consistent effort to improve — developing, iterating, and refining their estimation process over time.

Yeah, every line of code is a unique snowflake piece of undefinable research the universe has never seen, equally unknowable and inscrutably enigmatic. But the workers at EngiCorp building EngiCorp products using EngiCorp project routines and resources first, second, and third quarter of 2025 are literal world experts at EngiCorp outcomes. They very reasonably should be able to estimate EngiCorp work in Q4, and account for EngiCorp realities, providing maps of future costs that can drive EngiCorp process improvement and investment.

If I ask for a decking estimate and get back sophistry and smug incompetence, I’m not talking with a super skilled professional deck builder. Doesn’t matter how they hammer, saw, or draw.

> Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them.

The industry continues to fail when trying to use them. They have negative usefulness.

Does anyone know why the industry is killing OpenGL?

People wanted more direct control over the GPU and memory, instead of having the drivers do that hard work.

To fix this AMD developed Mantle in 2013. This inspired others: Apple released Metal in 2014, Microsoft released DX12 in 2015, and Khronos released Vulkan in 2016 based on Mantle. They're all kind of similar (some APIs better than others IMO).

OpenGL did get some extensions to improve it too but in the end all the big engines just use the other 3.

OpenGL cannot achieve the control over modern hardware necessary to get competitive performance. Even in terms of CPU overhead it’s very limiting.

Direct3D (and Mantle) had been offering lower level access for years, Vulkan was absolutely necessary.

It’s like assembly. Most of us don’t have to bother.

I just tested this on my computer.

  1. Make a new Xcode iOS project and delete all files except for Info.plist
  2. Remove all keys from Info.plist
  3. In the build settings search for "storyboard" and remove all keys
  4. Add yellow.asm to project
  5. Link UIKit, and Foundation

After all that you can build and run on a simulator

> so it's almost certain that private APIs would get accessed

No it's not. Just like with ObjC or Swift, in ASM you have to be explicit about the APIs you want to call. I don't see how you would accidentally call a private API in ASM.

IMO the bigger risk is attempting to call a method that does not actually exist. ObjC or Swift would protect you from that, but ASM would not and may just crash at runtime.

To me a handle implies that the object is somewhat sturdy. It’s okay to have it bump against other things and to set it on the floor.

nit: the pure HTML example is not the same as the other examples. It would make a POST request to the server with the data using a form encoding instead of a JSON encoding. It's not a given that your server supports this encoding!

One challenge is that JSON is for data and HTML is for UI. When a client gets JSON it can transform the data to make it ready for the UI. With HTML, the client is locked into the UI chosen by the server.

What if the client wants to render the output of an API in different ways depending on what screen is visible? If the server API outputs JSON, this is trivial. If it outputs HTML the client is stuck into rendering what the server gives it.

That's why GP mentioned the Accept header, the client can choose at runtime which one it wants.

i don't do frontend so apologies if it's a dumb question.

if html is for ui, what is css for?

i always thought html was for documents/data (like xml light)

Html is for structure, css for appearance. OP's point still applies

thanks!