7 ms·

I use this in one project but its bundle size is very large for what it does. I think Preact is usually a nicer option (and no, it doesn't require build tools a

• LudwigNagasena 4y ago
  What is wrong with build tools?
  • xigoi 4y ago
    More complexity and friction.
  • nisegami 4y ago
    I think it's more that these libraries are sometimes used in projects that aren't already using a build tool.
  • dgb23 4y ago
    The largest, most painful and apparent issue with JS related build tools is that they change and break. Frequently. And no, `package.lock` is not enough of a solution, because you will have to update dependencies at some point. Congrats, you now have multiple moving, breaking parts in your dependency tree that throw the weirdest and unrelated errors. So you're hunting down github issues, workarounds and patches, while still not really knowing what the problem was. The bonus here is that you need to remove these workarounds at some later point because your build tools and libraries have fixed the issues, so your code breaks again with very fun error messages or just straight up opaque and weird behaviors. At some point we have to ask why we're doing this to ourselves. It's not fun at all.
    • clncy 4y ago
      Agreed. Try inheriting a project that hasn’t been updated for a few years. Between the absolute dependency hell, and major breaking changes, there is huge temptation to just rewrite the whole thing. Even a basic application requires layers upon layers of dependencies. Many of them are not as mature as people like to think either.
    • wruza 4y ago
      they change and break. Frequently. Any notable examples? (apart from that “force everyone ESM overnight because we feel like” movement)
      • dgb23 4y ago
        I have encountered a mix of several weird bugs and breaking changes with gulp, webpack, rollup and what ever Nextjs uses. Also build related bugs with several popular libraries and the resulting versioning and dependency issues. NPM has disappointed me in similar ways at least a couple of times too. Babel is its own hell. Basically touching a JS project that hasn't been updated monthly is incredibly anxiety inducing. And now there are several new build tools since a relatively short while, which makes the issue even worse. They might be improvements in some dimensions but they all invent their own little world again, promising this or that. But it all sounds so familiar and I already lost trust.
      • lloydatkinson 4y ago
        I'm proud to say I recently published a library on npm and decided to specifically deliberately not publish anything other than ESM. Now bundle sizes are significantly smaller.
        • wruza 4y ago
          That’s the right thing to do. The issue that I mentioned included switching suddenly in highly depended-on packages without waiting for major end-user tools to catch up, splitting NPM across ESM for few months. It was a deliberate and non-systematic action. That’s why it’s worth ignoring it here.
  • lloydatkinson 4y ago
    Absolutely nothing and I advocate and push for them wherever possible. But I mentioned them for the usually very vocal crowd on HN (and others) that dominate any JS orientated conversation by pissing and crying that build tools exist. Apparently, to this crowd, the act of compiling code is perfectly OK everywhere else but a travesty to need or want to do any of that for software that runs in a browser. Weird.
    • yCombLinks 4y ago
      Build and dependency management is the worst part of the javascript ecosystem. Other languages do this much better. We're not against build tools for javascript. We're against bad ones. I'm only against adding a build tool when it's a small project that shouldn't require that complexity. I've seen projects where maintaining the build setup was more work than maintaining the code.
      • lloydatkinson 4y ago
        Yes, I've seen that too and it's a testament to how bad the ecosystem is. However, the kinds of problems that existed in 2015 thanks to detracting tools like WebPack and Babel don't really exist now with the fact that browsers support ES modules and Node is dragging its heels but now mostly supports ES modules. With things like typescript and vite I now never have the problems that used to be common. In fact when I see people creating brand new projects in 2023 using WebPack I cry a little in side. At some point having a bad tooling experience can't be solely blamed on the tools. It's a choice.
• aliswe 4y ago
  Preact 3KB?
  • fredrikholm 4y ago
    That's what they claim. https://github.com/preactjs/preact https://github.com/preactjs/preact
    • lloydatkinson 4y ago
      Yes, it really is.
• abdusco 4y ago
  Can you use Preact to build on server-rendered HTML?
  • dgb23 4y ago
    https://preactjs.com/guide/v10/server-side-rendering/ https://preactjs.com/guide/v10/server-side-rendering/
  • stepbeek 4y ago
    I have. We used stimulusjs otherwise and wrote a controller that took in a component name and JSON props (embedded in HTML as a data attribute). It works well. You end up with HTML like: <div data-controller=“component” data-name-component-value”example” data-props-component-value=“{a: 1}”></div>
• iambateman 4y ago
  I’m all about minimizing bundle size but if your project is at the point of optimizing for 10kb, I’m pretty sure you’re working on the Mars Rover. ;)
  • dx034 4y ago
    Or for people with bad connections. If you expect high latency it can be worth it to embed js code to avoid the additoinal roundtrip. 10kb makes a big difference for that.
    • wruza 4y ago
      Which sites do that for any meaningful reason? I see this argument often, but have a hard time either coming up with an idea of a business for which it would be non-marginally profitable or finding a real app/site which does that to cover the last mile of its world-wide scale. Until that I believe this argument is equivalent to “what about Mars”. By supporting dead slow connections on Earth you simply support them to remain so.
      • reflectiv 4y ago
        > Which sites do that for any meaningful reason? Literally none...this is just the argument of contrarians or people who've only ever worked on personal projects who take offense to real applications used by actual audiences.
      • dx034 4y ago
        In itself 10kb doesn’t make a difference. But it adds up so that this mindset can lead to noticeably faster pages.
    • lelandfe 4y ago
      As someone who has shipped thriftily-sized sites targeting developing countries, what you're describing is a needlessly extreme optimization. Inlining 3kb of data vs. 13kb would be a nearly unnoticeable difference for even the worst connections – like in Guinea, whose median download speed is around 3mbps. Inflating the document size does impact paint time, but it scarcely matters here.
• imacrayon 4y ago
  Chances are you’ll end up writing more than 10kb of custom JS to make your components work. Alpine comes with basic batteries already included.
• culi 4y ago
  react itself is only 2.5kb https://bundlephobia.com/package/react@18.2.0 https://bundlephobia.com/package/react@18.2.0
  • rk06 4y ago
    You can't use react for web without react dom (42kb) https://bundlephobia.com/package/react-dom@18.2.0 https://bundlephobia.com/package/react-dom@18.2.0