Plain Vanilla Web

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

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

urns, not URNs

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

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.

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

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

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.

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

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

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.

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.

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.

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

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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