One time I found some #JavaScript in an app that was constructing a full blown SELECT statement in SQL, sending it to the server, and then blindly executed on that server.
It is still the most glorious, beautiful code I've ever seen.
@cspray I did that once for a project as a joke (against a read-only SQL API) and found it was actually a really neat way to rapidly iterate on my project!
You can view source on https://sf-trees.com to see a demo of the pattern I built
@baumannzone This has to do with how floating point numbers are stored (essentially, they’re fractions, not decimals). This occurs in most programming languages, not just JS. Look up “floating point rounding error”
Diving back into a project that used Vue and it seems to be throwing an error when I add a data- attribute to a HTML element. It's a static string which I use for something else.
Spent a bit of time early this morning to knock out the most basic vector editing features in my SCI0 pic editor. The SCI0 pic byte-code is very terse; it doesn't even have closed polygons, just lines that happen to touch each other when rendered to the frame-buffer.
I'm sure this whole UI layer will need a refactor soon, but its definitely another step in a "useful" direction. Just a few core features left before a "beta" is viable.
@javedAB Other ways to achieve it include removing Javascript altogether and replacing it by server-side scripting, as well as serving most if not all of your sources over a fast CDN.
@aeveltstra server side rending is a valid approach. i started with @astro and @solid_js . however, from what i guess, server side rendering is more cost intensive than static html
Here's a very-niche but then-very-useful #javascript trick I realized today -- you can create empty text-nodes to use as node references, for things like DOM insertion, range boundaries, or whatever.
I needed this to set the end of a range immediately before an element's closing tag, when references to existing child nodes might be invalidated by race conditions.
You don't even need to persist the references for removal, since a single call to context.normalize() cleans them all away.
@ollicle Oh you were asking about dealing with sibling text nodes? Yeah, that :-) Normalizing isn't something you tend to need very often, but it's uniquely useful when you do.
That's a good point about spotting in dev tools, I guess it would depend on what you needed. If the nodes need to be around for a while, it would be more useful to be able to inspect them. My use-case is very transient, they're added and gone again in the space of a synchronous function call.