Live data from Hacker News

Plain Vanilla Web

plainvanillaweb.com

581–590 of 715 posts

Re: Plain Vanilla Web

#581
post #520

Earlier quoted context omitted.

No, TLS should always be required. We should be moving away from plaintext anything on the wire, if for no other reason than privacy (but also for integrity, injecting scripts into an HTTP response is a nasty attack surface).

TLS shouldn't be required for as long as it remains a heavily centralized thing; to require it would give undue power to root certificate authorities.

Do you have an idea how this could be decentralized?

Re: Plain Vanilla Web

#582
post #340

Earlier quoted context omitted.

I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one? I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. There are so many way to do commerce both on and offline…

> I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. People romanticize businesses like this but there’s a reason you’re not posting the link. It only works when it’s for a small group of people who are in the know and refer trusted buyers. It’s also trivial to set up any…

> People romanticize businesses like this but there’s a reason you’re not posting the link.

What you're insinuating is true, but more likely the reason they didn't post the link is that it's not relevant.

Re: Plain Vanilla Web

#583

I've built a library to make vanilla webcomponents reactive via a manual render() call that updates only changed nodes: https://vorticode.github.io/solarite/ I was planning to improve performance more before announcing it. But even as is it beats React and approaches Lit.js on the JS framework benchmarks.

I've done something similar to this for my own internal applications, making use of snabbdom to handle the DOM updates. Snabbdom is tiny, robust, proven, and unopinionated; so I didn't see any particular need to reinvent that wheel.

Re: Plain Vanilla Web

#584

Once you're building custom components in JS files, aren't you basically writing your own microframework? Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's. Producing a framework with those features t…

Just checked what's there for libs implementing local state management + server-side sync in vanilla JS. The best options I found were `@tanstack/query-core`[1] and `@signaldb/core`[2].

The former packs no dependencies, with a total size of 89.18 kB if you were to put all the module JS code together, unminified, on a single file. Which could be even smaller with an optimising bundler that tree-shakes and minifies the build.

[1]: https://www.npmjs.com/package/@tanstack/query-core [2]: https://www.npmjs.com/package/@signaldb/core

Re: Plain Vanilla Web

#585
post #340

Earlier quoted context omitted.

I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one? I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. There are so many way to do commerce both on and offline…

> You can simply not pay if you choose not to. It's only a matter of time before this seller falls victim to a scammer - once they're found. I used to work for a book publisher who started doing their own e-commerce, and at the time one of the payment methods was a "pay later" one that predated the internet ("acceptgiro"). It only took a few months (if that) after the first sites went live that someone placed an orde…

In another post it was revealed that the owner passed away in 2023. While I'm as certain as you that there was some level of abuse, it doesn't seem to have been enough to make him change his ways.

Consider also that if you have a plumber, electrician, or some other tradesperson come to your house, you don't pay them until after they have done the work. You could choose not to pay them, but they have your address, and you'll never be able to do business with them again. On a small enough scale, this is all you need to prevent abuse.

Re: Plain Vanilla Web

#586
post #73

Earlier quoted context omitted.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

I love ClickOnce and am amazed that it never got that popular. Installs and updates are seamless.

I wrote an inventory management program for my father's hazardous waste company. Used .net mvc as the backend, WPF as the frontend. WPF sucks in many ways, but I got it working and have had zero complaints.

I built that program almost 20 years ago. Until last year I spend maybe 5-6 hours total in maintenance, mostly ssl cert updates. Let that sink in.

Re: Plain Vanilla Web

#587
Thank you! This is the resource I've been wanting to hand-feed web components to me.

Looking forward to playing around with some personal projects. :)

Re: Plain Vanilla Web

#588
post #73

Earlier quoted context omitted.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

I get the impression this is said by people who observe large enterprises or don't have good device management. I work for a big company that deploys proper MDM to our Macs and PCs, and as long as the application is packaged correctly, they sure can push stuff out fast and without user intervention, including killing a running process if they so choose. Making an app that packages well is also hard, but that's not on those who push them to environments.

Re: Plain Vanilla Web

#589
I know I am in the VAST minority, or perhaps the only one, but I cannot stand frameworks. Sure, there may be a lot of power in them, but there is also a lot of bloat and complexity. IMHO, this "power" can easily be achieved with libraries instead of an IOC framework. After you learn a, typically terse and confusing, framework language, you have to know that framework language along with the base language (Java, C#, JavaScript, Python, etc.) I feel like frameworks are only as popular as they are because product owners and managers like to tick-off the number of tools their developers use; makes them look important, knowledgeable, and efficient.

Re: Plain Vanilla Web

#590

Earlier quoted context omitted.

TLS shouldn't be required for as long as it remains a heavily centralized thing; to require it would give undue power to root certificate authorities.

Do you have an idea how this could be decentralized?

It would have to be some kind of web of trust thing. But no, I don't have any specific suggestions to that effect (which is why I believe that HTTP should remain an option).
Post reply on HN