Earlier quoted context omitted.
You can get small sizes, great DX, first-class TypeScript support, all without the compiler though.
But I like the compiler.
UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
81–90 of 194 posts
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#82Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#83Earlier quoted context omitted.
Why would you ever need React over Mithril?
The ecosystem, if you're building a product of a certain complexity and can't afford writing large, complex, un-battle-tested views from scratch.
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#84Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#85Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#86Awesome list! I love that the cognitive overhead for web apps now is so great many people are "returning to monke" and coding in simple HTML/CSS/JS haha. Question: Shouldn't the items be in the row so I can see all of them at once? Why are the items in the columns? I'll open a issue (:
None of these are simple HTML/CSS/JS.
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#87Earlier 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
In most cases, your bottleneck won't be Mithril (or React for that matter), but instead what expensive computations you're doing in your components. While React has React.memo, Mithril has the `onbeforeupdate` hook [2] you can use to memoize components if you need it.
[1] https://carlmungazi.github.io/sourcecodeadventures/posts/pat... [2] https://mithril.js.org/lifecycle-methods.html#avoid-prematur...
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#88yeah, it's bigger than most of the other libraries, but it does an absolutely excellent job on progressive enhancement
source: i'm the creator of htmx
edit: PR here: https://github.com/adamghill/unsuckjs.com/pull/13
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#89There should be another row that which of these can be included as a standalone javascript lib in html instead of requiring NPM.
Not requiring NPM was one of my original requirements for anything on this list. All of these libraries should be available from HTML directly -- let me know or make a PR if that isn't the case.
Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries
#90It 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.
What changed to make GPL more "dangerous" - and to whom? I was under the impression that nearly every Linux distro uses GPL code in the kernel and/or userland.
The GPL carves out exceptions for the use of system libraries.
But, as for the "dangerous" part:
* I work in an industry in which software patents are required to survive. Personally, I hate software patents, but it is a reality until the law changes. As such, the GPL invalidates patents, making anything GPL completely off limits. That means that I would not have a job, and then there would be fewer competitors in the marketplace, which would make prices rise considerably. Too bad, too, because we would donate back improvements that are general enough to benefit others. Rather, now we just use proprietary solutions wholly because GPL is a minefield for us.
* I have personal projects. I write code that I want to use myself as well as allow others to use. I use MIT because GPL discourages that somewhat (the point above). I may want to use my personal projects commercially some day. MIT allows that; GPL makes it impossible. In other words, if I choose GPL today, I have poisoned that code from myself for the rest of my life.
In short GPL is not "free" as in freedom, because it comes with strings attached. It's communist in philosophy, but I hesitate to say that because then everybody jumps to some *a priori* conclusion of what they are now convinced that I'm saying, without listening to what I'm actually saying.
GPL says, in short, that the software is freely available for public use, but not for private use. (Yes, there are nuances to that, so much so (and so confusing) that most people either just ignore it, or say "IANAL...") It demands that 100% of the work of anyone in the future must be donated back to the collective for free. That is not freedom.
Create as much GPL code as you like. I create MIT. You can use mine (and I'm happy for you to!), but I can't use yours because of the restrictions you put on it. We can let the future decide which is more "free".