Live data from Hacker News

UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

unsuckjs.com

161–170 of 194 posts

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#161
why isn't some kind of baseline state/reactivity/ajax built directly into html standards by now.

there are too many ways to do the same thing in webdev. it's so stressful.

each approach has its own trade-offs and edge cases you not might find until the eleventh hour..

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#162
post #136

Earlier quoted context omitted.

In that case you need to have everything rendered server side and perhaps get creative with the usage of forms firing off events that can be intercepted by the server and then return a new page. Certain things like Nav menu drop downs and folding text can’t be done with native CSS and HTML.

Hold my beer: that’s something you can do with the input checkbox trick. Here’s an example: https://codepen.io/daviddarnes/pen/abVaGG

You might also be able to use a element for the drop-down state.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#163

Earlier quoted context omitted.

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 so…

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

Unlawfully including GPL code in your proprietary product doesn't magically make your code GPL. It can't. In fact it has the EXACT SAME EFFECT as including proprietary code it means you are committing copyright infringement by distributing the combined work. The ability to get out of jail free by complying with the GPL and releasing the combined work under the GPL or just replacing the code you never had the right to distribute without further drama or penalty are extra privileges that you will never receive if you decide to distribute proprietary software. You are confusing additional benefits for penalties and pitfalls.

Once again you don't have to release your code as GPL you can simply rewrite the portion that you didn't have a right to distribute.

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

If you are responsible for a product knowing where the code comes from falls under the basic responsibilities of the job. Declaring in public that you own someone Elise's property because you couldn't be bothered to look is like catching a public indecency charge because you couldn't remember to wear pants that day. You put on pants and the problem goes away.

If you have followed any of the cases in which companies misused GPL code it looks metaphorically like someone following you around politely and repeatedly reminding you to cover your nudity whereas infringing on proprietary code looks more like a swat team showing and flinging flash bangs. If you are lucky if you don't end up getting shot.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#164

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.

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.

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

The new paradigm in Next.js is to have "server components" by default, which only render static HTML on the server side; and opt-in to "client components", which render on both server and client.

> With Server Components, the initial page load is faster, and the client-side JavaScript bundle size is reduced. The base client-side runtime is cacheable and predictable in size, and does not increase as your application grows. Additional JavaScript is only added as client-side interactivity is used in your application through Client Components.

https://nextjs.org/docs/getting-started/react-essentials#ser...

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#165

why isn't some kind of baseline state/reactivity/ajax built directly into html standards by now. there are too many ways to do the same thing in webdev. it's so stressful. each approach has its own trade-offs and edge cases you not might find until the eleventh hour..

If I understood correctly Lit tries to be that

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#166
post #81

Earlier quoted context omitted.

But I like the compiler.

For the sake of a compiler? I'd rather not add complexity for complexity's sake. Or does it give you another advantage not mentioned above?

Well, I like the idea of a compiler, that doesn't include "the framework" as a bundle required to run my code, but bundles up my code itself as being functional without "the framework".

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#168

Earlier quoted context omitted.

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 so…

> 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 r…

Again, it's quite difficult to get access to proprietary source code, so that is a false equivalence. I'm not confusing the benefits for penalties... I'm observing the emergent behavior that the GPL license produces by its viral and infectious rules. The strength of the legal threat has not been tested in court, to my knowledge, but why risk a lawsuit? And there is still the patent issue.

In terms of marketing, GPL sets itself up to be the paragon of the open source spirit and the model that all open source licenses should follow, but it has a HUGE gotcha based on its political persuasion. It proclaims freedom, but it is most decidedly not completely free, and requires parsing of sophisticated legalese to understand the nuances. Good luck if you are a beginner, non-native speaker, or have otherwise spent substantial brainpower trying to understand the do's and don'ts. It will bite you.

You may absolutely love GPL and everything that it stands for. That's fine with me. But I don't, and I advise everyone that I know of the dangers and repercussions of using GPL dependencies. You can say that those are features and virtues, and I can say that they are dangers and liabilities, but the bare facts are the same.

But, getting back to the reason for this post, when I want to compare software packages, the license is the first thing I look at, and if it's GPL, I bail on it immediately.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#169
post #65

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…

> 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 feature support among browsers

* transpiling to a common older version of JS

* add polyfills to implement missing features

* add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#170

Surprised to not see Qwik. It's probably more a framework than just a HTML enhancer, yet it fits very much in that philosophy of reducing JS to the very bare minimum

So does Astro, many others. These are frameworks with no build steps that can be included from a CDN, though.
Post reply on HN