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

You are correct that I was a worried about an HN hug of orders for brass tacks.

> I guess I’ve spent enough time dealing with things like non-payment or doing work for trades that never arrive that I just don’t romanticize this stuff any more.

In this case there isn't much of a choice. When the last manufacture of brass tacks closed down, John bought the machinery and is the only place I know of to get proper shaker-style brass tacks in the US. I wanted the tacks, so I had no choice in the method of payment.

I understand your sentiment but it was perfectly normal to pump gas before paying in the U.S. for a very long time and still is in many places. In other cities it is unheard of. Restaurants we can still eat before paying, but not many other places still give consumers much trust.

This type of business works in the small - when you know your suppliers and your customers. It doesn't work if you have 10,000 customers, or if anyone can email you. For this business it's only a spam problem, though - they have to reject emails from strangers if they get a high volume, exactly the same way they have to reject emails selling Viagra.

That's probably alien to HN and a lot of them may try to contact him, as if they have a possibility of becoming his customer, which they don't.

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

also kinda common in germany. Used to be much more common, but you still see it, especially in b2b, even for high value items

> How does the woodworking company ensure payment? Does the specialized nature ensure only "real" customers buy?

Yes, I believe it does. These are highly specific brass tacks for making oval shaker boxes. There are very few manufactures of a proper #2 brass tack these days, so I would very much want to stay on the good side and any suppliers.

I think they said in their faq that twice they haven't been paid in 20 years or something like that. Their online "store" appears to be down right now–hopefully they are still in business.

edit: It appears John passed in 2023 :( https://blog.lostartpress.com/2023/02/07/john-wilson-1939-20...

They have your address and it would be illegal not to pay. But also if the products have little to no resale value, are good quality and replaced relatively frequently, then such a company is worth its weight in gold. Even if you "get away with it" you can obviously never do business with them again.

Not sure about the US, but in my country that's how mail order used to work for decades, and it's still pretty common to offer that payment option, though usually with some restrictions (e.g. not for your first order).

Most people are not scammers and will pay simply because it's the right thing to do.If your margins are decent, you can just eat the loss to some scammers as the cost of doing business. Especially if there's no real resale market for your product.

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.

Unfortunately, fraud is a part of business. During my time at Intuit, Apple, and Shopify fraud was a huge part of everything I worked on. When I was a teenager working at a gas station people would just run out the door with a 24 pack of beer.

That's just business, you need to price in disturbances like an important customer going bankrupt or switching suppliers or some customers refusing to pay for other reasons, and do a risk assessment before supplying on large orders.

It's one of the earliest lessons you'll learn from starting a company. Another close one is to not waste time on failed sales and annoying customers, replacing them with new customers is usually more profitable and enjoyable.

Me too. I don't want to be signed up for some email spam, and I don't want to initiate a conversation about buying something if I don't already have enough information about it to want to buy it.

urns, not URNs

> Why do I want "interesting" ways to buy things? I want to be able to buy what I want quickly and reliably. I don't get the benefit of making me try to figure out how to buy something I want

Understandable view, but try thinking it from the producers point of view. They want to create an sell in the way that makes sense for themselves and their goals. There are all different types of people with all different types of goals, so it is really awesome when there is all different types of commerce going on. It isn't about eliminating something, but the freedom to make something and sell it on your terms.

Why wouldn't you want interesting experiences options, from time to time?

Why wouldn't you appreciate getting out of the (often) dull (sometimes) frictionless select-order-pay-receive-use-store-forget-discard purchase experience?

Oh god, a webpage built in excel

Fixed drop-down fields are very helpful for shared/inter-company spreadsheets too. Highlight them in red until they're changed, then enforce the value via dropdown.

> The thing that happened is that FAANG redesigned the web for their own needs, then other companies used that to fulfill their own needs too. That's how we ended up with a lot of available content, but also user info mining, browser monopoly, and remote code execution (JS) as a daily normalization of deviance.

and most importantly - we lost our right to search the content that the community generates. it is now walled off behind FAANG services, that threw us directly in the dark ages of internet, when even your own content is out of reach.

here's as simple example - a group of friends been throwing parties for 20 years, like raves. all these are announced on the FB and now-and then on some other services. more than 400+ events for 20 years. trying to find these again is impossible. google won't index them, fb won't allow you to scrape then, insta also. perhaps some obscure snapshot lives of it in internet archive, perhaps not. so one reason to own the content you publish is to be able to actually use it yourself after a while.

Even with JavaScript in the equation, the vanilla web is a good option to reclaim all that, and honestly bringing a personal site up in 2025 takes... less than a day to setup with all the VMs, DNS, CF tunnel, DB, FE/BE hassle that stands in the way. It's more available than ever, people just need to brave and embrace this... but something tells me the majority will not do it.

Yeah, I've spent 2 years in a job trying to build a UI to beat an Excel file. Did not succeed.

I really hate how much work happens out of Excel/Google Sheets, but there's no denying that spreadsheets do a lot of heavy lifting without having to fuss with putting a DB together. Especially nowadays when two people can simultaneously work in a spreadsheet.

> Much of US banking operates almost entirely on this premise and has done so forever.

I might be mistaken, but isn't banking famous for

(1) the long hours (i.e., processes suck), (2) the drudgery of updating said Excel files (i.e., processes suck) (3) horribly expensive to access (i.e., processes suck)

I have never once in my life as a corporate lawyer thought of banking as a model of operational efficiency.

Years ago I was working for a company that was having trouble with their payroll processing vendor. As I was helping them out, I was astounded to find that the final step in payroll was to email a CSV file the bank for the ACH transfers.

This was a fairly small company (~300 employees) and a national bank, so it strikes me as likely that this is how a lot of companies do business.

Yep an early project of mine was building an import of account charges from an FTP file transmission. There was plenty of checking and validation, any records that didn't pass were rejected and the user got notified (I think via email) with the rejected records and the reasons. They could then correct them and resubmit.

Granted the only real security was the FTP username and password, but it was all internal and at the time (1990s) that was good enough.

To me, this line of argument is completely backwards. Are you arguing that when people didn't know better, they used flawed systems, or are you actually saying that having a unified method of interaction between users and systems though a web browser app is worse than dark IT excel sheet macros?

> Much of US banking operates almost entirely on this premise and has done so forever.

Not literally. Banks have a lot of automations. The reasons they’re not real-time has more to do with various regulations and technicalities of recourse, not because it’s someone doing semi-manual processing of everything at each bank.

That the system works does not mean that individual components of it are advisable. It works because it must and that is with great development effort to keep these interfaces working.

> Much of US banking operates almost entirely on this premise and has done so forever.

I've had the same epiphany when I worked for a fintech startup that interacts with financial institutions. Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes.

>> In short, while letting customers send Excel files "and then load+merge their results directly into the same SQL tables" might sound nice, this does not scale and will certainly result in a failure state at some point.

> Much of US banking operates almost entirely on this premise and has done so forever.

This is a disingenuous statement as it relates to at least credit/debit/gift card transactions. Bank-to-bank and select high-volume Merchants communicate in certain circumstances with secure file transfers, especially for daily settlements.

The vast majority of Merchants do not, and instead rely on secure web applications to authorize, capture, and settle their transactions.

Perhaps other banking domains rely on Excel and similar to do business. I cannot speak to those business areas.

> I'd take a look at the Nacha (ACH) operating rules if you have any doubt that sophisticated business workflows can be built on top of flat files and asynchronous transmission.

And I'd recommend you take a look at different integration - online payment processing using Oribtal as described by Oracle.

https://docs.oracle.com/cd/E69185_01/cwdirect/pdf/180/cwdire...

Why? What I would prefer is a "Notify me when the rider is [X] minutes away. Use ringtone [R]" feature. X is the time I need to go downstairs and open the gate. The customer need not have their brains cluttered with logistics details.

Still is that way in many places. Some smaller clients I've worked with prefer the flat-file + FTP over a more integrated solution (TCP/IP, etc.).

Just the fact that you've assumed a phone call highlights the difference in culture. It's done over text!

I cannot speak for Africa, but this is not true of South East Asia.

Whilst cheap 'dumb' phones do still exist and are used, even low income earners in South East Asia tend to have a smart phone, and most of the business done as landgenoot says is conducted via Telegram, Facebook, or occasionally WhatsApp or Line.

There are also ways of paying using nothing but a phone number, but usually business is done on a smart phone where photos of products are are shared, delivery is arranged, and since COVID, most payments are done via QR codes that require a smart phone.

In my experience this is not only true of the cities, but also even out in the provinces.

I live in Singapore and travel to Malaysia, Indonesia, and Thailand quite a bit. What you say is certainly not what I observe.

Do you really think that SEA is still stuck in such economy ? Man you need to explore the world more

Except this is pure fantasy and AI is uniquely unreliable and error prone.

It sounds like he’s already smoking pot.

This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning.

Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.

100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much

I think a really good example of this is that lots of times even when making a web app, different people make the web app from the people who made the marketing site for selling the web app.

That was one of the most interesting reads I've read in a while, thanks.

Thanks for the JoS link, a thought-provoking read as always! (And it doesn't feel like a 23-year-old blog post - love your work Joel).

Shrink-wrap is still very much a thing, even if distribution is entirely digital in most cases. It's dominated by internal line-of-business apps, sure, but that was true back then also.

I agree with Spolsky in theory. But in practice, I've been on one project in the last few decades which I actually think benefited from integrating a web framework. The majority of projects I've worked on absolutely did not need JavaScript, and the rest would have been served by an approach similar to what's described in the OP--a few minimal vanilla JS files to create a few web components.

And yet large teams of very smart people reach for NPM as just part of their initial setup process. It's so ubiquitous that I essentially had to learn to not write this way on my own, by asking myself "can I do this without JS"? Almost every time I asked that question, the answer was "yes", and the non-JS way was much easier. But for a long time I wondered if I was wrong--maybe the framework JS way is easier in some way I don't understand--because everyone around me was doing it the framework JS way. It's taken me years of experimentation to build up a preponderance of evidence to persuade myself that in fact, the framework JS way is just worse, most of the time.

Everybody wants to be Facebook or Google, but the fact is you probably just aren't. You probably don't have their problems and you probably don't need to use their tools.

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the path to rendering a page should be pretty clear. Have some weird JS requiring menu functionality? Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu. Or yes, if you count the menu as part of those pages. Have some video player stuff? Well it is going to affect all pages where there is the video player. Something for forms? All pages where you have such forms. Then there are things like maybe animations or checkbox states. But I fail to come up with examples, where the scope of the change is so unclear, that one can't relatively quickly figure out what will be affected and what not. It must be some WordPress mess or something. Then I can imagine it. But with a site built from ground up? Nope, must be bad design or structure.

Of course you could just have made up that example as a straw man as well.

Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.

>A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints.

It's been standard practice for at least 25 years to disable the submit button once it is pressed. If you aren't doing this as a developer, you are practically begging for trouble, and it's really so easy to avoid that trouble.

I agree with you about the customer-facing issues which occur with vanilla sites which don't deliver good user experience.

However, I'm interested in how frameworks solve the developer experience problem you mentioned:

> Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about?

> When you add a new thing in a template, how many N+1 issues across how many pages did you just cause?

> Where does the data even get loaded??

Doesn't this just change into

- "Will changing this React component affect only the feature I want, or do other pages interact with it differently?"

- "When adding a new component into a template, will I break any other pages which use this template?"

- "Where does the data even get loaded??"

I’d approach this with a wizard-style (step by step) interface and transactions—orthogonal to JS framework.

Again failing to understand what parent wrote.

Team of 30 people is not needed to write fully featured application.

Team of 30 people is needed to build, run and maintain enterprise applications. Where you might need 24/7 support and such support requires at least 5 FTE, you might need features changed when 3 people go on 2 or 3 weeks vacations. Maybe that single person will come up with something better to do with their life so you need to have some people to take over.

What parent comment was about, people make broad statements not understanding that world is much bigger place.

Yea it is absolutely possible to build an app the way you describe but it doesn’t work for every app everywhere.

The same of course using React/Angular doesn’t work for everything, everywhere.

I don't really have anything to add to the conversation at hand, but Photopea looks pretty cool. Thanks for sharing!

You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them.

The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.

Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React.

Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly.

There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by default at the beginning should be seen as unnecessary complication.

Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.

And if you can point me to an example of that I will happily lampoon them.

If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top.

All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.

There's a shocking amount of people who don't know that vanilla JS is a thing... They only know React...

I love it! All ES6, no deps.. probably makes your lives harder than they should be but in the name of pureness and badassery and complete control over performance, awesome! You choose to suffer for the right reasons. Wishing you the best of luck and that I can try it soon.

Forgot to say.. I very much admire and appreciate the aspect of "ejectability". More software should strive for this ideal.

https://thymer.com/ejectable-apps

I read that and nod all the way through. Hope you succeed!

Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.

You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements.

A blog is just one example of a place where frameworks don't help, chosen because the site OP shared is functionally the same as a blog. Other applications have different requirements and those requirements may also not benefit from a framework. Alternatively, the requirements themselves may actually have benefited from a framework and the authors chose to avoid them because the team preferred not to or because they felt strongly about avoiding frameworks because of personal preference.

In this case, this project has really one active contributor [0], so it's missing one of the key ingredients that in my experience really call for a framework: coordination between a large number of people.

(And lest I be mistaken: just because a project has a large number of people does not mean a framework would for sure be the best choice. I'm sure there are counterexamples to that too! It's just a hint in that direction, not an ironclad law.)

[0] https://github.com/mickael-kerjean/filestash/graphs/contribu...

I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.

I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't.

Rather than opening up that can of worms I'm going to leave it where I left it.

It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching.

If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.

Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance.

Dogma is a hell of a drug.

It is NOT a big if, because by default, caches are not deleted on shutdown. Plus, in a corporate environment, the windows installations are centrally managed and won't be configure to do so. But coming back to the original argument: If there is no caching, your SSR is never going to be fast too.

Totally different caching techniques. MPAs have a built in mechanism called back/forward cache. It works automatically on most sites, though some invalidate the cache. https://web.dev/articles/bfcache

SPAs need to hold onto the data themselves, and correctly transition it between pages/components. Poorly-built ones will simply refresh it every time, or discard it if the data is too large.

Both mechanisms can allow for immediate page loads if they've been correctly implemented. They just require a different approach.

That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.

If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering.

And quite frankly I don't see why Id want to reinvent the wheel there.

{#each notes as note} {note.content} {/each

is exactly what Id want to implement for example if I were writing JS functionality to render a collection.

And Svelte for example doesnt restrict you from using vanilla JS whenever you want either

Implementing state isnt very difficult.

I think youre thinking of a very static use case again. Link to page number doesnt make too much sense when the data changes (and do you really want to refresh the whole page just to change the table data?), but yes thats easy to implement to.

It would just look something like let pageNum = params.page

<Table defaultPage={pageNum}/>

Now think about if you need to implement a more complex table in an admin UI that lets you filter / sort, delete/add rows, etc. Thats where reactivity is really really nice. All you have to do is something like items = items.filter(i -> i.name.startsWith(input)) and youre done.

maybe you'll be interested to know v3 is in active development

https://github.com/MithrilJS/mithril.js/pull/2982

> 10x longer to respond

10x longer than what?

> It’s just the developers that don’t care because deviating from the framework

You realize that many major modern (and legacy) web frameworks started inside companies?

> I'm making a web game and using html, css and vanilla javascript

Nice work. Reminds me of "A Dark Room" and how a simple mostly-text interface with a bit of HTML/CSS/JS can have such a big impact.

https://adarkroom.doublespeakgames.com/

Both were absurdly slow and resource intensive.

We have 2 main products: a SaaS and a desktop app (1mln+ users combined). It's a pain in the ass to support the desktop app:

- many people refuse to upgrade for various reasons so we have to support ancient versions (especially for important clients), for stuff like license activations etc.

- various misconfigurations (or OS updates) on Windows can make the app suddenly crash and burn - and you waste time investigating the problem. My favorite recent bug: the app works OK everywhere except on some Japanese systems where it just crashes with access violation (see the next bullet point)

- debugging is hard, because you don't have immediate access to the machine where the bug triggered

- originally it was built 100% for Windows but now we have people asking for a MacOS port and it's a lot of work

- people crack our protection 1 day after release and can use it without paying

SaaS has none of those problems:

- people are used to the fact that SaaS applications are regularly updated and can't refuse to upgrade

- modern browsers are already cross-platform

- browser incompatibilities are easier to resolve

- you debug your own, well-known environment

- if someone doesn't play by the rules, you just restrict access with 1 button

Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that".

The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated rollout or if the manager of sales has some unique setting on his machine which for some inscrutable reason does silly things to the new version. If their web browser works, the inventory database works for them, and they're on the latest version. If their web browser doesn't work, well, your support teams would have had to eventually take care of that anyway.

That sounds nice and it probably works fine if you're targeting a single business running Windows, but targeting Mac, Windows and Linux remains more difficult, no?

And is there even a guarantee that your deploy will be rolled out in X minutes?

Version skew remains one of the biggest sources of catastrophic bugs at the company I work for, and that's not even taking into client app ver, just skew between the several services we have. Once you add client app ver, we have to support things for 3 years.

At my one-person company I just do a Kubernetes deploy, it goes out in a couple minutes and everyone has the latest ver whether they like it or not. I don't have the resources to maintain a dozen versions simultaneously.

There’s a hidden cost in web applications as well: you lose the value of the operating systems application language. Every website and thus electron app suffers from this. There’s no standard place for settings, buttons and windows don’t behave normally. There’s a lot of value in native apps in usability just in it sharing the same UX language as the operating system. Sadly this is mostly dead for new applications.

Building a game for multiple platforms for steam is way more work than building a single web app. Builting the game often requires unique settings for each platform, machines for each target platform, testing on each target platform, dealing with bugs on each target platform. Getting noterized/certified on each

> EDIT: For the naysayers: please then explain to me why Steam is so successful at deploying large games on multiple platforms?

How many games are multi-platform on steam? Checking the top 20 current most played games, 14 of them are windows only. If it's so easy to be multi-platform, why would 14 of the top 20 games not be multi-platform? Oh, it's because it's NOT EASY. Conversely, web apps are cross platform by default.

Only 2 of the top 20 games supported 3 platforms (windows, mac, steam-deck). 1 was windows+steam-deck, 3 were windows+mac

> For the naysayers: please then explain to me why Steam is so successful at deploying large games on multiple platforms?

Because Valve puts lots of time and money into making it work for their customers (https://github.com/ValveSoftware/Proton/graphs/contributors), time and money that the average small business can't afford.

Here's a good example: I used Weylus which turns any touch device (phone, tablet etc) into a drawing tablet + screen mirror. It can be used to turn your iPad into a second monitor or as a touch device for your laptop.

Weylus gives you a URL that you can visit on the device and instantly use it. Try doing that with native apps. They'd need native apps for Windows, Linux, Mac, iOS, Android... get them on the app stores too, support all the different Linux distros... or just a single URL that works instantly anywhere.

Steam works for the same reason the App Store works, it targets mostly a single platform (Windows) and all dependencies are bundled in. The Steam client itself is a web app running on the chrome engine, though.

In large corporate environments I agree but small companies still mostly don’t have central management of end user computers. They order a computer from Dell and use it as delivered. Much easier to just access everything via a browser that way.

> Many desktop applications are written in .Net so you don't even need to install the runtime because it's preinstalled on the operating system.

The last .NET version to be deployed this way has a 10 year old feature set. Nowadays you bundle the parts of .NET you need with the application.

> please then explain to me why Steam is so successful at deploying large games on multiple platforms?

if you look into the support forums on steam for any random game you'll find lots of complaints about stability and crashes, many of which are likely to be esoteric system-specific problems.

That’s a very ironic example given that the Steam Client is a web-app hosted in Chromium.

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.

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.

> it's preinstalled on the operating system.

Not on my computers. At home, or at work

As a Rails developer with no desire to work in a React codebase, I'm not qualified for about 50-60% of the Rails jobs postings. My lastest full time was at Shopify where I said over an over that I was Ruby only and not interested in a React position only to be told a few months in I needed to know React to get promoted. It is exhausting.

I have no React, Vue, or Angular experience. My websites were built with Livewire, some HTMX (basically Hotwire in the Rails world, server rendered HTML partials; or maybe Blazor SSR in the .NET world). I use Tailwind and a Laravel backend, but have some experience with C#.

If you think that’s interesting, send me your firm’s URL, I’ll consider applying. (Edit: or really anyone reading this who is interested - government of a foreign nation outside the US is not viable, unfortunately.)

Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.

Issues with old school websites before SPAs were usually "kinda clunky/hard to navigate/find stuff" and "ugly/inconsistent UI."

Issues with SPAs are "core features straight up don't work " and "page is now just an endless spinner."

I know which I prefer.

And adTech. I’ve been a happy user or the local gumtree [0] that always worked fine with my 9yo iPhone… until last year: the business model seems to have changed as they added in-list advertisement and I can only scroll the products list until the first ad wrapper shows up. Then the UI freeze and never gets back to life. I don’t even see the advertisements itself.

[0] https://www.leboncoin.fr/

Edit: just tried it again and seems they fixed it! The ads stays in loading state forever but the site is usable again. Wonder if they did something on their side or if they changed ad provider.

Bring back the <blink> tag.

The point is there's no reload flash as you switch between pages. The specific transition is up to the author.

This just means that user doesn't get the animation tho, right? The actual page transition still happens, so you get graceful fallback without the need to do anything special.

I believe it’s finally enabled by default in nightly builds, so it should be standard soon. I may be wrong and it may have been scoped css enabled, but both are available by feature flags on nightly and plan to be enabled by default by the end of the year.

No one uses Firefox (within the margin of error). Use them to your heart's content.

Oh no, you're part of the problem :(

I guess openly admitting that you refuse to learn how your platform actually works is an "earnest approach", of a sort, but so is admitting that you routinely leave grocery carts in the parking lot and don't see a problem with it.

Huh? The built-in APIs aren't perfect, but we're talking about something simple as

``` fetch('/my-content').then(async res => { if(res.ok) { document.getElementById('my-element').innerHtml = await res.text(); } }) ```

Something like that. Doesn't get much easier. Gone are the days of browser inconsistencies, at least of you stick to "Baseline Widely available" APIs which is now prominently displayed on MDN.

> Why not?

It's really irritating for your users. They might not consciously be able to point it out as the cause of their irritation, but they'll like your app a lot less.

> HTML is almost frozen in carbonite.

Not really - there are pretty big escape hatches - you can do pretty much anything in canvas, custom elements allows you to define your own elements with their own behaviour.

I'd say the problem is the opposite - one of the reasons desktop apps from 20-30 years ago ( say MacOS 7 ) where great from a user perspective is pretty much all apps looked and worked in the same way, using the same UI toolkit and the same UI principals. And from a developer perspective - a lot of the key decisions had already been made for you.

The web of today is a zoo of UI styles and interaction modes.

The problem isn't so much a lack of innovation or possibilities, but perhaps rather the opposite.

Yes, making UI’s is not a new problem but building on top of the DOM/HTML as the backbone is.

I too am from the before times where I guess we built essentially our own frameworks to handle own unique issues and take security into our own hands (verses have to trust external libraries and external resources….)

I sadly laugh when I hear 20+ years late people are still fighting back button navigation issues. I still see sites that can’t handle double posts correctly or recovery gracefully when post responses fail/timeout.

I’m out of the game now but for all the benefits of the web it’s been haves to death to support stuff the underlying infrastructure was nit designed for.

Look at WPF (or its more modern incarnations like Avalonia or Uno) for a decent example of what a GUI framework designed for desktop apps from the get go can look like.

Things like these haven't taken over the world because they didn't have the ease of app delivery that browsers provide, and attempts to bolt them onto browsers (Silverlight etc) didn't work out because they didn't work out of the box for most end users.

These days though we have enough bits and pieces directly in the browser (wasm, canvas, WebGL etc) to recreate something like Silverlight that "just works" in any modern browser. Take a look at https://eremex.github.io/controls-demo/ for an example of what's possible.

Yes, my first GUI apps were about 20 years ago in visual basic. It was far easier than laying out webpages (assuming you're targeting desktop users). It's just far harder to get users to download and run something (and should be). But the browser's layout system (the DOM) has 0 to do with that, there is nothing but inertia locking us into that.

Desktop apps have had superior UIs compared to the web for decades, and are still superior today. The Web is a terrible application platform which only persists because it's very easy to distribute to users.

It doesn't necessarily need to be Turing complete, but CSS in its current form is harder to understand, debug or make sense of than most Turing-complete languages.

> I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing.

Contrast that with non-framework JS/HTML, where _you_ decide how long it lives and how often you need to upgrade (or not). Having to rejigger a web app every 2-3 years because someone outside of your organization changes something is not only unappealing, but it's horribly expensive for large-scale businesses and possibly prohibitively expensive for small-scale businesses or solo developers.

Yes and for those cases it’s kind of already solved decently like with htmx or just plain old forms and post requests. I think those old ways are underrated.

But, for a chat app it isn’t gonna cut it. Or a collaborative app, where changes need to be pushed to the client. Or maps, or similar. Or anything which needs offline working. (I’m working on a desktop app where majority of state is owned by and lives on the client.)

TLDR I agree for passive web pages but the web is often more than that, many times for good reason.

Given the way most templates about Web Components are going it feels like a dirty secret that you don't need to use Shadow DOM at all when building Web Components and that it actually feels nice to build Web Components without it.

When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.

Interoperable: You can build a Web Component once and it should work "out of the box" in the latest Angular, React, Vue, Svelte, etc. (React was among the last holdouts on Web Component support because of Virtual DOM silliness.) Interoperable Web Components get us away from the era of needing to build npm libraries like ng-mycomponent, react-mycomponent, vue-mycomponent, for all the various combinations of drastically different component systems and ways of writing components, even when your component's core was as Vanilla as you could make it and you shared as much code as you could between implementations there were still so many small subtle things to do differently.

Date pickers aren't simple. I would challenge you to explain why you couldn't just store it in a variable or on the element itself.

One place to store it is in a data attribute.

> <h1>${x}</h1>

Fine for x:string, but what about w:WebWorker?

That doesn't look like it even has anything to do with custom components, that's just adding a method to a class. OOP 101.

Show me a successful GUI made with bash.

Can't put those in templates though. It's a serious pain and completely unnecessary.

Well it's not a lie, it's how HTML and the DOM work. Attributes are strings, and what you write in HTML will be passed as attributes.

You do also have access to properties, but only in Javascript — you can't for example write something like `<my-custom-component date="new Date(2024, 02, 04)">`. That means that if you need to pass around complex data types, you need to either manipulate the DOM objects directly, or you need to include some sort of templating abstraction that will handle the property/attribute problem for you.

This is my main criticism of web components. At the simplest levels, they're not useful — you could build this website very easily without them, they aren't providing a particularly meaningful abstraction at this level of complexity. But at the more complex levels, they're not sufficient by themselves — there's no state management concept, there's no templating, there's not even much reactivity, other than the stuff you could do with native JS event emitters.

As far as I can tell, the best use-case for web components is microfrontends, which is a pretty useful use-case (much better than iframes), but it's very niche. Apart from that, I really don't see why you wouldn't just write normal Javascript without worrying about web components at all.

I stand corrected!

That's a very subjective take on what properly means in this context. Many would argue that serving the content is the main thing that matters to your users, and if your font takes so long to load that you need to deal with it separately, it would be better to not do that to begin with. To put another way, as a fellow user of websites, I would much rather read what's written than look at a blank page while some marginally different version of Helvetica is fetched in the background.

It makes it harder for ISPs to inject ads: https://superuser.com/questions/1087669/blocking-the-isps-ad...

The irony is: I wrote a bunch of small custom elements [0][1] that do one thing and I don't use Lit for that, because Lit is still overhead. The litte bit of boilerplate overhead of Web Components, I simply wrote by hand.

[0]: Table of contents element: https://github.com/cmaas/table-of-contents-element

[1]: SVG avatars (React-free fork of Boring Avatars): https://github.com/cmaas/playful-avatars

> Sure but this page is about not using a framework.

Fair enough, but the way I read TFA, it doesn't dissuade developers from using tiny convenience libraries that leverage native browser capabilities. Based on your pushback, it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. I'll dig into that more, thanks!

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.

I feel the same way, although I do struggle with excluding people who use older technology. I suppose TLS 1.2 is fairly old at this point ...

A lot of people argue about this both for and against.

However, TLS does not entirely help all of these things, especially with the way it is commonly used with HTTPS (although it can be used in a more secure way, it usually isn't). Although it prevents spies from injecting scripts, it does not prevent the server operator from modifying them from what the user expects (and it is not necessarily the software the user intends to run), nor does it help against someone taking over the domain name and then legitimately putting something else there instead (and stealing cookies, etc; X.509 client authentication would prevent theft of authentication though). To verify that a file is not modified, cryptographic hashes will help much better (whether or not TLS is used; TLS still prevents spies from seeing which files you are looking for though, and prevents spies from obtaining a copy of a file that is intended to be secret). However, these are not inherently problems with TLS; they are problems with the implementation, problems with HTML, problems with HTTPS, and problems with the expectations.

Another issue with TLS is proxies; if you want to deliberately run a proxy on your own computer (so that it is protected from spies, etc), you will have to decrypt and encrypt the data twice. This is also a problem with the implementation, and not an inherent problem with TLS itself; an implementation could easily allow unencrypted proxies of encrypted connections, but doesn't.

Self-signed certificates are commonly used with Gemini protocol and can be used with other "small web" protocols that support TLS. If you know the server's certificate from some other source (TOFU is a common way, but you could have another way), then self-signed will work, although it should be possible for the end-user to specify to require a specific server certificate (and adding this information into the URL would make it possible to pass a URL that includes this information, which may sometimes be helpful).

Web of trust for X.509 certificates is something that I had thought of, and I had some ideas to make up a file format for that purpose. This will be a DER file which has a digital signature, and specifies hashes (and possibly other details) of certificates that you are aware of and will contain details about what parts of the certificate you trust and in what ways you trust them (e.g. you can say that you trust the common name, or that you understand a specific extension but have been unable to verify it, etc), as well as optional comments. Note that this can be used whether or not the certificate is self-signed; certificate authorities can still be used too (which still have uses, e.g. if the authority is partially being delegated).

Another problem with certificates is securely superseding them (especially self-signed certificates). X.509 does not allow to add an extra field of unsigned extensions after the signature (and an extension inside of the certificate clearly cannot sign the certificate itself, since it would interfere) (although an extra field could be added, implementations that do not understand it may reject the extra field), so this could be done in two other ways instead. One is to add an extension into the certificate specifying the superseding key (for security, this can be different than the certificate's own key, and the corresponding private key may be stored on a separate computer that is not connected to the internet and may also be passworded for additional security), and optionally links to sources of the superseding file; the superseding file is then a DER file that lists the certificates being superseded and what they are superseded by. This means that even if the keys (or other details in the certificate, such as names, or expiry dates) are changed, trusting someone else is not necessary, and no other third-party authority is needed to verify if it is actually the same person/organization, or if it is someone else who has taken over the domain name, or if spies are changing the certificate, etc.

Web of trust can be used together with superseding certificates.

DANE would also be a good thing to use, although it won't help by itself, for many reasons. For example, in case the domain name is taken over by someone else or if the DNS is not itself secure (or whoever owns the DNS tampers with it). However, it can be used in combination with other methods in order to improve security.

However, I think that allowing unencrypted connections is just simpler anyways; if the user does not need or want this privacy and security compared with wasting extra computing power or whatever, or wants to use older software that does not support this version of TLS, or is connecting only to other programs on the same computer (which will have its own security mechanisms, making TLS unnecessary (except for testing purposes)), or for whatever other reason, then allowing unencrypted connections is helpful, especially for read-only public data. Integrity can often be verified better in ways other than TLS anyways, as I had mentioned. I think there are many reasons why unencrypted connections should remain an option where possible; however, servers and clients should be made to allow TLS where possible, too, in case you do want this security, but it should not normally be mandatory (especially for read-only public data).

Framework people always complain that simplicity doesn't scale. In my nearly 20 years of experience doing this I can firmly say they are entirely wrong. If an application increases in complexity as its features increase the way to restore order is a minor refactor.

But really that isn't what this is about. Framework people were always falling back on this fail to scale argument even in the early days of jQuery. The real issue is that some people cannot architect and cannot refactor. That isn't a code or application limitation. Its a person limitation.

it's a long story, let's just call it "a non-functional requirement" :)

It has a contentious history and largely was forced through by one person in TC39 who focused on a particular corner case