Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

unsuckjs.com

Post reply on HN
Print view View original

151–160 of 194 posts

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#151

Post by spankalee »

earthboundkid wrote: post #147
satvikpendem wrote: post #125

Earlier quoted context omitted.

Interesting, at the workplaces I've been at, we only used React, nothing else, in order to make the code-sharing problem much easier, as well as not have developers learning many different frameworks just to get work done.

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.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#152

Post by jen729w »

vegcel wrote: post #130
jen729w wrote: post #104

Earlier quoted context omitted.

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`?

Could you explain a bit what you do like/don't like about Gatsby compared to Astro?

Gatsby felt like it had grown in to a monster. Astro was a lot simpler which suits my needs and, frankly, skill.

I worry that Astro is adding too many features and trying to become Gatsby. No thanks!

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#153

Post by coreyp_1 »

michaelmrose wrote: post #135
coreyp_1 wrote: post #113

Earlier quoted context omitted.

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, a…

It's really weird that you describe requiring reciprocation as poisoning downstream. Proprietary software also doesn't allow you to just incorporate their code in your proprietary software and distribute it. Nobody described plain jane closed source software as "infectious" even though by any reasonable definition it is vastly more so. Open source software will let you remediate the situation by removing it or open s…

I'm not aware of any closed source software that supplies you with source code. (Although, in contract negotiations, it is common for source code to be held in escrow for large $$$ contracts, but that is for a different perpose entirely).

Also, suppose that you were to write something that interacted with the binaries of a closed-source system. That would not automatically remove the proprietary nature of your own software, so it is not infectious at all. You may not be able to distribute the proprietary software, but you could sell it as an add-on product without surrendering your IP. That's not ebola. That's a full quarantine and separation that respects the IP of individual owners.

GPL is particularly troublesome when it is a dependency of a dependency of a dependency of a dependency. You may not even know that you are using GPL code because the dependency that you are intending to use is not GPL. Again, the words "viral" and "infectious" are used because of this behavior... And this behavior was purposefully designed into the license as part of the political beliefs of the founders.

I'm not saying that GPL is useless, but rather that it is significant and potent enough that it is a single factor that will eliminate a project from consideration. Period. No if's, and's, or but's. So much so that I personally avoid GPL as much as possible in my own projects, and I distribute my projects as MIT.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#154

Post by coreyp_1 »

musicale wrote: post #117
coreyp_1 wrote: post #90

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…

> 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.

I work in a suprisingly innovative industry... tolling!

Seriously, there's some surprising work being done in the field, and software patents play a big part for companies that are very active in the space.

It's like the stock market. A lot of millionairs have money in stocks, but so, too, does the average Wal-Mart employee (at least it was an option when I was a cashier 20 years ago!). In other words, even small companies can gain a competative advantage with just a patent or two.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#155

Post by MatthiasPortzel »

satvikpendem wrote: post #30
password54321 wrote: post #22

Earlier quoted context omitted.

A fresh install of NextJS is roughly 150MB. You realise that's mostly code that all needs to work right?

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.

NextJS sends all JS to the frontend even if it's static and server rendered. It renders once on the server, sends a React+JS bundle to the client, and re-renders the whole page on the client (which is exactly the same). As far as I could tell, there's no mechanism for Next.JS to say "this isn't dynamic" and send only HTML content. If there's a setting I missed, feel free to let me know.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#156

Post by MatthiasPortzel »

coreyp_1 wrote: post #90
musicale wrote: post #80

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…

> if I choose GPL today, I have poisoned that code from myself for the rest of my life

If you're the copyright holder, the terms of the GPL don't apply to you. It's a license that you give to other people. You can't revoke the license, of course. But as long as you haven't accepted contributions from other people, you can "fork" your own project and take it closed-source.

(I agree with your analysis in general. Most people don't understand the restrictions placed by the GPL.)

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#157

Post by ximm »

jabart wrote: post #97
kitsunesoba wrote: post #25

Earlier quoted context omitted.

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things. Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get…

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

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#158

Post by coreyp_1 »

MatthiasPortzel wrote: post #156
coreyp_1 wrote: post #90

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…

> if I choose GPL today, I have poisoned that code from myself for the rest of my life If you're the copyright holder, the terms of the GPL don't apply to you. It's a license that you give to other people. You can't revoke the license, of course. But as long as you haven't accepted contributions from other people, you can "fork" your own project and take it closed-source. (I agree with your analysis in general. Most…

Yup! Thanks for pointing that out.

And that was my thought in general... I want to write projects that others want to contribute to, without painting myself into a corner.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#159

Post by a_subsystem »

sureglymop wrote: post #96
samwillis wrote: post #6

This is a brilliant list, I'm a particular fan of HTMX and Alpine.js. The move back towards small dependancy free JS libs, in combination with modern JS ES Modules, is absolutely brilliant. I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs…

If you use htmx what backend technology do you choose?

Bash, duh. https://twitter.com/htmx_org/status/1657378246336598018

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#160

Post by Zizizizz »

robertoandred wrote: post #106
Zizizizz wrote: post #102

Earlier quoted context omitted.

No it doesn't, for some of these at least you can render the page server side and the reactive components become reactive a bit later on, isn't that how next would work as well? It's a blend of server side and front end interactivity right?

You can’t render server side if you only use the library in a client-side script tag.

https://htmx.org so with this, the button will be there, but clicking on it might not do something until it's been fetched
Post reply on HN