Live data from Hacker News

UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

unsuckjs.com

111–120 of 194 posts

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#111
post #54

Earlier quoted context omitted.

In that case why not just SSR lit on the backend and send that? It sounds like an unfair criticism otherwise

It's easy to add interactivity to a NextJS site when you need it.

Likewise with Lit, but that is besides the criticism that he was making earlier

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#112
post #48

I'd love to see a list of heavily interactive sites that use the HTMX technique. I believe Github uses something like HTMX + ActionCable, and it shows how good that experience can be (and some limitations). But I think it's in the small minority. It'd be nice to know of more examples, instead of just more libs.

I haven't studied the guts of it, but I've been impressed recently with Github. It feels like a normal, page-by-page application, with human-readable URLs, and none of the usual SPA shenanigans as far as after-page loading, infinite-scroll nonsense, or broken back button behaviour... but then stuff happens like a page that's sitting open on a PR automatically pulls new comments as they are posted, and it looks identi…

I very much agree. GitHub is always a source of inspiration for me design-wise

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#113

Earlier quoted context omitted.

https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryEx... 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…

IIRC, it's not about private use but about distribution. We publish libraries under MIT, since other corporate users would very likely need to distribute those. But the higher-level Apps we publish under GPL, so that downstream is obligated to keep it open-source (but there is no obligation to submit a PR upstream). And there are more than a few companies that use our GPL stuff, internally and don't redistrubute and…

Yes, distribution is the key.

Suppose that my company has powerful video editing software that we sell (which is distribution). Consider that it has unique functionality and has taken a decade to develop by a team of developers, all of whom have salaries, insurance, retirement, etc. that need to be paid, otherwise the software would not exist. Proprietary code and profit are more than appropriate in this situation, as I believe that workers should reap the reward of their labor and investment.

Now, suppose that a new feature is wanted. There is a project that provides that functionality, but it is licensed GPL. Can I use it?

Absolutely not!

Because, if I do, then I am obligated to release all of my source code in addition, because it integrates with the GPL code. It is financial suicide for my business to do so (which, btw, is a political preference for many of the GPL proponents). What will I do instead? I will probably just have my developer write our own version, adding in the extra features that we need.

Contrast that with the MIT-licensed code. We can use it without fear, and we will probably even submit enhancements back to the project, simply because it makes our lives easier in the future for maintenance.

GPL poisons downstream, simple as that.

You are correct that there is no obligation to submit a PR upstream, but there is a requirement for my source code to be made available under the same GPL license. GPL is "infectious" (or "viral", take your pick of words).

The funny thing is, I believe in freedom with software, but my interpretation of "free" is vastly different than the GPL interpretation of "free". And, as I said, I put my money where my mouth is... almost everything I write (except for my job) is MIT licensed code.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#115

Earlier quoted context omitted.

Astro is pretty nice too, I was going to write my blog with it but I liked the instant page transitions that NextJS provides out of the box for which I couldn't find a suitable solution in Astro.

Doesn’t NextJS do that with client-side JS though? I recently moved from Gatsby, which did that — and the transitions sure are instantaneous — to Astro, which outputs plain HTML pages. Each navigation is a request to the server. Yeah, they take a touch longer. But the response is tiny. You could always `preload`?

I tried preload, it doesn't work as well as with NextJS which, yes, uses client side JS. But critically, the pages still work without JS if one so chooses. It's progressive enhancement which Astro does not yet have.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#116
post #54

Earlier quoted context omitted.

That's all on the backend so it doesn't really matter to me as long as no JS is sent on the frontend. For the benefits NextJS gives me, like TypeScript, I'm fine with that.

In that case why not just SSR lit on the backend and send that? It sounds like an unfair criticism otherwise

I have the full React framework and ecosystem if I so choose to use it. For example, I could use something like react-three-fiber to add 3D or Framer Motion to add animations yet fall back to not having those when JS is disabled. Sure you could do the same in Lit but those libraries aren't present or as robust as in React.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#117

Earlier quoted context omitted.

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.

https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryEx... 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…

> I work in an industry in which software patents are required to survive

Thanks for the explanation! I wonder what the industry is (maybe finance or law or ??) It seems that in most of the tech industry software patents are primarily used as a war chest for large companies or for non-practicing entities focused on litigation. Usually execution is more important.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#118
post #97

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!

Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style

Or, tailwindcss…

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#119

Earlier quoted context omitted.

If you use htmx what backend technology do you choose?

The beauty of htmx is that it doesn't matter what you use on the backend. Literally anything that'll render HTML will suffice. Even static HTML files on a web server will do. No need for an application server at all if you're clever and your needs are simple.

What if I want the website to work even when JavaScript is not turned on? I'd need a backend server and some frontend logic handling that case.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#120

I can do the same thing via NextJS and output pure HTML and CSS without any JS at all. Or with server components, output only the minimal JS needed. Not sure why everyone wants to write a programming language inside HTML like lit does.

You can use lit components within Next, or within anything really. If you’re building a single app, use what you’re comfortable with. At my job, we’re often creating components that need to be used within an increasing number of frameworks because every client is using something different. Having a custom element instead of needing to load React on every client’s website is huge.
Post reply on HN