Please tell me I'm not the only one who gets really annoyed when someone uses jQuery to do stuff that would take the same amount of pure JS. I think these days many people only use jQuery out of laziness, not because it's necessary. Why load an entire library to set CSS attributes and innerHTML? Yes, there was a time when it was very useful to have jQuery, but today we have querySelectorAll and all that. You can save plenty of kBs, load time and improve performance.

Next time you're about to load jQuery ask yourself: do I really need it? Chances are the answer will be no.

A php site delivering javascript in json
Which is executed by eval
{ jsaction :"document.getElementById('id').innerHtml = 'hello world' ; document.getElementById('id').style. Color='red' " }

My worst sin is deleting elements with .innerHTML=“”;

When you find you should use `$("#id").html(response)` instead of `$("#id").innerHTML = response` and it works just fine out of a sudden.

So, how was your day?

Instead of .innerHTML writing .html and wondering what is wrong for an hour...

This Vue project I took over uses document.getElementById(...).innerHTML = stuff in its async created method.

That's the rant.

(long post is long)
This one is for the .net folks. After evaluating the technology top to bottom and even reimplementing several examples I commonly use for smoke testing new technology, I'm just going to call it:

Blazor is the next Silverlight.

It's just beyond the pale in terms of being architecturally flawed, and yet they're rushing it out as hard as possible to coincide with the .Net 5 rebranding silo extravaganza. We are officially entering round 3 of "sacrifice .Net on the altar of enterprise comfort." Get excited.

Since we've arrived here, I can only assume the Asp.net Ajax fiasco is far enough in the past that a new generation of devs doesn't recall its inherent catastrophic weaknesses. The architecture was this:

1. Create a component as a "WebUserControl"
2. Any time a bound DOM operation occurs from user interaction, send a payload back to the server
3. The server runs the code to process the event; it spits back more HTML

Some client-side js then dutifully updates the UI by unceremoniously stuffing the markup into an element's innerHTML property like so much sausage.

If you understand that, you've adequately understood how Blazor works. There's some optimization like signalR WebSockets for update streaming (the first and only time most blazor devs will ever use WebSockets, I even see developers claiming that they're "using SignalR, Idserver4, gRPC, etc." because the template seeds it for them. The hubris.), but that's the gist. The astute viewer will have noticed a few things here, including the disconnect between repaints, inability to blend update operations and transitions, and the potential for absolutely obliterative, connection-volatile, abusive transactional logic flying back and forth to the server. It's the bring out your dead approach to seeing how much of your IT budget is dedicated to paying for bandwidth and CPU time.

Blazor goes a step further in the server-side render scenario and sends every DOM event it binds to the server for processing. These include millisecond-scale events like scroll, which, at least according to GitHub issues, devs are quickly realizing requires debouncing, though they aren't quite sure how to accomplish that. Since this immediately becomes an issue with tickets saying things like, "scroll event crater server, Ugg need help! You said Blazorclub good. Ugg believe, Ugg wants reparations!" the team chooses a great answer to many problems for the wrong reasons:

gRPC

For those who aren't familiar, gRPC has a substantial amount of compression primarily courtesy of a rather excellent binary format developed by Google. Who needs the Quickie Mart, or indeed a sound markup delivery and view strategy when you can compress the shit out of the payload and ignore the problem. (Shhh, I hear you back there, no spoilers. What will happen when even that compression ceases to cut it, indeed). One might look at all this inductive-reasoning-as-development and ask themselves, "butwai?!" The reason is that the server-side story is just a way to buy time to flesh out the even more fundamentally broken browser-side story. To explain that, we need a little perspective.

The relationship between Microsoft and it's enterprise customers is your typical mutually abusive co-dependent relationship. Microsoft goes through phases of tacit disinterest, where it virtually ignores them. And rightly so, the enterprise customers tend to be weaksauce, mono-platform, mono-language types who come to work, collect a paycheck, and go home. They want to suckle on the teat of the vendor that enables them to get a plug and play experience for delivering their internal systems.

And that's fine. But it's also dull; it's the spouse that lets themselves go, it's the girlfriend in the distracted boyfriend meme. Those aren't the people who keep your platform relevant and competitive. For Microsoft, that crowd has always been the exploratory end of the developer community: alt.net, and more recently, the dotnet core community (StackOverflow 2020's most loved platform, for the haters). Alt.net seeded every competitive advantage the dotnet ecosystem has, and dotnet core capitalized on. Like DI? You're welcome. Are you enjoying MVC? Your gratitude is understood. Cool serializers, gRPC/protobuff, 1st class APIs, metadata-driven clients, code generation, micro ORMs, etc., etc., et al. Dear enterpriseur, you are fucking welcome.

Anyways, b2blazor. So, the front end (Blazor WebAssembly) story begins with the average enterprise FOMO. When enterprises get FOMO, they start to Karen/Kevin super hard, slinging around money, privilege, premiere support tickets, etc. until Microsoft, the distracted boyfriend, eventually turns back and says, "sorry babe, wut was that?" You know, shit like managers unironically looking at cloud reps and demanding to know if "you can handle our load!" Meanwhile, any actual engineer hides under the table facepalming and trying not to die from embarrassment.

today i learned that adding to innerhtml using a loop is so much slower than adding to a variable and writing it once.

sometimes i wonder if i were happier as a professional programmer. and then i experience this which means my family would be living under a bridge in no time.

I encountered a really weird bug today in my javascript. I'm working on a CMS and one of the things it handles is adding, uploading and resizing images. So, one function adds an empty image to the dom, unselects the currently selected image and selects the new empty image. Pretty straighforward right? So the problem is the unselect function didn't want to work. The image is added and gets selected but the previous image is also still selected.

I set a few breakpoints checked every variable but everything was the way it should. So after an hour trying things I discovered that if I removed the code where the image get added to the body the deselect function works (innerHTML += element) I thought maybe a little timout between these two actions would work but it didn't work. It looks like all dom actions lock up after the empty image gets added. I didn't understood so I moved the unselect function to the above the image add code and it worked wut ??.

code before fix:
func:
body.innerHTML += html;
unselect();
select();

after:
func:
unselect();
body.innerHTML += html;
select();

Atleast its fixed now

Another hours wasted on debugging, on what I hate most about programming: strings!

Don't get me started on C-strings, this abomination from hell. Inefficient, error prone. Memory corruption through off by one errors, BSOD by out of bound access, seen it all. No, it's strings in general. Just untyped junk of data, undocumented formats. Everything has to be parsed back and forth. And this is not limited to our stupid stupid code base, as I read about the security issues of using innerHTML or having to fight CMake again.

So back to the issue this rant is about. CMake like other scripting languages as bash have their peculiarities when dealing with the enemy (i.e. strings), e.g. all the escaping. The thing I fought against was getting CMake's fixup_bundle work on macOS. It was a bit pesky to debug. But in the end it turned out that my file path had one "//" instead of an "/" and the path comparison just did a string comparison without path normalization.

Stop giving us enough string to hang ourselves!

JS: adding new dom nodes by adding html markup to the innerHTML property as string...
It's either dumb or a genius move.

I ve made 9 pug templates for 8 responsive pages and use ssr to render all pages' innerHTML content configured & controlled by a remote configure center during this week. Totally worn out.