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.
Plain Vanilla Web
581–590 of 715 posts
Re: Plain Vanilla Web
#582Earlier 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…
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
#583I'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.
Re: Plain Vanilla Web
#584Once 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…
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
#585Earlier 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…
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
#586Earlier 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 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
#587Looking forward to playing around with some personal projects. :)
Re: Plain Vanilla Web
#588Earlier 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…
Re: Plain Vanilla Web
#589Re: Plain Vanilla Web
#590Earlier 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?