rellekio's comments

My concern is the difficulty of tracking down sources years later without a means of reference. Unless you are actively archiving and organizing those links in a useful way. What we have is more prone to forgetfulness, but also at the time that is our strength. Still a pain though

Something about opinions being treated as facts is part of a post truth society. I don't like what you said, therefore is false. It's a trend that to me is worse than death when it comes to discourse.

Democratic nation with a strong Oligarchy. Who over years forged q corpocracy that obfuscate such via citizens united. The basis in which we operate is democratic, but popular public policies are rarely enacted.

As to why you put too much emphasis on violence. Think of labor the united states has thanks to corporal punishment. Why waste labor?

In the end it doesn't matter too much as even the beginnings of a GAI would derail such a system. Think on the idiocy at the capital the other day and the post truth aspect that spurred it on.

The most difficult aspect of this is it is hard to compete against free.

Only critique is you need to allow for the brushes to be bigger. Specifically for the move tool as that is how I was taught to vreate primary forms before going in with any brushes.

That or having a good idea that isn't just marketing. No matter what organization your in there is internal marketing and external in terms of what we produce. I say that as sometimes despite what we advertise as ground breaking is just a web form plugged into a dockerfile.

It's more of a question of work and why we do so. Most are left burn out at the end of their week.

After all it's a job, because someone has to pay you to do it.

Programming is just the process of abstraction and automation of work. At what point does it end?

Data Oriented Programmming is both old and new. In that it does not have the same amount of programming patterns that OOP has. As it is a more bare metal means of programming without a ton of abstraction to ease most programmers into it.

Where I find the idea interesting is concurrent and parallel processes are more natural in the data oriented. And that is through immutablility and ownership as first principles.

I personally love TypeScript, but I do have one big hang up. Janky builds in testing. Can't explain it, but sometimes the guarantees TS is supposed to provide don't compile over. Mainly while using nodemon or another auto compile. Have only ran into it a couple times, but it mainly crops up during module linking.

Also keep in mind you can use as modules via require('') and skip adding types to a js lib. Be sure to add --module commonjs or the equivalent in config.

Why I like TypeScript for myself is writing modules and api's. Mainly: inline documentation. And the pursuit of more of a deterministic outcome in your programs. Still the linking issue bothers me.

But most complaints I hear on the topic is the same criticism of js in general. So much rope you can hang yourself with.

However if we are talking about speed. I do agree. But that is because to me it is madness to have these frameworks sitting on the main thread. And should be concurrently offloaded to a worker. Reactor's concurrent mode is also a great stab at this problem. Howver I believe the point is missed.

Being the only bindings a framework should have on the main thread is it's interactions with the dom. Everything else, including the virtual dom should be on a different thread.

So while I understand the push back, I believe people are missing the point. These frameworks have been implemented in the easiest fashion and have matured. But now that we can rely on multiple cores and ht. There should be a response.

Not to mention Web Apps vs Web Sites. We need to make that distinction, especially in line with wasm now being matured.

Edit: As for serverside rendering. If your backend engineer can't figure out how to cache this. I question the hire.

Call me a blending edge buff, but once WebGPU rolls out you can blur the distinction of web site and native program. But I would not utilize such on statically rendered website. But I would use it on a portable version of Photoshop, Blender, AutoCAD, or Minecraft.

Can you do the above today, inefficiently yes. But once WebGPU (gpu multi processing via a compute shaders with shared instructions) hits in combination with WebAssembley Workers (shared instruction cpu processing with proper floats across X cores) it will be an entirely different story.

What is insane to me is that these UI frameworks run in combination with the DOM on the main thread. That they are not designed from the ground up to run SSR and it is an afterthought.

Or in the instance of third world can even be managed by a Service Worker that drip feeds updates and presents th em on the site they are on next time they visit.

1 million and one ways to skin a cat. No way is better, it depends on the client's budget and use case.

Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up.

If your client's needs are to just display a static and do not dynamic updates from the server then ignoring the SPA approach is very wise.

Client side navigation handled poorly is just that handled poorly. And should be handled by the Senior Developer and not the Junior. As SPA is just another tool for a specific use case.

It's about something new versus what we have tried to this point.