I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser.

A vast majority of the hours I've spent building web sites & applications has been devoted to administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations. In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.

The web provides one type of UI/UX. It isn't the only way for users to interact with your product or business. Email and flat files are far more flexible than any web solution.

The fact that this all got hyperlinked is a superb. convenient, but also a challenge from tech perspective, and what FAANG did in the 30 years to come (after 1992) led to this horror of entangled and super-complex technologies we have today. Even vanilla web is quite complex if you take into consideration all the W3 standardization.

Security or not, you can have an appliance run much simpler software given longer product lifetimes,... My only hope is now with llm-assisted coding this vanilla approach comes back, as the boilerplate pain becomes more bearable (how I really hated html at some point...). Besides, it is much more pleasant to prompt yourself a website, rather than try to position some image on stupid fb/insta pages/events, which is one major reason to step back and own your content again.

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 and if you squint and look closely you'll find interesting people doing interesting things all around you.

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 number of different online purchase options that would avoid all of the problems with this for a nearly trivial fee.

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.

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.

I had a friend who worked at a gas station in high school. Filing police reports for people who filled up and left without paying was a standard part of operations.

This was in a nice area, too. Often people just forgot and drove away. They had recourse because they had security cameras and people had license plates. The cities where you’re forced to pay inside first probably have police departments that don’t respond to non-payment as gas stations.

If someone showed up with a gas can or something they were instructed to shut off the pump and make them come inside to pay. It wasn’t as much of an honor system as it seems if you’re not familiar with it.

You can’t have a pay-later business without an amount of non-payment, which has to be compensated by higher prices (which other customers shoulder).

These are all choices a vendor can make. Something like this usually lasts right up until the secret gets out to a wider audience where the people who don’t care about social norms have no problem abusing a system left wide open.

People who never experienced high-trust and customs societies cannot grasp why and how it works infinitely better than low-trust ones.

But granted, all it takes is a few determined bad faith actors to break high-trust, when they are not vehemently and swiftly rejected…

An interesting story behind those:

https://blog.lostartpress.com/2023/02/07/john-wilson-1939-20...

I know the other way around is basically the norm: how does one know the company, the seller, will actually provide the product after paying. But the prevailing culture, currently, is that companies in this regard are trustworthy and customers are not. It's a bit debatable but it makes sense.

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

Yep :)

While an e-commerce solution is not always needed, there’s a good chance that a very simple shop cart facility will convert more than an email link, for certain types of products.

That said, there are b2b exchanges where a simple website is perfect. Supplier quality cases where people need to exchange short texts or general supplier information exchange.

Also b2b customers are far less concerned about UX style than the average retail customer. The former wants a system that just works efficiently and everything else is a waste of time. Sometimes productivity clashes with modern sensibilities and in the b2b case productivity still wins.

I hate mail though for formal processes though. In that case a link to a simple website that orderly takes up information and it is the better solution.

I also hate putting excel files into tables. There is always something going wrong, especially with files created in many different languages, and it is still work overhead. But there are already solutions for general information exchange that aren't necessarily parasitic SaaS services.

Of course there are alternatives, but I wouldn't call the usual ERP/CRM software superior to web apps.

I originally planned to scrape the data and make my own website with better (imo) controls, but v0 turned into pumping the data into a Google sheet.

I've never needed v1. The Google sheets "UI" solves filtering (i.e., breakfast vs lunch), access control, and basic analytics (~7 other colleagues also use this daily).

Enabling customer self administration/configuration of a "B2B SaaS" system mandates some form of interaction. I would be surprised at how many would not expect "touching a browser" to do so.

> A vast majority of the hours I've spent building web sites & applications has been devoted to administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations.

If there is no validation of information given nor system rules enforcement, then I would question the correctness of said sites/applications.

> In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.

This approach obviates the value added by a system enforcing core software engineering concepts such as fitness of purpose, error detection/reporting, business workflows, and/or role-based access control.

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.

> error detection/reporting, business workflows, and/or role-based access control.

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.

https://www.nacha.org/newrules

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.

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.

This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.

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

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.

We execute Python in our PG database and do testing through PGTAP.

That said, I do think plain vanilla approaches like this site describes are valuable—not because everyone should use them, but because they remind us what the browser can do without 20 layers of abstraction. That can be really useful when the goal isn't a full app, but something in-between email and interface.

It’s less about dogma, more about choosing from a wider spectrum of options—including “no UI at all.”

> Email and flat files are far more flexible than any web solution.

Some times I feel like I’m taking crazy pills when I read HN lately. Suggesting that we e-mail requests around and have a person on the other end manually do things including merge data into SQL tables is such a bizarre claim to see. Every once in a while I encounter some business that operates like this and it’s inevitably a nightmare, either as a customer or a partner. Not to mention it’s ripe for everything from fraud to the company falling apart because the person who normally reads those e-mails and does the things for 20 years suddenly leaves one day.

This feels like a mix of rose-tinted glasses reminiscing about the old-timey way of doing things combined with a layer of career burnout that makes everything modern feel bad. Dealing with a business that operates this way is not good.

    7:40 - Bob was delayed by 5 minutes. ETA 7.45
    7:35 - Bob is heading your way. ETA 7:40
    7:20 - Bob has picked up your order from Pizza place

If you have even a small bandwidth to maintain it over time, quick and simple solutions like an Excel template and a few custom scripts work great and often end up being more flexible as your end user is mostly working with raw data.

Every business is basically a phone number that you can message. It does not matter if you buy a pizza or furniture, book a hotel or need someone to clean your sofa.

No website. No need to fill in forms. No platform fee.

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.

> Yeah, I mean, it’s a it’s a very, very, very important question, the SaaS applications, or biz apps. So let me just speak of our own dynamics. The approach at least we’re taking is, I think, the notion that business applications exist, that’s probably where they’ll all collapse, right in the agent era, because if you think about it, right, they are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents, and these agents are going to be multi repo CRUD, right? So they’re not going to discriminate between what the back end is. They’re going to update multiple databases, and all the logic will be in the AI tier, so to speak. And once the AI tier becomes the place where all the logic is, then people will start replacing the back ends, right?

https://www.windowscentral.com/microsoft/hey-why-do-i-need-e...

My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience.

We might adopt a framework eventually (I do appreciate how their opinionated structure can cut down on endless debates), but for now, plain JavaScript serves us really well.

On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.

Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.

It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.

In this case: this is a WordPress blog.

https://www.joelonsoftware.com/2002/05/06/five-worlds/

His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools.

The worlds he quoted were Shrink-wrap; Internal; Embedded; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today:

We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.

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.

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.

It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing.

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. Now as a user you’re confused: did you place the order or not? You got an error but the order also showed up in your history. Hmmm

As engineers we have issues understanding what is and isn’t in scope. 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?? The query lives so far away from where you use the data that it’s really hard to track down. Etc

We started putting new things in React, especially the more interactive areas of the site. It’s pretty nice in comparison. Not perfect, but the framework pushing you to think in components helps a lot. I’m slowly introducing this mentality to other parts but the framework really wants to fight you on it so it’s gonna take a while.

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

Yes and that’s normal. Big ball of mud is the worlds most popular software architecture.

Original: http://www.laputan.org/mud/

My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popu...

> Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu

MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.

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

Yes and no!

TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).

Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.

So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)

edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.

Software engineers are great at providing “well, why don’t you just..” answers to problems they don’t actually have their brains wrapped around. This often leads to attempts to scale poorly scaling approaches (e.g., we’ll just bake every variant, since there are only four today - which becomes combinatorially intractable after a few years of development).

On the flip side, software engineers are also great at choosing how they’re going to solve a problem before they really have a handle on what they’re going to solve.

I use this maybe 5-10 times per year (and several engineers I work with have taken to repeating it): “tell me what you’re doing but, more importantly, tell me what you’re not doing.”

Forcing people to be explicit about what is not in scope helps to bring clarity to otherwise murky tangles of ambiguity.

Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.

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.

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

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.

A sibling comment to yours described it very well.

There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.

If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that.

But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyperlinked webpages, and you often know that right away, even when you don't have many details sorted out at all.

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.

Those kind of posts are the same as ORm vs plain SQL or Scrum vs whatever.

Time wasting at best, misdirection of inexperienced at worst.

Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too.

[1] https://thymer.com/

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!

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

Keep going, you might just end the whole debate in this thread.

I kind think that if your discussing tech about the web you need to include the scale and your experience.

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

Irony here is that OP did precisely this with a link to the precise thing he built. Meanwhile you haven’t offered even a rough description of what you built, much less a link.

I also write more complex webapps using vanilla webtech (with a strong server-side solution like flask, django or similar). I checked out react it just hasn't clicked yet for me in combination with my serverside style.

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.

1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/review workflow, features for deciding what gets shown "above the fold," linters that enforce style guidelines, specialized search features, &c.

While some blogs can have complex requirements and some news sites might be simple, I hope we can appreciate that there will be some blogs that are much, much simpler than the NYT and this have fewer and simpler requirements.

They're both "publishing words," but the back-end complexity reflects the complexity of the business -processes and model more than the complexity of displaying articles on web pages.

In this particular site's case, the requirements are met by WordPress, so "a WordPress blog" is a simple description of what it is. It wasn't meant to include a value judgement.

This is where those people and teams are wrong.

Dogma is a hell of a drug.

> In this case: this is a WordPress blog.

100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the initial page load. Your users use the app on a daily basis, so they get all the JS/CSS/static assets served from their browser cache almost all of the time, until we make a new prod deployment (usually weeks). Plus, all users are always on Ethernet or WiFi at least, not some 3G cellular network somewhere in the desert.

If you use some smarter framework like Next.js, you even get smartly chunked js parts on a per-route basis, that are immutable - they contain a sha256 hash of their content in the filename, and we configure the webserver to serve them via `Cache-Control: immutable`. There won't even be a roundtrip to check for newer versions.

Plus Nextjs comes with tons of other stuff, like pre-loading chunks in the background, or when hovering over a link (i.e. using the time between the hover and the click to already load a chunk). Let alone that the initial render is static html and hydration happens completely unnoticed from the user.

* Are exclusively loaded on high speed internet in corporate networks.

* Have a high hours-of-work-per-page-load count.

* Update infrequently.

We're engineers, or at least we like to call ourselves that. Engineering is the process of gathering requirements and building a system that meets those requirements on time and under budget. If your requirements include being able to serve users on 3G networks or users who only load your site in order to read a single piece of content per day, yeah, optimize your load times. But don't attack other engineers for failing to live up to your app's requirements.

I do find it a little annoying that when we have these discussions about vanilla vs frameworks people hold up an example and I go there and see a news site of articles rather than a complex application, and I think to myself yeah I wouldn't have used a framework in this situation anyway. It's annoying from 2 directions: the first that people ARE using frameworks for sites that shouldn't have ever had them in the first place, and I can bring to mind a couple of news sites I visit regularly where this is obviously the case because of the silly ways they work. Secondly that this is then held up as an example, because most of my work is on very interactive sites so I end up thinking well yeah but that's not going to work for me is it. My feeling is that I could do vanilla but would end up with something like a site specific framework.

My current approach is to use a framework and consistent patterns but to try and use as few other dependencies as possible.

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.

And the reason for that is mainly to prevent edge cases and make sure people in CRUD apps see up-to-date content.

The experience with a no-cache max-age=0 server-rendered site would be very similar.

All of the headaches around custom routing code + restoration of state are pretty much obsolete wirh bfcache, introduced more than 5 years ago.

If you build a dynamic page and use HTTP headers to prevent caching, stop complaining about it. Most people making this argument want to offload dealing with external APIs to the frontend, and then complain about the result when no requirements around API response caching were defined, let alone time was given to define them.

Browser caching isn't a replacement as the first request for every endpoint is still going to be slow.

Yet somehow, APIs aren't treated with the same requirements for performance as web pages.

Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning

With most frameworks you don't need 100kB of JS code.

Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.

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

Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc

Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25kb overhead and get a better, nicer looking, more well tested product that would take you to do in a week?

The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with React/Angular (for example).

I can use a select from Ionic, a breadcrumb from Shoelace, and a date picker from Lightning and it'll all just work.

Doing vanilla Javascript development doesn't mean "don't use any libraries" (well, it might to purists, but whatever) it means stick to using standards based technologies with libraries and accelerators.

For example, I use many of the techniques described by the site, but I prefer to use lit-html library (NOT lit framework) for rendering.

Sometimes I use the vaadin router for routing, sometimes the Ionic router, sometimes my home grown one.

I use a little library I wrote called ApplicationState for cross component shared state, because I don't like state being coupled to my DOM structure.

Sure, this requires a deeper understanding than "batteries included" frameworks, but the advantages outweigh the negatives IMHO.

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

And you're using WordPress, so yeah you are using a framework. Turns out you do think they're necessary.

And as you can see, framework != slow, whether it's WordPress or anything else.

You get your lovely developer experience with components, with the same component API enabling layouts for the repeatable outer structure, easy composition of reusable parts of your content, ease of passing data around between these and implementing any logic you need before rendering or inside what you're rendering.

The user gets a snappy, static website.

Any sharp edges to this approach?

Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.

The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology used to build user interfaces for the web remains somewhat mediocre.

It’s unfortunate that history took some wrong turns with X11, Java, Flash, Silverlight, .NET, and countless other alternatives that I haven’t personally lived through.

Hopefully, someone will eventually find a way to make developing web applications comfortable and the broader community will embrace it.

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 preinstalled on the operating system.

Even ClickOnce deployments -- which you can deploy on the web or on a file share -- pretty much make deployments painless.

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

- 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

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.

Not sure yet how to solve this problem on the Internet yet though. How can we prevent uninformed masses from creating incentives for businesses, that turn the web into a dystopia?

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.

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.

> 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

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.

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.

https://learn.microsoft.com/en-us/dotnet/core/install/window...

Although, on re-read, maybe they meant there's a good chance another application already installed it? This I wouldn't agree with, as applications often insist on installing different versions of the system-wide runtime, even for the same major version.

To be specific, .NET install is version-aware and would manage those side by side, unless the destination folder is overridden.

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.

Not on my computers. At home, or at work

I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.

Games were made in flash so it can't be that slow.

Maybe slow for time to load. I think we got that down a bit and this wasn't to render content but a utility for a signed up user.

Modern day SPAs are far, far worse offenders when it comes to smothering resources.

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

https://m.youtube.com/watch?v=jnYjIDKyKHw

I get that huge apps probably need a lot more than that, but so many people these days reach for heavy frameworks for everything, because it’s all they know.

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

    
    Copy
    

You do have to call `getElementById` on a document. There can be many documents in a window.

Although a very consistent convention, there are no guardrails put in place to prevent something from setting the same id on two or more elements.

getElementById will return the first element that it finds with the id, but you can't know for sure if it is the only one without additional checks

function getId(v) {return document.getElementById(v)}

Dev tools allows $ $$, dunno, make a macro?

We must not defy the system!

    const g = (x) => document.getElementById(x);

Though I think maybe if one is using it for a different purpose, like looking for apartments or roommates then that's probably shit.

It’s such a pain having clear separation in development where everything runs off of the react server by default, but then it won’t when deploying, so either you end up doing all sorts of weird stuff or you need to be building and running production locally constantly, thus defeating the whole convenience of having a dev server that can hot reload the changes

If you’re writing an SPA, and it isn’t Twitter or a content consumption platform, and it isn’t necessary to be API-driven, seriously just stop. You’re not clever, you’re not improving the experience, you’re only appealing to the tastes of other programmers. If billion-dollar companies can’t get them working perfectly, you certainly won’t.

Moving a navigation/menu from one app to another takes 3 people 2-3 weeks by now. Changing the "router" to update the TS version is just as time consuming. Things that would have taken 1 day max. take now 2-3 weeks. That is 1/14th of the productivity and people get paid for that, more than I did. Oh and did I mention the menu responsiveness was broken for months at a certain viewport width? I did report it, but apparently it was so hard to fix, that it could not be done in a quiet hour, so it took months laying around in the queue of things to fix.

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