191–200 of 206 posts
Earlier quoted context omitted.
As a React developer I have the strictest policy to never go lower level than the browser and I never touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.
Damn, you must be the one scooping up all those 10+ years React experience jobs :)
Earlier quoted context omitted.
Not nearly as minimal as your example, but I like the "no build tools route" of using preact. You don't need to build your code, and you can get JSX-esque syntax and some of the niceness of React without messing with npm or webpack or any of that. https://preactjs.com/guide/v10/getting-started#no-build-tool...
I am failing to understand why someone would choose this over React. The page you linked to, I kid you not, has a section about how you build a Preact application from the command line...
Earlier quoted context omitted.
querySelectorAll is a lot slower than old school functions. You would be tempted to say who cares, but then you load Gmail and wait 2 seconds for UI to render.
https://www.sitepoint.com/optimizing-css-id-selectors-and-ot... The slowest and most convoluted selector took 21ms when tested against 50,000 elements using a 2014 MacBook Pro.
Earlier quoted context omitted.
querySelectorAll is a lot slower than old school functions. You would be tempted to say who cares, but then you load Gmail and wait 2 seconds for UI to render.
Do you have any references for this? I would be flabbergasted if the simple case of #id and .class weren't optimized to be basically identical. (the only difference being that they had to do a quick "parse" before jumping into the optimized path)
tldr just looking for class x10 slower.
Earlier quoted context omitted.
Using innerHTML as default if the second argument isn't an object risks XSS vulnerabilities. I'd prefer innerText for as default.
What XSS vulnerability? Any user can set the innerHTML of any element at any time.
Dynamically setting text is very common. While dynamically setting innerHTML is a rare and dangerous operation which should be explicit in the code. The alternative syntax also supported by this function $element("span", { innerHTML: html }) is much better.
Earlier quoted context omitted.
Do you have any references for this? I would be flabbergasted if the simple case of #id and .class weren't optimized to be basically identical. (the only difference being that they had to do a quick "parse" before jumping into the optimized path)
https://jsperf.com/getelementbyid-vs-queryselector/25 tldr just looking for class x10 slower.
Earlier quoted context omitted.
> What XSS vulnerability? Any user can set the innerHTML of any element at any time. This mindset right here is exactly why XSS is still an issue. If you pull user generated content and put it in the DOM like this, you will open your users to XSS from other users. Basing your personal use DOM APIs on setting `el.innerHTML` will lead to a slip-up. Use `textContent` by default.
Often times you write code to defend against other developers who don't know any better.
Earlier quoted context omitted.
Using tagged template literals the way lit-html does is the nicest JSX-substitute I’ve seen: https://github.com/Polymer/lit-html
The downside there is you’re heavily relying on strings, which feels a bit weird for things like event handlers, which would either have to inline the function as a string or do some magic behind the scenes. The editor is also going to be less helpful in figuring out your intent when using a string-only templating system.
For event handlers, only the event name is in the string. The handler function is passed directly in and we add it to elements with addEventListener().
The only "magic" is that we wrap the user's handler call it with the host component as the `this` value so that you don't have to create closures like in Reach. You can just do:
class MyElement extends LitElement {
render() {
return html`Click Ma
}
_onClick(e) {
console.log('this is', this);
}
}Earlier quoted context omitted.
Using tagged template literals the way lit-html does is the nicest JSX-substitute I’ve seen: https://github.com/Polymer/lit-html
It's pretty nice but doesn't play so nicely with editor indenting modes and stuff like that, so there are some reasons to use normal JavaScript function calls instead.