181–190 of 194 posts
Earlier quoted context omitted.
It sucks so much its unreal, forces OOP JS, which causes extreme amounts of boiler plate code and mutation bugs, making a simple change becomes a one week task. I'm just doing a complete rewrite of a legacy codebase made with TS, webcomponents and lit into a modern framework, which is about the only sane thing to do with it.
I would love to see a more fleshed out rebuttal of it. Is it a scale issue?
Earlier quoted context omitted.
Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!
If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives
Earlier quoted context omitted.
> Having a build step also increases activation energy and friction Yes this! As an interpreted language it should not need a build step. Every project should be git clone https://github.com/user/foo && cd foo && google-chrome index.html
I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points: * slow network, especially on mobile * reduce the size of the download by minifying * reduce the number of calls by bundling files in a single one * Inconsistent JS and HTML…
Earlier quoted context omitted.
Why not?
It sucks so much its unreal, forces OOP JS, which causes extreme amounts of boiler plate code and mutation bugs, making a simple change becomes a one week task. I'm just doing a complete rewrite of a legacy codebase made with TS, webcomponents and lit into a modern framework, which is about the only sane thing to do with it.
In react, mutating a model is a bug. It's left up to the developer to remember not to do that. Outside of react, mutating a model seems like a natural fit for the way stuff actually works and it's not considered a bug.
Earlier quoted context omitted.
But wouldn’t you be happier if each and every component on the page paid the price of a full templating system? No? Oh yeah, I forgot that Web Components are a terrible idea that are only marginally successful because they can claim to be a “standard” when they’re not any more standard than any other JavaScript.
I honestly don't know how WCs got through the standards process successfully, they're so bad.
Earlier quoted context omitted.
But wouldn’t you be happier if each and every component on the page paid the price of a full templating system? No? Oh yeah, I forgot that Web Components are a terrible idea that are only marginally successful because they can claim to be a “standard” when they’re not any more standard than any other JavaScript.
You only "pay" for as many template systems as you use, not one for every component, and modern template systems are far smaller than the major frameworks.
Earlier quoted context omitted.
Yes! I don't think Mithril gets enough attention. It's my go to JS framework when I need more than Vanilla JS but don't need something like React.
Did you ever run into performance problem with Mithril? I like how simple it is to use but the idea to run / diff the entire component tree on every user interaction kinda scares me
Earlier quoted context omitted.
If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives
I'll never understand CSP not allowing onclick handlers. Having all your javascript in a separate file makes it very hard to diagnose and understand what is causing the event on the element.
I wonder if there were a better way to opt-in to "use strict" (and maybe even ESM friendliness) in onclick handlers if that would have fewer CSP concerns. I doubt there are any current proposals to build such tools for HTML, though.
It would be handy to see the license. It's becoming increasingly more dangerous to use anything in the GPL family for anything but the narrowest of use cases. It's to the point that, even now, if it's GPL I refuse to incorporate it, even in personal projects. And I'm not against open source... Everything I write is MIT.