I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?".
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.
I've found that "send me a spreadsheet and I'll upload it" isn't a great user experience. It's just a big pile of cells, with no documentation (which they wouldn't read anyway).There are a billion things they can do wrong, and they get no feedback on it until I email it to them. They don't know what the options are for any field, and it's easy to enter a nonstandard value. A typo in a header row can lead to data loss with no errors.
There are times when it's the easiest way to handle things, especially for experienced users. But I find it a massive hassle to maintain support for every possible mistake the user can make.
I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one?
I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.
There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you.
> I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.
People romanticize businesses like this but there’s a reason you’re not posting the link. It only works when it’s for a small group of people who are in the know and refer trusted buyers.
It’s also trivial to set up any 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.
> 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.
> 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.
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.
> 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).
The business can just make less money than they would if everyone paid (which is, as you say, impossible). Costs and prices are linked in some markets, but it's not a natural law.
For this to work, you need society as a whole to participate in enforcement.
But we have created an environment where this kind of thing is unthinkable, not even because people won't do it, but because they will only create legal trouble for themselves if they try. So the modus operandi for your average citizen in Western societies in general and US in particular is to not get involved and leave it all to law enforcement.
> 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.
Payment after receipt is very common in Switzerland, but fraud is presumably rare. Your name would probably go on the debtors register and that's the sort of bad credit history you don't want to have. At some point the police/debt collection is involved, they get sent to whatever the address is and so on. For the average person it's not worth burning your name and address for a free spokeshave.
How does the woodworking company ensure payment? Does the specialized nature ensure only "real" customers buy? Is there a trusted relationship? A threat of legal action?
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.
> 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.
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.
Cash on delivery (CODl used to be popular in the US for a lot of the mail order junk on television in the 70s to early 80s. The rise of the credit card for normal people was a cause of its decline because people now had a reliable way to pay over the phone when ordering said junk.
It's only a matter of time before this seller falls victim to a scammer - once they're found. I used to work for a book publisher who started doing their own e-commerce, and at the time one of the payment methods was a "pay later" one that predated the internet ("acceptgiro"). It only took a few months (if that) after the first sites went live that someone placed an order for a few hundred euros worth of books and had it delivered at a storage unit address. We scrapped the pay later payment option for orders over a certain amount then, and I'm sure later on the pay later option was removed entirely in favor of pay in advance methods.
There's newer pay later schemes now (Klarna IIRC) but the risk and debt collection falls to this payment provider. Of course, they got in legal trouble recently because they're a loan / credit company but didn't present the user with the right legalese for that.
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.
In your case, perhaps a shopping cart could increase conversion, perhaps not.
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.
> 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.
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
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?
Lets first not forget: 1) people been doing business with these "ugly" green textmode screens, long before web; 2) the web existed in a very reasonable form pre-www as FIDO, GOPHER, and of course IRC & EMAIL.
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.
> 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.
With that title I didn't expect Javascript to be part of the equation. To me "vanilla" is CERN's HTTP+HTML.
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.
There are some secessionists - Gopher is still alive, Gemini - but alternatives have a hard time to compete with the content companies can provide apparently for free. Most of the content we want costs time and/or money. Content creators can be fine with contributing from their own pocket, but this is not really sustainable. User sponsorship (donations via Paypal, Patreon, Kofi, ...) don't work well either.
Also, since the supporters of the alternatives are generally supporters of freedom (who isn't? Well, people don't reject freedom, they are "just" making compromises), they have to deal with illegal content and other forms of abuse.
So there are 3 problems an alternative web must solve: protocols, moderation and repayment.
> 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.
In fact, I've gone the opposite way- my work has an internal cafe with a menu website that takes a lot of clicks to see everything.
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).
I have a similar experience with providing users with excel files, but would also like to add that in a lot of business, the number 1 competition for a web application is the good old excel file (or its modern cloud version), and it's sometimes a challenge to beat.
> 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.
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.
> 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.
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?
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.
> 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.
This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.
>> 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.
> 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.
Generally in the excel load process, one does sanity checks. However your database can do all the checking if you so wish. CHECK() gets you quite far. If you have PostgreSQL(PG) or some other advanced SQL database, you can even go forth with functions and views and triggers and everything else.
We execute Python in our PG database and do testing through PGTAP.
100% agree that we’ve collectively overbuilt a lot of B2B SaaS admin surfaces. I've also seen situations where a simple Google Sheet + cron + db insert script beat out six months of frontend sprinting.
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.”
I agree. Having seem enormous amounts of effort wasted on implementing fancy web apps by Digital-first consultancies (they reject BAs, but substitute designers) in the B2B space, I think there does need to be more education for the people who procure this stuff (especially in government) who get ripped off routinely.
> 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.
> 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.
Excel files can work surprisingly well in B2B scenarios where there's a high degree of trust. At a retailer I used to work at, we ran an impromptu Christmas gifts team in December each year, where corporate clients could put in a large order of gifts to be sent to their employees. Rather than build a website for it, we just sent them over an Excel file they could fill in with the name and address of each employee, the gift they wanted to receive and a message for the label. They'd send the file back to us and we had a process to validate the data and load it into our system. It sounds primitive, but it was much more time- and cost-efficient than faffing around with a custom application that we would only use for one month per year and which the clients probably wouldn't enjoy using anyway.
Well, sometimes it was DBF files (of dBase / FoxPro / Clipper fame). The first app I ever wrote for money was a thing that prompted you to insert a floppy with a .dbf consisting of a list of recalled products and append it into a local database (another .dbf!) that would let the user query the whole thing. The floppies were obtained by means of a person walking to the local office of the corresponding government entity where they would hand a blank floppy and receive it back with the copy of the most recent updates. That was late 90s.
This evolved through multiple iterations as the government end of it did. At one point you no longer had to walk there physically; instead, there was a dial-up endpoint running UUCP that could be used to fetch the file. Then they found out about Internet, and it became a website with the file, now .mdb (MS Access) rather than .dbf. I rewrote the app in .NET/WinForms, since it was much easier to do all those things from it than to try bolting it onto an old TUI DOS app.
But it was still basically the same table with the same schema by mid-10s, and my app was still chugging along. I wonder sometimes if some iteration of it is still in use today; wouldn't be surprised if it were.
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.
Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.
Yes. I’m happy to do whatever makes the most sense in any given situation. I have never in my life thought to myself “I could easily help solve this problem and make everyone better off, but I will refuse because problem-solving is work and work is only for employees.”
For that, I would propose a feature where I can mark the directions to my home from a well known checkpoint on a map, one time. If the rider deviates in the last mile, they get notification. If they continue to deviate, I get a notification. The solution is not for me not constantly monitor the rider's location.
Some even still use textfiles to exchange order information on a jointly used ftp server, where the most common error is that access happens simultaneously.
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’ve never felt more useless at work than when I was told to integrated with a new React self-service portal. No one actually wanted to build things for it or use it. It was the pet project of a new CIO. I think it fell over under its own weight in under 2 years.
Especially for internal tooling that is little more than CRUD, I find the web to be most useful when a consultant is brought in to build it once or when an internal team can't be allocated to help maintain it.
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.
I moved to south east Asia and the phenomenon of a "hotline" openend my eyes.
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.
I'm thinking about why this is not really how we do in the west. Would customers even want to get on the phone? I think my initial reaction if I was to contact a business through a hotline is that on the other side of the phone it will be a massive call center rather than the business directly which would make me cautious.
But just because it works that way there, doesn't mean it's right. There's nothing about SEA that implies to me the pinnacle of operational efficiency.
In south east asia, people dont' have very good phone or even smart phone in that matter, txt msg makes sense. The same to many african countries where dumb phones are still dominant.
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.
This is some excellent first-principles thinking. Sort of like resisting the next team hire until it's unbearable, keeping the user out of the browser until it's unbearable
no no no.....what you people really need is just an ai chatbot that simply generates your crud app/interface/store/whatever on the fly, so you don't even need excel or anything at all and the internet is just one big open vector database big brain. b2b, saas, excel, admin roles?? haha whats that?? and then we just relax outside in the grass hugging trees and smoking pot or whatever like in the 80s.
Weirdly this is something similar to what Satya Nadella said.
> 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?
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code.
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.
I think that this comment is a great example of the total disconnect these conversations always have.
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.
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.
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.
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.
So much great and timeless stuff was written in the 2000's, it's great and should be part of everyone's read list. Another one that's still pretty timeless is https://randsinrepose.com/
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 work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework.
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.
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.
But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".
Maybe. Personally I haven't come across this phenomenon. But I haven't worked on this type of system in a very long time, so it's probably different perspective from different 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.
> 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
Yes and that’s normal. Big ball of mud is the worlds most popular software architecture.
> 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.
MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.
This is doing the same thing described in the GP of your comment.
If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.
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.
Thankfully, there's a bunch of great and "easy to get going" languages now that __also__ have types (or optionally encourage them) that the "don't have types" thing isn't as much of a forced issue anymore (though engineers can still choose to go type-free and eventually face the wrath of lack of types in a large-scale project)
>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.
Absolutely, and this sort of thing happens in large companies as well.
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.
> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+.
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.
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.
I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.
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.
Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer.
Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static.
I think what you’re really complaining about is that people use React for static content and don’t statically render it first. That is sloppy, I agree. But it’s not React itself that’s the problem but rather the developers who don’t care what they are doing.
In theory, you can completely statically render everything. In practice, every static site I've seen built with React also uses dynamic client-side components, either as a prerendering mechanism, or because there are dynamic toggles and things on the site that are easiest to build as React components. This usually means that a lot of excess Javascript gets loaded on the client that isn't usually necessary.
The islands/RSC work seems to offer some improvements to this, but most of these websites still include a full copy of React on the page to essentially do what the speculation rules API and a `<dialog>` element could do just as easily.
HTML will be around long after React is dead. What guarantee does a React codebase have that its toolchain will still work in 5 years? We've seen build tools come and go, whole approaches deprecated. What if a security update requires upgrading to a non-compatible version of React, therefore necessitating a considerable refactor?
Meanwhile, the original Space Jam website still renders perfectly.
The standards are superior to the frameworks built on top of them. Abstractions come and go, but web standards, once adopted, have a solid track record of sticking around.
Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.
Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.
It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.
It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.
You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
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.
I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.
Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?
Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?
How is it any different to choose a web application framework from the start when building a web application?
You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
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.
A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same reason than people choose IBM: nobody get fired for choosing IBM / React.
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.)
We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies.
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.
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.
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.
Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here.
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.
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.
I think that this comment is a great example of the total disconnect these conversations always have.
I just pointed out that frameworks are not always necessary.
>> In this case: this is a WordPress blog.
No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers.
If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.
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.
Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from:
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.
Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are.
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.
> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining
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.
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.
If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
While I think your page is excellent and loads great, I don't think this is related to the approach described by TFA. You're using the biggest framework around: WordPress. You're just static rendering it. TFA is talking about no build tools at all, using modern web standards, and specifically nothing requiring preprocessing. "... just an editor, a browser, and web standards" is a quote from the page.
> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code
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.
That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not deleted, which is a big if.
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.
This is spot on. Load times do not matter for the kinds of apps that:
* 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.
Congtats! Usability should be a first class citizen. Instead we seemed to have perfected the art of loading screens, "hydrating" components, time & power consuming animations and annoying modals.
One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.
SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.
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.
And frankly, most big sites in my experience break bfcache. For instance: YouTube, Gmail, NYT, steampowered.com, CNN. All have broken bfcache in Chrome.
That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side)
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.
No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache.
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.
Not sure if it's no-framework related, but navigation back/forth is sometimes broken: the url changes immediately, but the page doesn't update and stays on the same article.
Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning
I recently did a ShowHN post for my browser-based screen recording web page side project. 100% vanilla, with added wasm-based ML shenanigans. It really is amazing what functionality can be built into a web page without resorting to framework support!
So you are the guys behind this amazing news website. What made you build this and is the target audience American? If you don't mind me asking, how are you guys monetizing this? Is this a funded venture or bootstrapped?
Rest of World looks like a fantastic news website I was not familiar with. I just spent a half hour reading a whole bunch of interesting articles there. Well done for helping build it - its super fast from Australia.
My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction.
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?
Does your "nice reactive table with search" retain its current state (including scrolling!) if I click on a link that opens another page, and then back out?
Does it let me link to page N of results?
As a user, I find that, in practice, it's these kinds of things that frustrate me far more than the lack of instant reactivity, whereas simple form with a submit button and a paginated table below works just fine.
Increasingly, this is actually an argument in favor of vanilla web components.
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.
Modern static content web development is in some of the best health it's ever been in with the likes of Astro.
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.
I thought this was sarcasm, so I loaded the page, and yeah, that is an insanely fast cold load time, and even more impressive once the resources are cached.
They care about time and they absolutely do care. If your giant virtual DOM mess takes 10x longer to respond on every user interaction they will absolutely notice. It’s just the developers that don’t care because deviating from the framework puts their job at risk.
Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.
I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.
Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format.
HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.
Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.
Yup, the web is a thoroughly mediocre application platform†, but the world’s best application distribution platform.
†I know this claim will rub some people the wrong way, but if you compare the capabilities of web tooling to build rich application UIs against desktop app tooling of even 20-30 years ago, there’s no comparison. The web is still primitive, and while JS and CSS are improving at a good pace, 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.
It's both, really. HTML makes it really easy to do "corporate branded" fancy buttons, but you still have to jump through hoops to do something that could be done with a database and the stock data grid widget in <10 lines of code in VB or Delphi.
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, 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.
>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.
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. It's probably the best upgrade paths of any of the libs I work with.
But you're not wrong about there being many ways to write components and manage state.
And RSC is a mess. But thankfully you can keep pretending that doesn't exist.
> 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.
> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument
To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.
Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.
Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.
For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.
I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.
How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.
But you don't have to learn "framework after framework". Realistically, at a well-organised organisation you learn React and that's it. You don't worry about the compilation and minification and what have you, because you have a working build system that does the build and does the source maps, and you have a culture that fixes these things if they break or become flaky.
As someone who stepped away from web for a while and came back to it a couple of years ago, a straight React or Next.js application is so, so much nicer to work with than old-school webapps were. It feels like the web has finally been dragged kicking and screaming into a world of regular software development best practices. JS isn't the best programming language but it's a proper programming language and it does the job, I'm continually baffled that people would rather contort themselves with the sub-Turing tarpit of CSS and what have you instead of just using some libraries, writing some code, and actually solving their problems in what's usually an objectively easier and better way.
It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.
I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly.
The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology 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 think that using browser as the way to, essentially, deliver desktop LOB apps to the users seamlessly, updates and all, makes perfect sense. Writing those apps in HTML/CSS/JS, not so much - it's forced on us because that's the only stack that browsers have historically supported, but even with all the app-centric additions to HTML over the past two decades, it's clearly not designed for them first and it shows.
I hope that, in the long term, wasm and canvas (or something similar) will gradually take over this niche. Frameworks like Avalonia already let you write a desktop app and then surface it in the browser, today. This stuff is still rough around the edges, particularly wrt accessibility, but there's nothing unsolvable there in principle, it just needs time and effort (and money).
Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.
Nothing got my old iMac G5 whipped into a frenzy like loading a page that had Flash on it somewhere. I’m not kidding when I say that there were many areas in World of Warcraft, a full-fat seamless open world 3D MMORPG, that didn’t make its fans as angry as Flash could manage to.
I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.
It probably could’ve been great, but unfortunately such a thing would’ve been unlikely at best with Flash being solely controlled by Adobe. Not only does that company have a disinclination towards optimization that persists to this day, but with there having been no alternative implementations of Flash, there was no possibility of other organizations taking up that torch or for there to be competition between implementations driving things forward.
The flash player leaked memory. The longer-running the app, the more noticeable it was. I believe this is why Adobe Air (flash player packaged as deliverable) failed.
As for the speed of the flash player itself it was quite good.
My experience circa. 2008/9 was it was fine (used it on a commercial app in lieu of good enough web standards for the featureset). It was fast and reactive for an app-like experience.
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.
Flash was a lot of things, but also, at the same time, neither of these things. (You could come across poorly coded and thus poorly performing apps, but that wasn’t the standard).
Modern day SPAs are far, far worse offenders when it comes to smothering resources.
> deploying native applications is simply too costly.
I do not understand why people hold this impression, especially in corporate environments.
Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed.
Many desktop applications are written in .Net so you don't even need to install the runtime because it's 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?
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
You could of course also make your desktop app auto update without offering a way to refuse. Or you could make it display an error, if the user accesses it without being at the newest version, and block all further interaction. Those are considered impolite, but it seems you are doing it anyway in your web app already.
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.
Some people should probably only be given thin clients, because they are too inept to be allowed to handle anything else.
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?
The web browser is not some magic tool that is always guaranteed to work. Group policy alone can wreck total havoc on web apps on all the major browsers.
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
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.
Of course. I was strictly refering to .NET preinstalled in Windows as per the comment I replied to, which I believe only applies to Framework 4.8.
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.
> 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.
Not going to lie, that's a pretty out of touch opinion in the current decade, where most software feels an order of magnitude slower and less reactive than a mechanical device made 120 years ago.
Most of that software are bloated SPAs that somehow manage to be slower than a complete page reload of any website or app, that is rendered server side using any traditional web framework statically rendering HTML templates.
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.
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.
This feels like bringing the annoying transitions people used to use between slides in PowerPoint to the web. There's nothing smooth about the transition in the linked demo, it's quite jarring.
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.
I have a few sites that aren’t that complex, and I use JS to run a PHP file and populate the results in a div. It appears reactive, but it’s dead simple.
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.
Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime.
I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity.
Edit: holy shit y'all do not like the earnest approach to technology
"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted
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.
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.
No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.
That's a code smell. If you're creating the element you ought to already know about it. If you're not creating the element you should inventory them all at once as the page (or component) loads.
If I'm just adding sprinkles of interactivity to a statically-rendered page for something that vanilla is good enough for (i.e. minimal-to-no display logic), I use the expando giving an element an `id` adds to `window`:
You don’t have to call getElementById or querySelector on document. You can narrow the search by starting at a specific node, just most people default into document as it’s already a global.
Also, it’s a mess separating stuff between react and the server, especially when building with express/node as the backend and the whole codebase together
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
Still the case in most Asian countries where UIs are all Craigslist alike and UX is just shit. People just got use to it. Apparently westerns willing to pay a premium for better UX. It's a culture gap.
Side note but as a buyer looking to buy used tools from locals, Craigslist's UX could not be better. I just started using it recently (after forgetting about it for a decade). Absolutely the opposite of shit.
Though I think maybe if one is using it for a different purpose, like looking for apartments or roommates then that's probably shit.
I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile.
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.
We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...
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 given up on doing frontend work for the time being, because of this crap. I used to do full stack with modern JS, TS, CSS, HTML and whatnot, but then someone made it all go to shit by advertising for NextJS and React, while there was zero interactivity on the whole platform, except for a couple of checkboxes. A few years later, there still isn't much. Some page transitions for when things happen in the backend. I told them in the beginning, that there is not much interactive stuff, but they all got flashed by some one minute low effort Material Design shit, and the idea of the whole thing being "modern" and hiring more React devs. So I stepped away from that while frontend part and let them dig their own hole.
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.
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.)
Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.
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.
Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...
Even in theory, producing json is just typically slower than producing HTML.
It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.
That reminds me of when I first benchmarked a Rails app and noticed that JSON rendering was significantly slower than the remote database call. No lie, jbuilder was taking about 80% of the request time for about 90% of all endpoints.
I guess the rendering itself is pretty much the same for both SPAs and MPAs, since in the end it can be pretty much the same markup, but the SPA is also at a disadvantage here because it has to combine template/components + JSON to generate the HTML :/
The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.
The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional
Page refresh between pages is ok. Lag when updating a form based on your inputs isn't. Frontend UI is like a bigger monitor or faster PC - you may not have known what you were missing, but once you've experienced it it's very frustrating to go back to the clunky old thing.
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.
People looking to get shit done don't really care but, when they're just mindlessly clicking, they'll hit the back button to the main feed way before the time it takes to fetch a modern framework if your site happens to be the first they hit with that particular version from the CDN.
Once you're building custom components in JS files, aren't you basically writing your own microframework?
Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's.
Producing a framework with those features that still fits in a single small size JS file would be great, especially if it can do component updates to shared state (without updating the DOM each turn, hence shadow DOM).
This entire endless conversation would be made SO much easier if we spent some time thinking about the difference between web APP and web SITE. They get conflated all the time and although there is of course a Venn diagram where there’s a bit of crossover, they’re basically entirely distinct beasts that require entirely different technical approaches.
Spend five minutes on webcomponents.org for a depressing ride. Broken links, broken demos, ghost town community and shuttered chat servers. Sponsored and abandoned by the Google Polymer team, or so it appears. Just sad.
Custom elements are very well documented and work in every browser. Get your server to render html with your own elements in them - your own "island architecture", no vercel necessary.
That some site promoting them is moribund doesn't change the fact they work - and are widely used.
I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being useful to any type of site I run (and I run several disparate types).
Web Components don't solve the problems I do have and add new problems I don't want.
Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.
Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.
Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.
You can use the shadow DOM outside of custom elements, and can use custom elements without a shadow DOM.
Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.
I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.
IMHO everyone building for the web should understand how it works and know how to use the foundational web stack, leveraging the web platform per se. Then, by all means use a build system and your preferred frameworks at your discretion, remaining aware of tradeoffs.
For my part, one of the things I like best about Remix (/React-router v7+) is its explicit philosophical alignment with leveraging web standards and doing more by doing less (e.g. mutate server data using... the HTML form tag).
I also highly recommend https://every-layout.dev which showcases eye-opening, mind-expanding techniques for implementing performant, accessible, flexible web layouts using only browser-native CSS.
Context: I've been professionally involved with web development since 1998.
I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that.
This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.
State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
Could you explain what you mean by "storing it in a variable"? It's perfectly fine to store data in a variable (that's what most frameworks do in the end), but that state needs to be reactive in some way — updating that state needs to trigger the necessary UI changes (and ideally in such a way that the entire component isn't being regenerated every time the state changes). This is what makes state management so hard.
Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM with unnecessary renders because that's rarely (perhaps never?) the easiest way to patch changes to it, unlike in React where useMemo is prevalent.
Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems.
The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input is another string, what state should you store here? Fundamentally, there's only one thing that's interesting: the input's value. Anything else — say, the class used to set the background colour — is derived from that value. And therefore we always want our data to flow in one direction: the input value is the source, and any other state or UI updates are based on that.
But in practice, it's usually hard to maintain that strict flow of data. For example, you'll probably have multiple sources that combine in different ways to create different derived data. Or you might have multiple different ways of updating those sources that all need to perform the same updates to the derived data. Or you might have multiple levels of derived data.
It's definitely possible to build applications like this — I started out this way, and still use this for simple projects where the state is fairly easy to manage. But as projects get more complex — and as the state gets more complex — it almost invariably leads to weird glitches and broken states that shouldn't exist. Hence why state management is the core of most modern frameworks — it's the most important problem to solve.
N.B. `useMemo` in React has nothing to do with the DOM — React will never thrash the DOM with unnecessary changes, that's the point of the diffing process. `useMemo` is instead about reducing the number of times that React builds its own VDOM nodes.
This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vanilla JS is superior to React in terms of performance.
Of course vanilla JS is superior to any framework in terms of performance. Anything you can do in a framework, you can do directly in vanilla JS. But performance isn't the only issue here, otherwise we'd all be writing a lot more assembly code.
I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too weird. And these weren't even the first wave of frameworks — people had been using state management systems long before then, but they had other flaws that made them difficult to work with in their own right. React became popular very quickly because it had a very simple rendering model, and because it was quick in comparison to a lot of other options at the time. Since then, the field has developed a lot, and at this point I wouldn't recommend React at all.
Listen, if you're losing track of the date in your date picker as implied previously, then I don't know what to tell you man. Not a problem I've ever seen with progressive enhancement, and I've worked on more complex user interfaces than most. I have witnessed people struggle to solve state-related issues in SPAs for even relatively simple problems though, where the solution would be trivial in vanilla js. If it's not for the performance, and it's not cutting down development time, then what is the endless framework churn really accomplishing? Because that js date picker from twenty years ago still works.
I mostly use SolidJS. It's super lightweight - in many ways, it's just a wrapper around `document.createElement` and a signals library - so you've got a lot of flexibility to use it how you want. It works well for complex web applications, but the library part of it is small enough that you could probably use it for individual widgets on a page and not have too much overhead. The UX is React-like (hooks and JSX), but honestly feels simpler - JSX gets compiled directly to DOM nodes rather than a VDOM abstraction, and there's no "rules of hooks" to learn.
That said, it's kind of niche, which means you need to be more willing to write stuff yourself, so a good mainstream alternative is Vue. Vue is also signals-based and relatively lightweight, but still has a lot of batteries included and a wider ecosystem that is fairly strong. They're also great at taking the parts of other frameworks that work best and implementing them in Vue, but in a fairly considered way. I understand there's also some fairly battle-tested full-stack frameworks in the Vue ecosystem, although I've not had much personal experience of that.
Both libraries are signals-based, which is a completely different reactivity concept to React, which will take a bit of getting used to. But I suspect Vue will make that transition a bit easier - despite SolidJS's more superficial similarities to React, it behaves quite differently.
yeah idk either I didn't read it carefully enough or it was edited at roughly the same time, because I thought I was responding to something very different.
State management, state manage management everybody yells when talking about web dev.
It’s not some sort of mystery, it’s just a global of your variables.
The example given clearly showed components backed by JavaScript. Which means you could implement a state management system in seconds.
But beyond that state management is overrated. I remember when react came out and somebody from face book was describing updating some pending message count number. And how they had trouble with it. The issue was they made shitty code, and the result of react was a solution that hid that shitty code. Because I bet to this day if you profile their example they still had the bug but the state management system silently hid it as a future performance problem.
I get so tired of framework people talking about state as the hill they are willing to die on. State is stupid simple. You use the frameworks because you cannot figure it out on your own and need the giant tool to do it for you.
When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin.
It lets you build full web UIs without touching HTML, CSS, or JavaScript, entirely in Java. The UI logic runs on the server, meaning: no API design, no JSON mapping, no Redux — just a Java object model.
Vaadin follows a true full-stack approach, where frontend and backend live in a single codebase. Combined with Spring Boot or other JVM frameworks, this creates a cohesive Java application—no complex build pipelines, no split repos, and no friction between frontend/backend roles.
What I personally enjoy most is the smooth developer experience: you see your changes reflected in the browser instantly — no manual builds, reload fiddling, or sluggish toolchains - just java and a bit of maven. For many internal business apps, it feels just as “plain” as the old-school server-rendered apps—just with modern capabilities like Web Components and security by default.
(Full disclosure: I work at Vaadin, but I’m genuinely a fan of the approach because it saves developers a lot of headaches.)
This still of programming does not adhere to MVC though, you can't ever swap out the frontend because it's basically merged to the backend and I suspect complex to debug simmilar to JSF.
All MVC (or rather something more modern like MVVM) happens on the server in this scenario, but it doesn't mean that it doesn't happen at all.
A different View + ModelView on top of the same Model could then be used to provide a different frontend if that is ever required (in practice, it probably won't be).
So a pattern is not mandatory with Vaadin, but you can make the UI “simple” changeable with a corresponding pattern of your choice. MVP and MVVM would be good examples of this.
Seems like this is more for the hobbyists - building webpages for the love of the act. Frameworks are built to be standardized, enforce best practices via their design, and allow developers to 'hit the ground running', so to speak.
No web site is intrinsically valuable - the information and functionality it wraps is what holds its value. Developing the access to that information and function, enforcing correctness, and the timeliness of that development is what frameworks empower orgs to deliver at much lower cost in the present and future, vs. vanilla web dev.
You can't overstate how often decisions are large orgs are driven by hype, follow-the-herd, or "use popular framework X because I won't get in trouble if I do" mentalities. The added complexity of tools can easily swamp productivity gains, especially with no one tracking these effects. And despite being terrible decisions for the business, they can align with the incentives of individual decision makers and teams. So "people wouldn't do it if it wasn't a net positive" is not an argument that always holds.
I see absolute messes created out of React and associated frameworks. Quite possibly because, “you’re holing it wrong”. Just using a framework is not going to force best practices and it’s very easy to create terribly bloated and slow systems with these tools if you’re not thoughtful.
Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion.
If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like "<h1>[object Worker]</h1>".
If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy for at least 25 years now; iirc .toString() was specified in ES3, which was published in March 2000.
If I want in the general case to append a child node to a parent (as here with the h1 as parent and the stringified interpolated value as child), I will in almost every case call parent.appendChild(child), where parent and child both implement Node, which is the parent class of Element. The result will correspond closely to the element tree which would be constructed by assigning a string like your example to some other element's innerHTML. (You are essentially using the browser DOM implementation as a templating engine. As sugar over a lot of createElement calls and piecewise tree construction, this isn't a terrible strategy! The JSX with which you're familiar is a more elaborate and more typesafe solution for essentially the same problem.)
Similarly, these references would be from the JS perspective a POJO with lots of seriously heavy implicit "render magic," so you can use them, as with any first-class Javascript value, as function arguments parallel to but a superset of what React does with its props. See the MDN documentation on Node.appendChild (and Node, Element, HTMLElement, etc) for more: https://developer.mozilla.org/en-US/docs/Web/API/Node
If I want to represent the state of a worker thread in the UI, a problem I first recall solving over a weekend in 2016, the way I do it will end up closely resembling the "MVC pattern," with the Worker instance as "model,"
the DOM element structure as "view," and a "controller" that takes a Worker and returns an element tree. Even if I'm using React to build the UI - which I have also been mostly doing for about as long - I am still going to handle this translation with a library function, even if my component actually does accept a Worker as a prop, which it actually very likely will since that will enable me to easily dispatch effects and update the UI on changes of worker state. I might define that "business logic" function alongside the component which uses it, in the same module. But React or vanilla, I won't put that logic in the UI rendering code, unless it is trivial property mapping and no more (unlikely in this case, since any interesting worker thread state updates will arrive via message events requiring the parent to keep track in some way.)
will just stringify the worker and pass that string to the `my-component`. To get the worker instance to be passed correctly, I'd need to do something like
So this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components.
Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?
Yeah, I think the original question was a bit weirdly worded which made people focus on web workers rather than complex data in general.
You can use properties (as opposed to attributes) as I demonstrated, and you can use methods like you suggest, but these are both verbose and limited, and add an extra "the component has been created but the props haven't been fully passed" state to the component you're writing. Imagine a component with maybe five different props, all of which are complex objects that need to be passed by property. That's a lot of boilerplate to work with.
I showed earlier how it takes multiple lines and some fiddling with DOM to set a simple property with vanilla web components. Sure, if you're using a framework like lit, you have access to template binding, but at that point you might as well use an equivalent framework like SolidJS or Svelte which just skips the web component layer.
Every time I go back to give Web Components another 5 minutes, I hit this point where using lit or a lit-like would take a lot of the pain of the problems Web Components don't solve and have no planned solution for away.
But once I decide to cross the "no dependencies" line, using something like Preact + htm as a no-build solution would also take the most of the rest of the pain away, and solve many, many other problems Web Components have no solution and no planned solution for.
You're right, it is just a method call from a class. Nothing interesting or new. And that's exactly why I like it! I like me FE code as boring, unimpressive and as simple as possible.
Imagine 50 years ago: “Data passing seems inherently broken in Unix, because all processes must use strings for input and output. Such a model just can't be built on top of.”
As a matter of fact, Tcl/Tk has been doing exactly that since the 1990s. Of course, Tk has been "borrowed" by other languages, Python's tkinter is well-known. Any language using Tk widgets still has to input options in text form. Obviously that's not particularly difficult to accomplish.
That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringing me?
In theory it is completely an implementation detail, I agree. In practice, it's bloat. If every web component I use in my project might pull in a completely different framework behind the scenes (and worse: if those web components depend transitively on other web components that pull in yet more frameworks), then I now have to deal with all of those different frameworks. Each of them will load more bytes and make my page's startup time slower. Each of them will have their own state management systems. Each of them will have their own approach to templating. Each of them will behave subtly differently in practice.
Why bother when I can just write everything in a single framework?
At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing.
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.
It is absolutely a lie, because web components can handle arbitrary data just at much as any framework.
You're holding web components to a higher standard here in expecting them to take arbitrary data in HTML when HTML itself doesn't support arbitrary data. Notably you can't assign arbitrary data to framework components from within HTML either, so how are web components any more limited?
The original comment was that "all HTML attrs must have string keys and values", which is completely true.
The point of web components is that they create normal HTML elements. So it makes sense to consider what the value of them being normal HTML elements is. You can write them directly in your HTML source code, for example. But if you do that, you only get access to attributes and not to properties, and therefore everything needs to be strings. Alternatively, you can treat them as DOM nodes in Javascript, at which point you get access to properties and can use non-string values, but now you've got to deal with the DOM API, which is verbose and imperative, and makes declarative templating difficult.
Yes, we could compare them to components from other frameworks, but that's honestly an absurd comparison. They're simply trying to do different things. Frameworks aren't trying to create HTML elements. They're trying to reactively template the DOM. It's just a completely different goal altogether. The comparison doesn't make sense.
State management is arguably one of the most important problems to solve. That's why we use React and Vue. You can very easily build complex user interfaces at scale with those frameworks. And you can even take web components along for the ride if you want to. They are partially overlapping solutions for different problems.
There are caveats and warnings already by the time we've added an `<x-header>`, and the attribute boilerplate seems onerous right from the start. It pains me to say that almost a decade on, I'm still not a fan of web components.
Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data.
I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatibility issues.
On one hand this approach is simple, but on the other hand I dislike treating HTML as a mere string, when it is actually a tree and treating it as such is a huge enabler, that many frameworks miss out on.
Make sure to sanitize the content before inserting if you use this approach.
> Warning: This is a security risk if the string to be inserted might contain potentially malicious content. When inserting user-supplied data you should always consider using a sanitizer library, in order to sanitize the content before it is inserted.
Or a simple escapeHTML function within the innerHTML - but I prefer innerText in a separate pass, as using escapeHTML as a pattern gives an opportunity to forget to use it.
Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed.
Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle.
Can we just use links to go between pages, instead of toggling css display:none on custom elements to show different "pages"? You're replacing browser functionality with custom code. To get on par with browser default functionality, you need to implement a loading indicator, error handling, back/forward button handling, address bar updates, opening links in a new tab when someone middle clicked or ctrl clicked, new window when they shift clicked, etc.
https://plainvanillaweb.com/pages/applications.html This example code does exactly one of those things: update the address bar by setting the fragment identifier. Middle clicking and back/forward buttons work because of that. Error handling (if it were to not just be static content but actually loading something from a server like a real website, which can fail) and loading indicators are not present
Re-implementing browser code in JavaScript is not using the "plain" or "vanilla" web functionality. You're making your own framework at that point
And at that point of course we would see some 90% reduction of SPAs, and hordes of FE devs looking for work. There is non-technical incentive at work to keep this bloat in the boat.
> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \<link> tags into the index.html but this quickly becomes unworkable if we have multiple HTML pages. Instead it is better to import them into the index.css (via @import)
You'll eventually need \<link> anyway for preloads, especially with web fonts, since that's the only way to prevent FOUC. Personally I lean on build steps to solve this. I don't like bundlers or frameworks, but I have grown accustomed to custom-building.
I don't find this convincing. For one, many sites don't need web fonts to begin with. For two, the sites that do can use `font-display` or, even better, just let the browser figure it out. Browser developers have spent way more time on these problems than any one of us individually ever will and more often than not, the behavior you get out of the box is already pretty fine.
As a user of websites, I definitely notice when a website uses web fonts and relies on font-display. Preloading them is the only way to avoid jarring changes to the layout. Even if the changes are relatively small, they're very jarring. I won't do that to users of my sites. It's not hard to take care of properly.
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.
That's the point of preloads. You don't need to choose. As soon as the HTML is loaded, the font is ready. You see the HTML immediately (about 10-20ms) with the web font. Win win.
I’m using HTMX and Hyperscript exclusively for interactivity and I’m loving the simplicity of it.
Problems of FAANG are not our problems, yet they've somehow convinced majority of software architects that complexity is good.
My only concern is when I use HTMX/Hyperscript in my FOSS projects will others be comfortable contributing to it even though it has very little learning curve but they have to empty their React cup.
Hum for me vanilla is html+css.
If you throw in javascript language, I do not see the 'vanilla' anymore :)
I ended up using hugo + isso (for commenting) and it works very well.
I moved to this setup after the wordpress drama, and even if I miss something, freedom has no price: https://gioorgi.com/2024/liberta-come-aria/
Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.
The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`.
You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a template child element with a `shadowrootmode` attribute.
I'd recommend vanilla TypeScript instead of vanilla JavaScript. The benefits of typing are enormous. You don't even need npm in the critical path either if you use VSCode since it has tsc built in
Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project
This is the common wisdom about frameworks but I think it ignores the wastage & other side effects around frameworks and the things they make easy or difficult. Many of the decisions made in any framework will represent guardrails for things that don’t apply to you specifically.
I know you’ll “write your own framework” but maybe that’s optimal in some situations - more than we might give credit to at the moment.
I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.
I support the general idea here but just because something is in a browser doesn't mean it's a good formalism.
Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic.
But for internally composing a web application, Web Components are simply awful. They add nearly no helpful features that vanilla JS doesn't already have, and they add bucketloads of extra complexity. You got attributes and properties, and they're mostly the same but kinda not always and oh by the way, attributes can only be strings so good luck keeping that in sync. You got shadow DOM which is great for distribution but super restrictive if you want any sort of consistent global styling (and a total pain in devtools, especially once you go 10 levels deep). You can turn that off, of course, but you gotta know to do that. And plenty more quirks like this. It's just.. It makes lots of easy things 5x harder and 1 hard thing 1.5x easier. Totally not worth it!
If you really want to not use a big clunky framework, but at the same time you have a complex enough app that composition and encapsulation is important, you'd be much better off just making your own object hierarchy (ie without extending HTMLElement), skipping all that awkward web component luggage and solely doing what they do best (tie an object to an element).
Or, better yet, get over yourself and just use a framework that does this for you. Your future self will thank you (and your colleagues even more so).
ps. rant time: If only the web browser people had gotten off their high horse and not proposed the word "Web Components"! If they would've just been named "Custom Elements", which is what they are, then we wouldn't have had 5+ years of people mistaking them for a React competitor.
I haven't started using Web Components, but I was under the impression that libraries like Lit address most of the issues you mentioned for devs who don't want to write their own minimal base class, no?
Sure but this page is about not using a framework. Once you're on board with using a framework like Lit, you might as well use Preact or Svelte or a similarly lightweight framework. The "web component" angle adds no value if it's all internal to your app.
Lit is amazing though. It's fast, lean, and easy to learn. In fact, to my experience, the only things about it that are un-ergonomic, are due to the fact that it's built around web components. Lit without web components would be so much better (again, except if you're building something to be distributed to other programmers on any framework). It wouldn't have a single global registry of components, it wouldn't have that attribute mess, and I bet it'd not need a compiler at all (it doesn't need it now either, but is easier/nicer with it).
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.
> 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!
I do know what you specifically mean when you say that, but… _all_ libraries are leveraging native browser capabilities, even ones which implement a better component model than Web Components.
> it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect.
It has custom syntax, custom directives that look like regular JS functions but cannot be used like regular functions, a custom compiler in the works etc. etc.
They will keep telling you it just a small library and very vanilla though.
And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative to virtual DOMs, etc. The custom html syntax, IMO, is super useful too (eg it lets you workaround The Attribute Mess by passing data straight to properties, as you would in any sane non-web-component framework). And it's a lot closer to regular HTML than eg React's custom HTML syntax (JSX).
> lit-html is a genius alternative to virtual DOMs, etc
It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.
Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.
The classMap must be the only expression in the class attribute, but it can be combined with static values
--- end quote ---
So now you have to figure out which attribute this is called from, whether this particular call is allowed in this attribute etc.
So what they do is they parse (with regexes) their "close to HTML" code into a structure not dissimilar to React's, figure all this stuff out, reassemble actual HTML and dump it to the DOM
Based on the JS Framework Benchmarks (so caveats apply), an app built with lit-html (i.e. just the HTML templating part, as I understand it) is about the same size as SolidJS, and an app built with lit (i.e. the full framework) is about the same size as Svelte or Preact, and at a similar order of magnitude to Vue or Mithril.
So at least in terms of minimal bases, all of these frameworks are much of a muchness.
I really agree with you. Custom elements are a great way to distribute primitives. They start creating friction when trying to actually compose applications.
Perhaps my brain has been addled by a decade of React but as the examples became more advanced, they just looked a lot noiser and more complex compared to JSX or Svelte components.
> then we wouldn't have had 5+ years of people mistaking them for a React competitor.
The browser people literally promoted them as a React alternative. Then their goals and role changed every year, and now they are again promoted as an alternative
Yeah what a waste of collective brainspace that was eh. If they had promoted them as "custom elements are the best way to distribute components!" then I bet they'd have been much more widely embraced by now, by merit of not overselling them.
I remember when web components first came out and there was some hype around them, and just being really confused on what they're actually good for. I think it's really telling that since web components came out there's never been a popular framework, website, or company that has heavily leveraged them.
Funny story, I have a comment chain here from a few years ago with someone who didn’t realize it wasn’t actually a framework. Total woosh. Lumped it in with the other frameworks and dismissed them all in the same sentence.
When you include "No tools" in your requirements, you're locking yourself out of WebAssembly. WebAssembly still requires that you have a C compiler that can target WebAssembly binary format. Zig works well as a compiler for this purpose, even if it's just building C code.
WebAssembly doesn't need to be bloated, I've written a C program that imports nothing, and the resulting WASM file is under 3KB in size, and there's under 10 lines of code to load it up.
I've learned that people use what they familiar with.
At first, I learned and use plain HTML/CSS/PHP and I thought that was good. At college, they taught .NET framework and for some years, that was my go to techstack. Then I started to learn about more languages and frameworks. At some point, it's hard to switch between them
Now I stick with one thing, unless that platform doesn't support it. This also allow me to be a lot more productive since I know most of the thing needed to be done
Sure I can start with vanilla web, or some new framework but it'll take a lot more of time and just not worth it
My main gripe with web components is that while they expose the first half of the tree traversal (from the outside in, via connectedCallback), they don't provide access to the second half, after child elements have been created. (akin to Initialize and Load events from ye olde .NET)
This is the approach I took for my side project website. The idea of installing a framework and dealing with hosting and whatnot just did not interest me.
More importantly, the needs of the site are drop-dead simple so no need to install a Ferrari when all I need is a bicycle.
That’s exactly what I do. The projects are small enough that it’s perfect. But it reminds me how insane it would be if it was one of my professional projects.
"However, this rich functionality comes at the cost of framework and tooling complexity"
this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?
Updating content in raw DOM methods is as direct as:
1. Get the desired node.
2. Write the content.
That is it. The corresponding code is two lines.
But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control.
That is simple, but many people find that simple is not easy.
It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of experience.
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.
the tools are supposed to make u be able to make products faster and more efficiently and iterate faster on business requirements or whatever problem you are trying to solve. you are treating it like its some toy your supposed to fiddle with or something. there is a reason we aren't coding in binary and use functions to encapsulate and abstract away logic. these frameworks are supposed to provide boilerplate so that you don't have to go through the trouble yourself because somebody already solved it so you can be more productive and build on top.
getting a site up and running with vercel is like 20x faster and more simple than hardcoding .html files man.
As someone with a 'full stack' history (ie basic front end knowledge compared to a full-timer on that coal face every day), I do notice a lot of the stuff jQuery does is now native to the browser, like being able to use fetch with promises in a few lines of code, or select stuff with querySelector(All)? or xpath. Then all the nice additions to CSS (and HTTP, no more sprites) that weren't possible in the past and remove the need for frameworks.
I tend to rely on Bootstrap so the layout is reasonable on mobile- but that's purely through my own lack of experience.
But I guess someone with a more intimate knowledge can easily get the idea of building a framework. Then add on all the use cases and feature requests...
Some web pages, particularly traditional media websites are absolute hell holes of bloat, but I guess that's more about their ad serving than lean web development.
No one cares how many pedals you have on your guitar pedalboard. But if you hit one wrong note, everyone in the audience will hear it and talk about it. Playing pedals is primarily for you and your team, not your audience.
I suspect that's where the new React Compiler will eventually head where based on your code it will try and remove as much React runtime as possible if it's not needed.
Just for anyone reading this and wondering what the dependency footprint of React is:
- React-DOM has one runtime dependency (a cooperative scheduler)
- React itself has no runtime dependencies
It's possible the poster above is referring to build time dependencies. This is harder to assess because there are several options. For example, if compiling JSX using TypeScript, this adds only one more dependency.
Am I the only one who (still) does not feel comfortable seeing JavaScript being intertwined into the so-called "vanilla" web in a way that seems more like a hard dependency and not the progressive enhancement we were taught should be the approach for serious public websites?
The page https://plainvanillaweb.com/pages/sites.html uses custom components for all code examples and embedded content. Without JavaScript, it merely shows "enable scripting to view ../XYZ.html" in place of all code examples and demos. Better than having no fallback at all, I suppose, yet still not "navigable".
The fact that it does not even bother to build these custom components on any native element with a similar purpose—like, say, a link that users could follow to see the text document (*), or a plain old iframe (**)—is grim.
Web components are indeed useful for prototyping and personal testing, but are they really beyond the threshold where it is safe to serve them in the wild, potentially harming some users?
(*) I know, view-source: links and embeds are sadly blocked by browsers nowadays. Makes very little sense to me. Someone likely managed to exploit it for some nasty purposes, so now we are "protected", I suppose.
(**) See? In the olden days even iframes were said to have a link fallback inside, for user agents that did not support them.
It depends on the context. What you say makes a lot of sense for web sites, but expecting a web app to use JS strictly as a "progressive enhancement" is IMO unreasonable.
Now, this particular website is indeed a proper website, and so it shouldn't need JS to do its thing. But it's also a website that advocates for a certain way of developing web apps (even if they don't use such terminology themselves), and as such, is essentially a demo for the same.
You're not the only one. I block most subresources by default and was disappointed to see empty figures peppered throughout their articles. I'm learning to not automatically equate advocacy of "vanilla" with advocacy of robustness.
Question - why would you do this in current year? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
Well, one nice thing about doing things this way is that it'll still be as viable in five years as it is today.
I'm sitting on two UIs at work that nobody can really do anything with, because the cutting-edge, mainstream-acceptable frameworks at the time they are built in are now deprecated, very difficult to even reconstruct with all the library motion, and as a result, effectively frozen because we can't practically tweak them without someone dedicating a week just to put all the pieces back together enough to rebuild the system... and then that week of work has to largely be done again in a year if we have to tweak it again.
Meanwhile the little website I wrote with just vanilla HTML, CSS, & JS is chugging along, and we can and have pushed in the occasional tweak to it without it blowing up the world or requiring someone to spend a week reconstructing some weird specific environment.
I'm actually not against web frameworks in the general sense, but they do need to pull their weight and I think a lot of people underestimate their long-term expense for a lot of sites. Doing a little bit of JS to run a couple of "fetch" commands is not that difficult. It is true that if you start building a large enough site that you will eventually reconstruct your own framework out of necessity, and it'll be inferior to React, but there's a lot of sites under that "large enough" threshold.
Perhaps the best way to think about it is that this is the "standard library" framework that ships in the browsers, and it's worth knowing about it so that you can analyze when it is sufficient for your needs. Because if it is sufficient, it has a lot of advantages to it. If it isn't, then by all means go and get something else... again, I'm definitely not in the camp of "frameworks have no utility". But this should always be part of your analysis because of its unique benefits it has that no other framework has, like its 0KB initial overhead and generally unbeatable performance (because all the other frameworks are built on top of this one).
For example - I have a fairly complex app, at least for a side project, but so far I managed to keep everything without a single external dependecy nor any build tool. Now I have to convert it all to react and I'm not very happy about that, I will have to add a ton of tooling, and what's most important for me, I won't be able to make any changes without deploying the tooling beforehand.
Mostly for the virtue signaling. There's something to be said for going with the fundamentals, but people who loudly preach fundamentals tend to be, well...
Frameworks are fine when you just need to get a job done quickly. And they're ideal when you're in a typical corporate code factory with average turnover, and for the same reasons Java is ideal there.
React is the new Java.
But when you need something the framework can't provide, good luck. Yes, high performance is typically one of those things. But a well engineered design is almost always another, costing maintainability and flexibility.
This is why you almost always see frameworks slow to a crawl at a certain point in terms of fixing bugs, adding features, or improving performance. I'd guess React did this around like 2019 or so.
Overly hated on and conflated with frameworks, yes.
React requires very little from you. Even less if you don't want to use JSX. But because Facebook pushes puzzlingly heavy starter kits, everyone thinks React needs routers or NextJS. But what barebones React is, at the end of the day, is hardly what I'd call a framework, and is suitable for little JS "islands."
Because of the ridiculous complexity in their setup and operation, their glacially slow performance if it is actually written in JavaScript and not a non-web platform language that compiles to native code, and their extreme volatility and instability/pace of deprecation.
The benchmarks I've seen actually show web components being slightly slower than the best frameworks/libraries.
The idea is: no build steps initially, minimal build steps later on, no dealing with a constant stream of CVEs in transitive dependencies, no slow down in CI/CD, much more readable stack traces and profiling graphs when investigating errors and performance, no massive node_modules folder, etc. Massive worlds of complexity and security holes and stupid janky bullshit all gone. This will probably also be easier to serve as part of the backend API and not require a separate container/app/service just running node.js and can probably just be served as static content, or at least the lack of Node build steps should make that more feasible.
It's a tradeoff some people want to make and others don't. There isn't a right and wrong answer.
The problem I found is that my full-SSR project doesn't use any Node.js at all, and it works fine for everything but CSS, because in order to use includes and variables I need a CSS compiler.
For example, I use a CSS library that defines a very nice style class "alib-link" for all links. I would want to set it for all <a> elements, without adding `class="alib-link"` all the time. It's easy with a CSS-preprocrssor, but how to avoid using one?
If you do this with no build step, how can you have cache busting of your component files? or is there an alternative solution that doesn't sacrifice on performance (but also doesn't serve stale files or an inconsistent version between files)?
I tried to build an app with web components but honestly, the DX is quite bad and I abandoned the shadow DOM for light dom until I abandoned the vanilla tech stack entirely and moved the project to React. It is just so much faster to develop in React in comparison. Also when stuff goes wrong with components they many times just fail silently with no errors given to the console.
You have such a great community with big, very well thought out libraries like Tanstack Query that is pretty nice to work with. I can have backend and front end code in the same repository in a simple way and reuse code.
I also have the project in Phoenix Liveview which is also a much nicer way of using components. The thing is I don't really know which tech stack is gonna win so I made a small prototype in both to see different advantages / disadvantages.
One thing is clear tho, pretty much everything is better than using vanilla components and it's really sad because I really do want to use vanilla components and I want them to be good.
One recommendation is to change the mental model here. In my eyes it isn’t “don’t use a framework”, it’s “build the framework you need”. It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react. My SPA non.io is built like this - one master component that has class functions I want, and one script for generic functions.
Although I do think there is merit to "light" frameworks such as Astro, with its scoped styling and better component syntax. But at the same time, independence is also important.
I started something similar with https://webdev.bryanhogan.com/ which focuses on writing good and scalable HTML and CSS.
Man, the example web components seem to work great if you wish to hide data from scraping and search indexing... And if you try to work around this, you end up with something very very similar to https://stimulus.hotwired.dev/ .
Is there any clean solution to the innerhtml problem in plain JavaScript applications, that does not require a virtual DOM or component lifecycle AND has Jetbrains IDE support?
I'd like to use lit-html but Jetbrains does not support it - very annoying.
Was wondering what you meant so I looked up "the innerhtml problem" and the top result indeed does list quite a few issues with appending to innerHTML that can be easily avoided. For anyone else interested: https://stackoverflow.com/a/33995479/1201863
Although I'm liking the use of javascript classes, not for any technical reasons just that it's a defiant middle finger to the React crew (who you now no longer hear from) that cancelled classes.
As a react dev I find this fascinating - in the same way I was fascinated by the foraging walk I went on the other day - but was SO HAPPY that supermarkets exist when I saw how much effort it is.
> The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off.
I agree. (This should also include CSS, TLS, cookies, and many other things; I often disable CSS, and it should work just as well if CSS is disabled just as much as if pictures or JavaScripts or cookies are disabled.)
However, there are some uses where JavaScripts may be helpful e.g. if a web page has a calculations or something like that implemented by JavaScripts; but that is not an excuse to prevent the documentation from being displayed if JavaScripts are disabled. They should really make documentation and as much other stuff to work even if JavaScripts are disabled (and, depending on what it does, may provide a description of the calculation or of the rules of the game being implemented, or a link to API documentation, or something else like that).
Pictures also might be useful in some articles (but are often overused); but even then, if the picture is not displayed you could use an external program to display them. However, if it can be explained in the text, then it should be explained in the text if possible so that even if you do not have a suitable program to display that picture (or do not want to display that picture, e.g. the file size is too big; or maybe you are using text to speech or a braille display or something else like that) then it will still work.
TLS also should not always be mandatory, either. For things that require user authentication, and for writing, it can be useful to be mandatory (especially if you are using X.509 client authentication; this will be better than using cookies or other methods for authentication, anyways); but for read-only access to public data, TLS should be optional (but the server should still allow it in case the client wants to use TLS for read-only access to public data too).
No, TLS should always be required. We should be moving away from plaintext anything on the wire, if for no other reason than privacy (but also for integrity, injecting scripts into an HTTP response is a nasty attack surface).
my issue with doing web development without frameworks is how to best manage the app state. In react things like redux help with this, but in my experience state management becomes a mess without frameworks, maybe it's a skill issue on my side I don't know.
My business doesn't use React anymore, and I'm so happy I don't have to do pointless maintenance.
A side note, included in my repository: you update your element's innerHtml from the constructor, not from the connectedCallback. MDN and the web standards seem to be inconsistent on this, and elsewhere people write about it, too.
People talk a lot about data and binding, etc. I think it's weird, it's like people have forgotten how to just use setters. You can call a render() method from a setter, and it does the same thing WebKit et al do when you call an internal setter on an HTML element.
I don't see the value in these frameworks anymore.
The section on Web Components is... teeechnically correct. Unfortunately, it's missing a lot of information on hidden pitfalls of doing things in certain ways
As an example, the examples on `connectedCallback()` don't guard against the fact that this callback gets called every time the element gets inserted into the DOM tree. This could happen because you've removed it to hide it and then added it later to show it again, or it could happen because you've moved it to a new location in the tree (different parent, or re-ordering with respect to its siblings). Or maybe you're not manipulating this object at all! Maybe someone else is moving around a parent element of your custom element. Whatever the case, if you're element's ancestor path in any way gets disconnected and then reconnected from `documentElement`, `connectedCallback()` gets called again.
That means that you have to spend extra effort to make sure anything you do in `connectedCallback()` either gets completely undone in `disconnectedCallback()`, or has some way of checking to make sure it doesn't redo work that has already been done.
There are some other pitfalls involving attributes, child elements, styling, behavior with bundling, etc., that they never really get into. And generally speaking, you're probably only going to find out about them from experience. I don't think I've seen anywhere that goes into Web Component best practices.
Which is a shame, because they are incredibly powerful and I enjoy using them quite a bit. Now that my company has decided to go all in on React, I think they've only really seen the beginner path on both. Web Components as a beginner look harder than React as a beginner. Once you start actually building apps, I find they actually end up having to do largely the same level of manual shenanigans. But I find that I'm doing manual shenanigans to work around React, whereas with Web Components there isn't any magic to work around, but there also isn't a lot of "help" that you'd end up ignoring in most cases anyway.
In theory, “de-frameworking yourself” is cool, but in practice, it’ll just lead to you building what effectively is your own ad hoc less battle-tested, probably less secure, and likely less performant de facto framework.
I’m not convinced it’s worth it.
If you want something à la KISS[0][0], just use Svelte/SvelteKit[1][1].
Nowadays, the primary exception I see to my point here is if your goal is to better understand what’s going on under the hood of many libraries and frameworks.
Any attempt to show that vanilla web components are somehow a viable solution always read like a parody.
The boilerplate, the innerHTML strings, the long list of caveats, the extra code to make basic things like forms work, manually attaching styles etc. etc.
The site positions itself as advocating for simplicity and minimalism in web development—stressing plain HTML, CSS, and JavaScript—but then pivots into building the entire project using React. That’s a contradiction.
If the goal is truly "plain vanilla web," introducing React (with its build tools, dependencies, and abstraction layers) runs counter to that ethos. A truly minimalist approach would skip frameworks entirely or at most use small, native JS modules.
So yes, it's philosophically inconsistent. Want to dig into a better alternative stack that sticks to that principle?
I’m building a plain vanilla web application right now.
The main reason is I want direct control of the DOM and despite having 10 years or more react experience, it is too frustrating to deal with the react abstractions when you want direct dom control.
The interesting thing is that it’s the LLM/AI that makes this possible for me. LLMs are incredibly good at plain JavaScript.
With an LLM as capable as Gemini you rarely even need libraries - whatever your goal the LLM can often directly implement it for you, so you end up with few of no dependencies.
Ah. Thanks, that hint pointed me to [1]. Seems like it's been supported by every major browser since 2021, and only specified in the upcoming ECMAScript 2026 spec.
Be wary of building a website without a framework to abstract stuff like DOM usage and page generation. Raw webdev is hard, due to lots of compatibility issues at every level (CSS, HTML, JS) and are moving targets. You shouldn't even try it until you understand protocol design and have implemented some medium complexity standards like IRC and a basic DNS client or server.
I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?".
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.
I've found that "send me a spreadsheet and I'll upload it" isn't a great user experience. It's just a big pile of cells, with no documentation (which they wouldn't read anyway).There are a billion things they can do wrong, and they get no feedback on it until I email it to them. They don't know what the options are for any field, and it's easy to enter a nonstandard value. A typo in a header row can lead to data loss with no errors.
There are times when it's the easiest way to handle things, especially for experienced users. But I find it a massive hassle to maintain support for every possible mistake the user can make.
I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one?
I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.
There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you.
> I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.
People romanticize businesses like this but there’s a reason you’re not posting the link. It only works when it’s for a small group of people who are in the know and refer trusted buyers.
It’s also trivial to set up any 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.
> 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.
> 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.
> 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.
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.
> 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).
The business can just make less money than they would if everyone paid (which is, as you say, impossible). Costs and prices are linked in some markets, but it's not a natural law.
> 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).
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…
For this to work, you need society as a whole to participate in enforcement.
But we have created an environment where this kind of thing is unthinkable, not even because people won't do it, but because they will only create legal trouble for themselves if they try. So the modus operandi for your average citizen in Western societies in general and US in particular is to not get involved and leave it all to law enforcement.
> brass tacks
An interesting story behind those:
https://blog.lostartpress.com/2023/02/07/john-wilson-1939-20...
> 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.
Payment after receipt is very common in Switzerland, but fraud is presumably rare. Your name would probably go on the debtors register and that's the sort of bad credit history you don't want to have. At some point the police/debt collection is involved, they get sent to whatever the address is and so on. For the average person it's not worth burning your name and address for a free spokeshave.
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? Is there a trusted relationship? A threat of legal action?
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.
> 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...
Sad to hear. Thanks for the info.
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.
Cash on delivery (CODl used to be popular in the US for a lot of the mail order junk on television in the 70s to early 80s. The rise of the credit card for normal people was a cause of its decline because people now had a reliable way to pay over the phone when ordering said junk.
https://en.wikipedia.org/wiki/Cash_on_delivery
> You can simply not pay if you choose not to.
It's only a matter of time before this seller falls victim to a scammer - once they're found. I used to work for a book publisher who started doing their own e-commerce, and at the time one of the payment methods was a "pay later" one that predated the internet ("acceptgiro"). It only took a few months (if that) after the first sites went live that someone placed an order for a few hundred euros worth of books and had it delivered at a storage unit address. We scrapped the pay later payment option for orders over a certain amount then, and I'm sure later on the pay later option was removed entirely in favor of pay in advance methods.
There's newer pay later schemes now (Klarna IIRC) but the risk and debt collection falls to this payment provider. Of course, they got in legal trouble recently because they're a loan / credit company but didn't present the user with the right legalese for that.
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.
As in urns for ashes, not Universal Resource Names.
urns, not URNs
In your case, perhaps a shopping cart could increase conversion, perhaps not.
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.
> if you squint and look closely you'll find interesting people doing interesting things all around you
Yep :)
> 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.
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
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?
Lets first not forget: 1) people been doing business with these "ugly" green textmode screens, long before web; 2) the web existed in a very reasonable form pre-www as FIDO, GOPHER, and of course IRC & EMAIL.
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.
> 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.
With that title I didn't expect Javascript to be part of the equation. To me "vanilla" is CERN's HTTP+HTML.
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.
There are some secessionists - Gopher is still alive, Gemini - but alternatives have a hard time to compete with the content companies can provide apparently for free. Most of the content we want costs time and/or money. Content creators can be fine with contributing from their own pocket, but this is not really sustainable. User sponsorship (donations via Paypal, Patreon, Kofi, ...) don't work well either.
Also, since the supporters of the alternatives are generally supporters of freedom (who isn't? Well, people don't reject freedom, they are "just" making compromises), they have to deal with illegal content and other forms of abuse.
So there are 3 problems an alternative web must solve: protocols, moderation and repayment.
> 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.
In fact, I've gone the opposite way- my work has an internal cafe with a menu website that takes a lot of clicks to see everything.
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).
I have a similar experience with providing users with excel files, but would also like to add that in a lot of business, the number 1 competition for a web application is the good old excel file (or its modern cloud version), and it's sometimes a challenge to beat.
Yeah, I've spent 2 years in a job trying to build a UI to beat an Excel file. Did not succeed.
> 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.
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.
> 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
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?
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.
> 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.
This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.
>> 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.
Generally in the excel load process, one does sanity checks. However your database can do all the checking if you so wish. CHECK() gets you quite far. If you have PostgreSQL(PG) or some other advanced SQL database, you can even go forth with functions and views and triggers and everything else.
We execute Python in our PG database and do testing through PGTAP.
100% agree that we’ve collectively overbuilt a lot of B2B SaaS admin surfaces. I've also seen situations where a simple Google Sheet + cron + db insert script beat out six months of frontend sprinting.
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.”
I agree. Having seem enormous amounts of effort wasted on implementing fancy web apps by Digital-first consultancies (they reject BAs, but substitute designers) in the B2B space, I think there does need to be more education for the people who procure this stuff (especially in government) who get ripped off routinely.
> 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.
> 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.
Excel files can work surprisingly well in B2B scenarios where there's a high degree of trust. At a retailer I used to work at, we ran an impromptu Christmas gifts team in December each year, where corporate clients could put in a large order of gifts to be sent to their employees. Rather than build a website for it, we just sent them over an Excel file they could fill in with the name and address of each employee, the gift they wanted to receive and a message for the label. They'd send the file back to us and we had a process to validate the data and load it into our system. It sounds primitive, but it was much more time- and cost-efficient than faffing around with a custom application that we would only use for one month per year and which the clients probably wouldn't enjoy using anyway.
<<Wait, it's just a bunch of Excels?>> <<Always has been>>
Well, sometimes it was DBF files (of dBase / FoxPro / Clipper fame). The first app I ever wrote for money was a thing that prompted you to insert a floppy with a .dbf consisting of a list of recalled products and append it into a local database (another .dbf!) that would let the user query the whole thing. The floppies were obtained by means of a person walking to the local office of the corresponding government entity where they would hand a blank floppy and receive it back with the copy of the most recent updates. That was late 90s.
This evolved through multiple iterations as the government end of it did. At one point you no longer had to walk there physically; instead, there was a dial-up endpoint running UUCP that could be used to fetch the file. Then they found out about Internet, and it became a website with the file, now .mdb (MS Access) rather than .dbf. I rewrote the app in .NET/WinForms, since it was much easier to do all those things from it than to try bolting it onto an old TUI DOS app.
But it was still basically the same table with the same schema by mid-10s, and my app was still chugging along. I wonder sometimes if some iteration of it is still in use today; wouldn't be surprised if it were.
I think of something similar every time I use the Uber Eats 'track order' screen. All I need is a simple textual history:
Having a live location of the delivery person makes total sense here though.
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.
Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.
> so if you have their location you can easily tell them how to get to you.
So you work in logistics support, but you pay to do it?
Yes. I’m happy to do whatever makes the most sense in any given situation. I have never in my life thought to myself “I could easily help solve this problem and make everyone better off, but I will refuse because problem-solving is work and work is only for employees.”
You want pizza or not?
For that, I would propose a feature where I can mark the directions to my home from a well known checkpoint on a map, one time. If the rider deviates in the last mile, they get notification. If they continue to deviate, I get a notification. The solution is not for me not constantly monitor the rider's location.
As this thread is about over engineering solutions, I can't help but wonder if this is satire
This is how 100% B2B worked before there was B2B SaaS, and it's still how 99% of B2B works today.
Yep. EDI and FTP.
Some even still use textfiles to exchange order information on a jointly used ftp server, where the most common error is that access happens simultaneously.
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’ve never felt more useless at work than when I was told to integrated with a new React self-service portal. No one actually wanted to build things for it or use it. It was the pet project of a new CIO. I think it fell over under its own weight in under 2 years.
If that's the most useless thing you ever did at work, count youself lucky.
Especially for internal tooling that is little more than CRUD, I find the web to be most useful when a consultant is brought in to build it once or when an internal team can't be allocated to help maintain it.
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.
I moved to south east Asia and the phenomenon of a "hotline" openend my eyes.
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.
I'm thinking about why this is not really how we do in the west. Would customers even want to get on the phone? I think my initial reaction if I was to contact a business through a hotline is that on the other side of the phone it will be a massive call center rather than the business directly which would make me cautious.
Just the fact that you've assumed a phone call highlights the difference in culture. It's done over text!
Can it work that way? Of course.
But just because it works that way there, doesn't mean it's right. There's nothing about SEA that implies to me the pinnacle of operational efficiency.
In south east asia, people dont' have very good phone or even smart phone in that matter, txt msg makes sense. The same to many african countries where dumb phones are still dominant.
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
This is some excellent first-principles thinking. Sort of like resisting the next team hire until it's unbearable, keeping the user out of the browser until it's unbearable
no no no.....what you people really need is just an ai chatbot that simply generates your crud app/interface/store/whatever on the fly, so you don't even need excel or anything at all and the internet is just one big open vector database big brain. b2b, saas, excel, admin roles?? haha whats that?? and then we just relax outside in the grass hugging trees and smoking pot or whatever like in the 80s.
Weirdly this is something similar to what Satya Nadella said.
> 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...
Except this is pure fantasy and AI is uniquely unreliable and error prone.
It sounds like he’s already smoking pot.
"Realistic Diction is Unrealistic"
Or
"If you ever want to make someone look dumb, quote them verbatim."
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code.
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.
I think that this comment is a great example of the total disconnect these conversations always have.
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.
Many years ago—2002!—Joel Spolsky wrote this:
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.
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.
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.
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).
That was one of the most interesting reads I've read in a while, thanks.
So much great and timeless stuff was written in the 2000's, it's great and should be part of everyone's read list. Another one that's still pretty timeless is https://randsinrepose.com/
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 work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework.
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.
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.
But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".
Maybe. Personally I haven't come across this phenomenon. But I haven't worked on this type of system in a very long time, so it's probably different perspective from different experience.
Oh I was hired because I’ve been here before and know what to do. It’s fast becoming a career specialty lol
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.
> 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
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.
MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.
This is doing the same thing described in the GP of your comment.
If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.
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??"
> Doesn't this just change into /../
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.
Thankfully, there's a bunch of great and "easy to get going" languages now that __also__ have types (or optionally encourage them) that the "don't have types" thing isn't as much of a forced issue anymore (though engineers can still choose to go type-free and eventually face the wrath of lack of types in a large-scale project)
>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.
Absolutely, and this sort of thing happens in large companies as well.
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.
> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+.
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.
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.
I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.
On the third hand, some people use React and some framework to write static web page...
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.
Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer.
Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static.
I think what you’re really complaining about is that people use React for static content and don’t statically render it first. That is sloppy, I agree. But it’s not React itself that’s the problem but rather the developers who don’t care what they are doing.
In theory, you can completely statically render everything. In practice, every static site I've seen built with React also uses dynamic client-side components, either as a prerendering mechanism, or because there are dynamic toggles and things on the site that are easiest to build as React components. This usually means that a lot of excess Javascript gets loaded on the client that isn't usually necessary.
The islands/RSC work seems to offer some improvements to this, but most of these websites still include a full copy of React on the page to essentially do what the speculation rules API and a `<dialog>` element could do just as easily.
HTML will be around long after React is dead. What guarantee does a React codebase have that its toolchain will still work in 5 years? We've seen build tools come and go, whole approaches deprecated. What if a security update requires upgrading to a non-compatible version of React, therefore necessitating a considerable refactor?
Meanwhile, the original Space Jam website still renders perfectly.
The standards are superior to the frameworks built on top of them. Abstractions come and go, but web standards, once adopted, have a solid track record of sticking around.
There is significant path dependency in either direction.
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.
Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.
Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.
It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.
It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.
Until you have a definitive answer, err on the side of simplicity.
You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
Success for the current requirements? Or success for an imagined future?
For an imagined future.
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.
> A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.
—John Gall
I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.
Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?
Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?
How is it any different to choose a web application framework from the start when building a web application?
We have a fundamental difference of philosophy.
What is your philosophy?
You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
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.
The primary use case for these large frameworks is hiring.
There's a shocking amount of people who don't know that vanilla JS is a thing... They only know React...
haven't observed this at all
It's mostly younger people
> it doesn't require them because it's a blog.
A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same reason than people choose IBM: nobody get fired for choosing IBM / React.
[1] https://github.com/mickael-kerjean/filestash
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...
> one of the key ingredients that in my experience really call for a framework: coordination between a large number of people
Keep going, you might just end the whole debate in this thread.
Fully support the comment.
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.
We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies.
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/
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.
Sites vs. applications. It's important to know which you're building.
I feel this about just about every k8s discussion that comes up.
I kind think that if your discussing tech about the web you need to include the scale and your experience.
Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here.
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.
> how your frameworkless design handles a dozen different features that their use case absolutely requires
Would you mind sharing one or two kind of feature that are required by these development team ?
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.
Holy moly, that's pretentious.
I was genuinely curious because i never faced the kind of issue a web development team would have, it wasn't about counter argumenting.
You could have just said "x and y".
I think that this comment is a great example of the total disconnect these conversations always have.
I just pointed out that frameworks are not always necessary.
>> In this case: this is a WordPress blog.
No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers.
If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.
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.
Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from:
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.
Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are.
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.
> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining
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.
>that their use case absolutely requires
This is where those people and teams are wrong.
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.
> Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work
> In this case: this is a WordPress blog.
If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
Well, at least you found your category.
While I think your page is excellent and loads great, I don't think this is related to the approach described by TFA. You're using the biggest framework around: WordPress. You're just static rendering it. TFA is talking about no build tools at all, using modern web standards, and specifically nothing requiring preprocessing. "... just an editor, a browser, and web standards" is a quote from the page.
> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code
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.
That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not deleted, which is a big if.
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.
This is spot on. Load times do not matter for the kinds of apps that:
* 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.
Nice site, I found some interesting stories.
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.
Congtats! Usability should be a first class citizen. Instead we seemed to have perfected the art of loading screens, "hydrating" components, time & power consuming animations and annoying modals.
One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.
SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.
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.
And frankly, most big sites in my experience break bfcache. For instance: YouTube, Gmail, NYT, steampowered.com, CNN. All have broken bfcache in Chrome.
That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.
That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side)
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.
No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache.
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.
Not sure if it's no-framework related, but navigation back/forth is sometimes broken: the url changes immediately, but the page doesn't update and stays on the same article.
Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning
I recently did a ShowHN post for my browser-based screen recording web page side project. 100% vanilla, with added wasm-based ML shenanigans. It really is amazing what functionality can be built into a web page without resorting to framework support!
https://news.ycombinator.com/item?id=43960434
Fantastic website, really happy to be able to finally read interesting stories and news about the tech scene where I work, in Vietnam
Took me off guard too :D I didn't expect to click on a random link on HN and see an article about my home country
Ahhh, the beauty of WordPress-generated static pages.
So you are the guys behind this amazing news website. What made you build this and is the target audience American? If you don't mind me asking, how are you guys monetizing this? Is this a funded venture or bootstrapped?
Rest of World looks like a fantastic news website I was not familiar with. I just spent a half hour reading a whole bunch of interesting articles there. Well done for helping build it - its super fast from Australia.
> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code
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.
shoutout to Mithril! Has always been an under-appreciated gem.
maybe you'll be interested to know v3 is in active development
https://github.com/MithrilJS/mithril.js/pull/2982
My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction.
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?
Does your "nice reactive table with search" retain its current state (including scrolling!) if I click on a link that opens another page, and then back out?
Does it let me link to page N of results?
As a user, I find that, in practice, it's these kinds of things that frustrate me far more than the lack of instant reactivity, whereas simple form with a submit button and a paginated table below works just fine.
Increasingly, this is actually an argument in favor of vanilla web components.
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.
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
Your primary image is over 200kb. 100kb is nothing.
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.
I believe the topic is front-end frameworks. WP is used as a CMS but the entire front end is built from scratch.
As a fellow vanilla-fan: If this shows anything, it shows how bloated modern web development has become. Your page is snappy as hell.
Modern static content web development is in some of the best health it's ever been in with the likes of Astro.
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.
What do you even need JS for on that site? It looks like it should be doable with plain HTML.
Blazing fast. Wow!
I thought this was sarcasm, so I loaded the page, and yeah, that is an insanely fast cold load time, and even more impressive once the resources are cached.
I love Rest of World! Great work!
Kudos, the site feels really snappy and I’ve definitely come across the journalism before.
Any sharp edges to this approach?
In my experience, the sharp edges are browser compatibility issues, and I've been gratefully avoiding them for years by using jQuery.
I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code.
Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.
No user cares about 100K.
They care about time and they absolutely do care. If your giant virtual DOM mess takes 10x longer to respond on every user interaction they will absolutely notice. It’s just the developers that don’t care because deviating from the framework puts their job at risk.
> 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?
10x longer than not using that framework and yes, I do realize that.
what? that is impossible
Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.
I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.
Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format.
HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.
Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.
Yup, the web is a thoroughly mediocre application platform†, but the world’s best application distribution platform.
†I know this claim will rub some people the wrong way, but if you compare the capabilities of web tooling to build rich application UIs against desktop app tooling of even 20-30 years ago, there’s no comparison. The web is still primitive, and while JS and CSS are improving at a good pace, HTML is almost frozen in carbonite.
> 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.
It's both, really. HTML makes it really easy to do "corporate branded" fancy buttons, but you still have to jump through hoops to do something that could be done with a database and the stock data grid widget in <10 lines of code in VB or Delphi.
Are we really comparing 2 tier to three tier here? ( With the web effectively 3 tier by default ).
That old VB code that queried the database directly wouldn't work well over a non-local network.
ie there is a bit of apples and oranges comparison here.
You do have a point, but then again, think about how many corpnet apps are web apps these days, even though the network is local.
Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason?
I also don't like the state of the web.
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, 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.
>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.
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. It's probably the best upgrade paths of any of the libs I work with.
But you're not wrong about there being many ways to write components and manage state.
And RSC is a mess. But thankfully you can keep pretending that doesn't exist.
> 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.
> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument
To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.
Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.
Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.
For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.
I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.
How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.
But you don't have to learn "framework after framework". Realistically, at a well-organised organisation you learn React and that's it. You don't worry about the compilation and minification and what have you, because you have a working build system that does the build and does the source maps, and you have a culture that fixes these things if they break or become flaky.
As someone who stepped away from web for a while and came back to it a couple of years ago, a straight React or Next.js application is so, so much nicer to work with than old-school webapps were. It feels like the web has finally been dragged kicking and screaming into a world of regular software development best practices. JS isn't the best programming language but it's a proper programming language and it does the job, I'm continually baffled that people would rather contort themselves with the sub-Turing tarpit of CSS and what have you instead of just using some libraries, writing some code, and actually solving their problems in what's usually an objectively easier and better way.
Why would a language meant to focus only on styling need to be Turing complete?
At 100s of millions I’m assuming you have something closer to a static site than an application?
It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.
I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly.
The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology 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 think that using browser as the way to, essentially, deliver desktop LOB apps to the users seamlessly, updates and all, makes perfect sense. Writing those apps in HTML/CSS/JS, not so much - it's forced on us because that's the only stack that browsers have historically supported, but even with all the app-centric additions to HTML over the past two decades, it's clearly not designed for them first and it shows.
I hope that, in the long term, wasm and canvas (or something similar) will gradually take over this niche. Frameworks like Avalonia already let you write a desktop app and then surface it in the browser, today. This stuff is still rough around the edges, particularly wrt accessibility, but there's nothing unsolvable there in principle, it just needs time and effort (and money).
Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.
Both were absurdly slow and resource intensive.
Nothing got my old iMac G5 whipped into a frenzy like loading a page that had Flash on it somewhere. I’m not kidding when I say that there were many areas in World of Warcraft, a full-fat seamless open world 3D MMORPG, that didn’t make its fans as angry as Flash could manage to.
I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.
I wonder what could have been if it had had the same effort applied to optimize it as JavaScript did.
It probably could’ve been great, but unfortunately such a thing would’ve been unlikely at best with Flash being solely controlled by Adobe. Not only does that company have a disinclination towards optimization that persists to this day, but with there having been no alternative implementations of Flash, there was no possibility of other organizations taking up that torch or for there to be competition between implementations driving things forward.
The flash player leaked memory. The longer-running the app, the more noticeable it was. I believe this is why Adobe Air (flash player packaged as deliverable) failed.
As for the speed of the flash player itself it was quite good.
My experience circa. 2008/9 was it was fine (used it on a commercial app in lieu of good enough web standards for the featureset). It was fast and reactive for an app-like experience.
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.
It was OK on Windows. It sucked on any other platform. And it was a security disaster.
Flash was a lot of things, but also, at the same time, neither of these things. (You could come across poorly coded and thus poorly performing apps, but that wasn’t the standard).
Modern day SPAs are far, far worse offenders when it comes to smothering resources.
Just like browsers now.
> deploying native applications is simply too costly.
I do not understand why people hold this impression, especially in corporate environments.
Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed.
Many desktop applications are written in .Net so you don't even need to install the runtime because it's 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?
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
You could of course also make your desktop app auto update without offering a way to refuse. Or you could make it display an error, if the user accesses it without being at the newest version, and block all further interaction. Those are considered impolite, but it seems you are doing it anyway in your web app already.
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.
Some people should probably only be given thin clients, because they are too inept to be allowed to handle anything else.
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?
The web browser is not some magic tool that is always guaranteed to work. Group policy alone can wreck total havoc on web apps on all the major browsers.
This would be noticed immediately when all of the workers under the group policy try to access their email in the morning
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.
You can still do system wide deployments with .NET Core, or .NET 5+, as you prefer to call it.
https://learn.microsoft.com/en-us/dotnet/core/install/window...
Of course. I was strictly refering to .NET preinstalled in Windows as per the comment I replied to, which I believe only applies to Framework 4.8.
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.
It doesn't usually happen (on Windows but realistically elsewhere too) unless you publish an application as self-contained.
To be specific, .NET install is version-aware and would manage those side by side, unless the destination folder is overridden.
> 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.
> it's preinstalled on the operating system.
Not on my computers. At home, or at work
Not going to lie, that's a pretty out of touch opinion in the current decade, where most software feels an order of magnitude slower and less reactive than a mechanical device made 120 years ago.
Most of that software are bloated SPAs that somehow manage to be slower than a complete page reload of any website or app, that is rendered server side using any traditional web framework statically rendering HTML templates.
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.
You can get smooth transitions with just css too with @view-transition https://developer.mozilla.org/en-US/docs/Web/CSS/@view-trans...
This feels like bringing the annoying transitions people used to use between slides in PowerPoint to the web. There's nothing smooth about the transition in the linked demo, it's quite jarring.
Bring back the <blink> tag.
Worth mentioning @view-transition is still not supported in Firefox.
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.
The view transitions can even do most of the in-page or cross-page animations marketing wants. Just with way, way less code or things to break.
https://m.youtube.com/watch?v=jnYjIDKyKHw
Even so you can do insanely simple refreshing dynamics with CSS and JS without importing any npm packages.
I have a few sites that aren’t that complex, and I use JS to run a PHP file and populate the results in a div. It appears reactive, but it’s dead simple.
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.
Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime.
I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity.
Edit: holy shit y'all do not like the earnest approach to technology
Oh no, you're part of the problem :(
yes, probably, even maybe
But what's the problem again?
"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted
Ok so where is the sensible subset of the runtime we're supposed to use? Why have browsers not excised the rest?
Backwards compatibility, which is kinda important on the web. It should be possible to build a website and have it just work a decade later.
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.
No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.
That's a code smell. If you're creating the element you ought to already know about it. If you're not creating the element you should inventory them all at once as the page (or component) loads.
If I'm just adding sprinkles of interactivity to a statically-rendered page for something that vanilla is good enough for (i.e. minimal-to-no display logic), I use the expando giving an element an `id` adds to `window`:
You don’t have to call getElementById or querySelector on document. You can narrow the search by starting at a specific node, just most people default into document as it’s already a global.
> You don’t have to call getElementById or querySelector on document.
You do have to call `getElementById` on a document. There can be many documents in a window.
Ah yes correct on getElementById, especially as every id must be unique.
> especially as every id must be unique.
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
Why are you writing it so many times? Write an alias in 10 seconds?
function getId(v) {return document.getElementById(v)}
Dev tools allows $ $$, dunno, make a macro?
But if Brendan Eich wanted us to have a shorter name, he would have given us a shorter name!
We must not defy the system!
Sorry?
JavaScript has functions:
...what is this simple compared to?
Also, it’s a mess separating stuff between react and the server, especially when building with express/node as the backend and the whole codebase together
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
Still the case in most Asian countries where UIs are all Craigslist alike and UX is just shit. People just got use to it. Apparently westerns willing to pay a premium for better UX. It's a culture gap.
Side note but as a buyer looking to buy used tools from locals, Craigslist's UX could not be better. I just started using it recently (after forgetting about it for a decade). Absolutely the opposite of shit.
Though I think maybe if one is using it for a different purpose, like looking for apartments or roommates then that's probably shit.
I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile.
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.
We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...
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 given up on doing frontend work for the time being, because of this crap. I used to do full stack with modern JS, TS, CSS, HTML and whatnot, but then someone made it all go to shit by advertising for NextJS and React, while there was zero interactivity on the whole platform, except for a couple of checkboxes. A few years later, there still isn't much. Some page transitions for when things happen in the backend. I told them in the beginning, that there is not much interactive stuff, but they all got flashed by some one minute low effort Material Design shit, and the idea of the whole thing being "modern" and hiring more React devs. So I stepped away from that while frontend part and let them dig their own hole.
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.
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.)
my firm is government, so do not expect too much... email to {trafalgar battle british general's last name]@rails.cl
Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.
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.
Oh, totally. I myself have written on how GitHub manages to make client side navigation 2x slower than full page reload: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe...
Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...
Even in theory, producing json is just typically slower than producing HTML.
It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.
That reminds me of when I first benchmarked a Rails app and noticed that JSON rendering was significantly slower than the remote database call. No lie, jbuilder was taking about 80% of the request time for about 90% of all endpoints.
Rendering the template or JSON response is the last and probably often the least computationally expensive step though.
I guess the rendering itself is pretty much the same for both SPAs and MPAs, since in the end it can be pretty much the same markup, but the SPA is also at a disadvantage here because it has to combine template/components + JSON to generate the HTML :/
The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.
The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional
React aficionados will disagree though, and tell you to move your logic into the React framework using code.
Page refresh between pages is ok. Lag when updating a form based on your inputs isn't. Frontend UI is like a bigger monitor or faster PC - you may not have known what you were missing, but once you've experienced it it's very frustrating to go back to the clunky old thing.
> Lag when updating a form based on your inputs isn't.
Why not?
> 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.
Unless the page refresh is fast, I tend to agree with you!
People looking to get shit done don't really care but, when they're just mindlessly clicking, they'll hit the back button to the main feed way before the time it takes to fetch a modern framework if your site happens to be the first they hit with that particular version from the CDN.
How do you know? Are you surveying them, including the ones who noped out of your site?
Once you're building custom components in JS files, aren't you basically writing your own microframework?
Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's.
Producing a framework with those features that still fits in a single small size JS file would be great, especially if it can do component updates to shared state (without updating the DOM each turn, hence shadow DOM).
This entire endless conversation would be made SO much easier if we spent some time thinking about the difference between web APP and web SITE. They get conflated all the time and although there is of course a Venn diagram where there’s a bit of crossover, they’re basically entirely distinct beasts that require entirely different technical approaches.
Spend five minutes on webcomponents.org for a depressing ride. Broken links, broken demos, ghost town community and shuttered chat servers. Sponsored and abandoned by the Google Polymer team, or so it appears. Just sad.
Of what relevance is this?
Custom elements are very well documented and work in every browser. Get your server to render html with your own elements in them - your own "island architecture", no vercel necessary.
That some site promoting them is moribund doesn't change the fact they work - and are widely used.
I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being useful to any type of site I run (and I run several disparate types).
Web Components don't solve the problems I do have and add new problems I don't want.
Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.
Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.
Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.
They let you encapsulate the logic pretty much however you want, same as not using web components.
When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.
You can use the shadow DOM outside of custom elements, and can use custom elements without a shadow DOM.
Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.
> rendering an element statically, shipping it, and updating it dynamically via modern JS
Noob question, but what happens behind the scenes in terms of these concepts for web components instead?
I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.
Shoutout to Facet also[0].
[0]: https://github.com/kgscialdone/facet
see also https://github.com/bigskysoftware/fixi
This is a great resource.
IMHO everyone building for the web should understand how it works and know how to use the foundational web stack, leveraging the web platform per se. Then, by all means use a build system and your preferred frameworks at your discretion, remaining aware of tradeoffs.
For my part, one of the things I like best about Remix (/React-router v7+) is its explicit philosophical alignment with leveraging web standards and doing more by doing less (e.g. mutate server data using... the HTML form tag).
I also highly recommend https://every-layout.dev which showcases eye-opening, mind-expanding techniques for implementing performant, accessible, flexible web layouts using only browser-native CSS.
Context: I've been professionally involved with web development since 1998.
I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that.
[1] https://wrnrlr.github.io/prelude/
See also:
Meiosis Pattern: https://meiosis.js.org/docs/01-introduction.html
Mithril: https://mithril.js.org/
This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.
Web components only solve the interoperable, encapsulated component problem.
Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.
Encapsulated - yes.
Interoperable - can you expand on this?
State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
C'mon.
Even something simple like a date picker. Where are you going to store which month you're looking at?
There's state everywhere, and we should not be sending it all back and forth to the server.
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.
Could you explain what you mean by "storing it in a variable"? It's perfectly fine to store data in a variable (that's what most frameworks do in the end), but that state needs to be reactive in some way — updating that state needs to trigger the necessary UI changes (and ideally in such a way that the entire component isn't being regenerated every time the state changes). This is what makes state management so hard.
Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM with unnecessary renders because that's rarely (perhaps never?) the easiest way to patch changes to it, unlike in React where useMemo is prevalent.
Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems.
The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input is another string, what state should you store here? Fundamentally, there's only one thing that's interesting: the input's value. Anything else — say, the class used to set the background colour — is derived from that value. And therefore we always want our data to flow in one direction: the input value is the source, and any other state or UI updates are based on that.
But in practice, it's usually hard to maintain that strict flow of data. For example, you'll probably have multiple sources that combine in different ways to create different derived data. Or you might have multiple different ways of updating those sources that all need to perform the same updates to the derived data. Or you might have multiple levels of derived data.
It's definitely possible to build applications like this — I started out this way, and still use this for simple projects where the state is fairly easy to manage. But as projects get more complex — and as the state gets more complex — it almost invariably leads to weird glitches and broken states that shouldn't exist. Hence why state management is the core of most modern frameworks — it's the most important problem to solve.
N.B. `useMemo` in React has nothing to do with the DOM — React will never thrash the DOM with unnecessary changes, that's the point of the diffing process. `useMemo` is instead about reducing the number of times that React builds its own VDOM nodes.
This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vanilla JS is superior to React in terms of performance.
Of course vanilla JS is superior to any framework in terms of performance. Anything you can do in a framework, you can do directly in vanilla JS. But performance isn't the only issue here, otherwise we'd all be writing a lot more assembly code.
I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too weird. And these weren't even the first wave of frameworks — people had been using state management systems long before then, but they had other flaws that made them difficult to work with in their own right. React became popular very quickly because it had a very simple rendering model, and because it was quick in comparison to a lot of other options at the time. Since then, the field has developed a lot, and at this point I wouldn't recommend React at all.
Listen, if you're losing track of the date in your date picker as implied previously, then I don't know what to tell you man. Not a problem I've ever seen with progressive enhancement, and I've worked on more complex user interfaces than most. I have witnessed people struggle to solve state-related issues in SPAs for even relatively simple problems though, where the solution would be trivial in vanilla js. If it's not for the performance, and it's not cutting down development time, then what is the endless framework churn really accomplishing? Because that js date picker from twenty years ago still works.
> at this point I wouldn't recommend React at all.
Out of curiosity, what would you recommend?
I mostly use SolidJS. It's super lightweight - in many ways, it's just a wrapper around `document.createElement` and a signals library - so you've got a lot of flexibility to use it how you want. It works well for complex web applications, but the library part of it is small enough that you could probably use it for individual widgets on a page and not have too much overhead. The UX is React-like (hooks and JSX), but honestly feels simpler - JSX gets compiled directly to DOM nodes rather than a VDOM abstraction, and there's no "rules of hooks" to learn.
That said, it's kind of niche, which means you need to be more willing to write stuff yourself, so a good mainstream alternative is Vue. Vue is also signals-based and relatively lightweight, but still has a lot of batteries included and a wider ecosystem that is fairly strong. They're also great at taking the parts of other frameworks that work best and implementing them in Vue, but in a fairly considered way. I understand there's also some fairly battle-tested full-stack frameworks in the Vue ecosystem, although I've not had much personal experience of that.
Both libraries are signals-based, which is a completely different reactivity concept to React, which will take a bit of getting used to. But I suspect Vue will make that transition a bit easier - despite SolidJS's more superficial similarities to React, it behaves quite differently.
You were doing ok up until this comment.
yeah idk either I didn't read it carefully enough or it was edited at roughly the same time, because I thought I was responding to something very different.
One place to store it is in a data attribute.
State management, state manage management everybody yells when talking about web dev.
It’s not some sort of mystery, it’s just a global of your variables.
The example given clearly showed components backed by JavaScript. Which means you could implement a state management system in seconds.
But beyond that state management is overrated. I remember when react came out and somebody from face book was describing updating some pending message count number. And how they had trouble with it. The issue was they made shitty code, and the result of react was a solution that hid that shitty code. Because I bet to this day if you profile their example they still had the bug but the state management system silently hid it as a future performance problem.
I get so tired of framework people talking about state as the hill they are willing to die on. State is stupid simple. You use the frameworks because you cannot figure it out on your own and need the giant tool to do it for you.
When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin.
It lets you build full web UIs without touching HTML, CSS, or JavaScript, entirely in Java. The UI logic runs on the server, meaning: no API design, no JSON mapping, no Redux — just a Java object model.
Vaadin follows a true full-stack approach, where frontend and backend live in a single codebase. Combined with Spring Boot or other JVM frameworks, this creates a cohesive Java application—no complex build pipelines, no split repos, and no friction between frontend/backend roles.
What I personally enjoy most is the smooth developer experience: you see your changes reflected in the browser instantly — no manual builds, reload fiddling, or sluggish toolchains - just java and a bit of maven. For many internal business apps, it feels just as “plain” as the old-school server-rendered apps—just with modern capabilities like Web Components and security by default.
(Full disclosure: I work at Vaadin, but I’m genuinely a fan of the approach because it saves developers a lot of headaches.)
This still of programming does not adhere to MVC though, you can't ever swap out the frontend because it's basically merged to the backend and I suspect complex to debug simmilar to JSF.
All MVC (or rather something more modern like MVVM) happens on the server in this scenario, but it doesn't mean that it doesn't happen at all.
A different View + ModelView on top of the same Model could then be used to provide a different frontend if that is ever required (in practice, it probably won't be).
So a pattern is not mandatory with Vaadin, but you can make the UI “simple” changeable with a corresponding pattern of your choice. MVP and MVVM would be good examples of this.
Debugging in the frontend is not trivial, but can still be done with the appropriate setting in the properties (https://vaadin.com/docs/latest/flow/configuration/developmen...)
Seems like this is more for the hobbyists - building webpages for the love of the act. Frameworks are built to be standardized, enforce best practices via their design, and allow developers to 'hit the ground running', so to speak.
No web site is intrinsically valuable - the information and functionality it wraps is what holds its value. Developing the access to that information and function, enforcing correctness, and the timeliness of that development is what frameworks empower orgs to deliver at much lower cost in the present and future, vs. vanilla web dev.
This is the narrative, of course.
In practice, it is sometimes true, and often not.
You can't overstate how often decisions are large orgs are driven by hype, follow-the-herd, or "use popular framework X because I won't get in trouble if I do" mentalities. The added complexity of tools can easily swamp productivity gains, especially with no one tracking these effects. And despite being terrible decisions for the business, they can align with the incentives of individual decision makers and teams. So "people wouldn't do it if it wasn't a net positive" is not an argument that always holds.
I see absolute messes created out of React and associated frameworks. Quite possibly because, “you’re holing it wrong”. Just using a framework is not going to force best practices and it’s very easy to create terribly bloated and slow systems with these tools if you’re not thoughtful.
Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
You can invoke custom methods and pass in any kind of data into them. As in
``` class SomeElement extends HTMLElement { constructor() { super(); }
}// ignore registry stuff
const customElement = document.getElementById('custom-element-id');
customElement.someMethod(42); ```
But you won't learn that from most mainstream custom element tutorials though, for whatever reason.
> <h1>${x}</h1>
Fine for x:string, but what about w:WebWorker?
Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion.
If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like "<h1>[object Worker]</h1>".
If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy for at least 25 years now; iirc .toString() was specified in ES3, which was published in March 2000.
Yeah sorry I meant how would you pass it to another GUI component like we can in React.
If I want in the general case to append a child node to a parent (as here with the h1 as parent and the stringified interpolated value as child), I will in almost every case call parent.appendChild(child), where parent and child both implement Node, which is the parent class of Element. The result will correspond closely to the element tree which would be constructed by assigning a string like your example to some other element's innerHTML. (You are essentially using the browser DOM implementation as a templating engine. As sugar over a lot of createElement calls and piecewise tree construction, this isn't a terrible strategy! The JSX with which you're familiar is a more elaborate and more typesafe solution for essentially the same problem.)
Similarly, these references would be from the JS perspective a POJO with lots of seriously heavy implicit "render magic," so you can use them, as with any first-class Javascript value, as function arguments parallel to but a superset of what React does with its props. See the MDN documentation on Node.appendChild (and Node, Element, HTMLElement, etc) for more: https://developer.mozilla.org/en-US/docs/Web/API/Node
If I want to represent the state of a worker thread in the UI, a problem I first recall solving over a weekend in 2016, the way I do it will end up closely resembling the "MVC pattern," with the Worker instance as "model," the DOM element structure as "view," and a "controller" that takes a Worker and returns an element tree. Even if I'm using React to build the UI - which I have also been mostly doing for about as long - I am still going to handle this translation with a library function, even if my component actually does accept a Worker as a prop, which it actually very likely will since that will enable me to easily dispatch effects and update the UI on changes of worker state. I might define that "business logic" function alongside the component which uses it, in the same module. But React or vanilla, I won't put that logic in the UI rendering code, unless it is trivial property mapping and no more (unlikely in this case, since any interesting worker thread state updates will arrive via message events requiring the parent to keep track in some way.)
Does that help clear up what I'm getting at?
What would you expect that to do, in any framework?
In React, say, I might write
and expect the worker instance to be passed as an object to `MyComponent` as a prop. But with webcomponents, I can't do something like that. will just stringify the worker and pass that string to the `my-component`. To get the worker instance to be passed correctly, I'd need to do something likeSo this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components.
Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?
Yeah, I think the original question was a bit weirdly worded which made people focus on web workers rather than complex data in general.
You can use properties (as opposed to attributes) as I demonstrated, and you can use methods like you suggest, but these are both verbose and limited, and add an extra "the component has been created but the props haven't been fully passed" state to the component you're writing. Imagine a component with maybe five different props, all of which are complex objects that need to be passed by property. That's a lot of boilerplate to work with.
In what way are properties verbose and limited in your view?
You can set them declaratively with a template binding in most template systems.
I showed earlier how it takes multiple lines and some fiddling with DOM to set a simple property with vanilla web components. Sure, if you're using a framework like lit, you have access to template binding, but at that point you might as well use an equivalent framework like SolidJS or Svelte which just skips the web component layer.
Bringing it back to the site, the author does describe implementations of context providers and signals:
https://plainvanillaweb.com/blog/articles/2024-10-07-needs-m... https://plainvanillaweb.com/blog/articles/2024-08-30-poor-ma...
I haven't tried signals yet, but I couldn't see why you could pass in an object with multiple values.
Skipping the web component later would skip then interoperable component part.
With any web component you could assign the worker to a property, either imperatively:
Or declaratively: That's using lit-html syntax, but there are a lot of other rendering libraries that work similarly.Every time I go back to give Web Components another 5 minutes, I hit this point where using lit or a lit-like would take a lot of the pain of the problems Web Components don't solve and have no planned solution for away.
But once I decide to cross the "no dependencies" line, using something like Preact + htm as a no-build solution would also take the most of the rest of the pain away, and solve many, many other problems Web Components have no solution and no planned solution for.
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.
>just adding a method to a class. OOP 101.
You're right, it is just a method call from a class. Nothing interesting or new. And that's exactly why I like it! I like me FE code as boring, unimpressive and as simple as possible.
And custom elements are just classes, so you can do that.
Imagine 50 years ago: “Data passing seems inherently broken in Unix, because all processes must use strings for input and output. Such a model just can't be built on top of.”
Show me a successful GUI made with bash.
Why is a GUI unsuited to stringly-typed data in a way that a CLI is not?
As a matter of fact, Tcl/Tk has been doing exactly that since the 1990s. Of course, Tk has been "borrowed" by other languages, Python's tkinter is well-known. Any language using Tk widgets still has to input options in text form. Obviously that's not particularly difficult to accomplish.
Just an intuition.
Web Components can have properties too, and in fact this is the norm.
Can't put those in templates though. It's a serious pain and completely unnecessary.
You absolutely can put properties in templates. Web component authors do this all the time.
Here's a lit-html template that sets a property:
That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringing me?
How does using a library ruin the goals of the components at all?
The goal of web components is to enable interoperable, encapsulated, reusable components, where how they're built is an implementation detail.
You can use a web component that used lit-html without knowing anything about lit-html, it even that the component uses it.
In theory it is completely an implementation detail, I agree. In practice, it's bloat. If every web component I use in my project might pull in a completely different framework behind the scenes (and worse: if those web components depend transitively on other web components that pull in yet more frameworks), then I now have to deal with all of those different frameworks. Each of them will load more bytes and make my page's startup time slower. Each of them will have their own state management systems. Each of them will have their own approach to templating. Each of them will behave subtly differently in practice.
Why bother when I can just write everything in a single framework?
At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing.
Normal HTML elements don't exclusively use HTML attributes either. Surely you've used button.onclick or element.classList or element.innerHTML?
Being plain HTML is important for the user of the element.
That the element may use a library for its implementation is basically irrelevant.
Hi.
Not in <template>s, the vanilla HTML alternative to this.
This is just a lie perpetuated by the React team 10 years ago
All HTML elements are JavaScript objects that have properties. You can pass arbitrary data to custom elements via those properties.
Look at any modern HTML template system and you'll see the ability to pass data to properties declaratively.
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.
It is absolutely a lie, because web components can handle arbitrary data just at much as any framework.
You're holding web components to a higher standard here in expecting them to take arbitrary data in HTML when HTML itself doesn't support arbitrary data. Notably you can't assign arbitrary data to framework components from within HTML either, so how are web components any more limited?
The original comment was that "all HTML attrs must have string keys and values", which is completely true.
The point of web components is that they create normal HTML elements. So it makes sense to consider what the value of them being normal HTML elements is. You can write them directly in your HTML source code, for example. But if you do that, you only get access to attributes and not to properties, and therefore everything needs to be strings. Alternatively, you can treat them as DOM nodes in Javascript, at which point you get access to properties and can use non-string values, but now you've got to deal with the DOM API, which is verbose and imperative, and makes declarative templating difficult.
Yes, we could compare them to components from other frameworks, but that's honestly an absurd comparison. They're simply trying to do different things. Frameworks aren't trying to create HTML elements. They're trying to reactively template the DOM. It's just a completely different goal altogether. The comparison doesn't make sense.
State management is arguably one of the most important problems to solve. That's why we use React and Vue. You can very easily build complex user interfaces at scale with those frameworks. And you can even take web components along for the ride if you want to. They are partially overlapping solutions for different problems.
some people cheat by using web components but with Lit Elements. https://lit.dev/ . I use it with raw JS without any bundling.
Same. Recreating a basic lit framework is like 300 lines of code
Microsoft solved this with VIEWSTATE in ASP.NET it's perfect, then industry went with everything Ajax and other over engineered frameworks.
I did a small project last week. It's completely vanilla and works great. It's a web tool for writing long threads for Mastodon.
I kept on wondering while making it if I was doing it wrong without any framework. Because that's what everyone else seems to expect.
Splinter, splinter.almonit.club, if anyone cares.
There are caveats and warnings already by the time we've added an `<x-header>`, and the attribute boilerplate seems onerous right from the start. It pains me to say that almost a decade on, I'm still not a fan of web components.
Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data.
I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatibility issues.
On one hand this approach is simple, but on the other hand I dislike treating HTML as a mere string, when it is actually a tree and treating it as such is a huge enabler, that many frameworks miss out on.
If the thing you need to input contains inputs, you're just throwing the user's content away.
Setting innerHTML is dangerous if it is a value that came from user input.
Users will be able to inject cross site scripting attacks into the forms of other users.
Not saying to never sit, just saying to be aware of injection attacks on the front end.
Make sure to sanitize the content before inserting if you use this approach.
> Warning: This is a security risk if the string to be inserted might contain potentially malicious content. When inserting user-supplied data you should always consider using a sanitizer library, in order to sanitize the content before it is inserted.
https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...
Anything with user input I just use innerText.
Or a simple escapeHTML function within the innerHTML - but I prefer innerText in a separate pass, as using escapeHTML as a pattern gives an opportunity to forget to use it.
Beware of xss
Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed.
Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle.
the other way around is near impossible
Can we just use links to go between pages, instead of toggling css display:none on custom elements to show different "pages"? You're replacing browser functionality with custom code. To get on par with browser default functionality, you need to implement a loading indicator, error handling, back/forward button handling, address bar updates, opening links in a new tab when someone middle clicked or ctrl clicked, new window when they shift clicked, etc.
https://plainvanillaweb.com/pages/applications.html This example code does exactly one of those things: update the address bar by setting the fragment identifier. Middle clicking and back/forward buttons work because of that. Error handling (if it were to not just be static content but actually loading something from a server like a real website, which can fail) and loading indicators are not present
Re-implementing browser code in JavaScript is not using the "plain" or "vanilla" web functionality. You're making your own framework at that point
Indeed... I'd critisize SPAs a lot less if they wouldn't try to (poorly) mimic MPAs that often.
And at that point of course we would see some 90% reduction of SPAs, and hordes of FE devs looking for work. There is non-technical incentive at work to keep this bloat in the boat.
> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \<link> tags into the index.html but this quickly becomes unworkable if we have multiple HTML pages. Instead it is better to import them into the index.css (via @import)
You'll eventually need \<link> anyway for preloads, especially with web fonts, since that's the only way to prevent FOUC. Personally I lean on build steps to solve this. I don't like bundlers or frameworks, but I have grown accustomed to custom-building.
I don't find this convincing. For one, many sites don't need web fonts to begin with. For two, the sites that do can use `font-display` or, even better, just let the browser figure it out. Browser developers have spent way more time on these problems than any one of us individually ever will and more often than not, the behavior you get out of the box is already pretty fine.
As a user of websites, I definitely notice when a website uses web fonts and relies on font-display. Preloading them is the only way to avoid jarring changes to the layout. Even if the changes are relatively small, they're very jarring. I won't do that to users of my sites. It's not hard to take care of properly.
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.
That's the point of preloads. You don't need to choose. As soon as the HTML is loaded, the font is ready. You see the HTML immediately (about 10-20ms) with the web font. Win win.
I’m using HTMX and Hyperscript exclusively for interactivity and I’m loving the simplicity of it.
Problems of FAANG are not our problems, yet they've somehow convinced majority of software architects that complexity is good.
My only concern is when I use HTMX/Hyperscript in my FOSS projects will others be comfortable contributing to it even though it has very little learning curve but they have to empty their React cup.
Hum for me vanilla is html+css. If you throw in javascript language, I do not see the 'vanilla' anymore :)
I ended up using hugo + isso (for commenting) and it works very well. I moved to this setup after the wordpress drama, and even if I miss something, freedom has no price: https://gioorgi.com/2024/liberta-come-aria/
Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.
> It's really too bad custom elements got associated with shadow DOM
Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)
> you have to explicitly specify mode: open
The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`.
You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a template child element with a `shadowrootmode` attribute.
I stand corrected!
I'd recommend vanilla TypeScript instead of vanilla JavaScript. The benefits of typing are enormous. You don't even need npm in the critical path either if you use VSCode since it has tsc built in
Nice, but it's no https://motherfuckingwebsite.com/
See also http://bettermotherfuckingwebsite.com/
and https://thebestmotherfucking.website/
Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project
This is the common wisdom about frameworks but I think it ignores the wastage & other side effects around frameworks and the things they make easy or difficult. Many of the decisions made in any framework will represent guardrails for things that don’t apply to you specifically.
I know you’ll “write your own framework” but maybe that’s optimal in some situations - more than we might give credit to at the moment.
I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.
I've built a library to make vanilla webcomponents reactive via a manual render() call that updates only changed nodes:
https://vorticode.github.io/solarite/
I was planning to improve performance more before announcing it. But even as is it beats React and approaches Lit.js on the JS framework benchmarks.
I support the general idea here but just because something is in a browser doesn't mean it's a good formalism.
Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic.
But for internally composing a web application, Web Components are simply awful. They add nearly no helpful features that vanilla JS doesn't already have, and they add bucketloads of extra complexity. You got attributes and properties, and they're mostly the same but kinda not always and oh by the way, attributes can only be strings so good luck keeping that in sync. You got shadow DOM which is great for distribution but super restrictive if you want any sort of consistent global styling (and a total pain in devtools, especially once you go 10 levels deep). You can turn that off, of course, but you gotta know to do that. And plenty more quirks like this. It's just.. It makes lots of easy things 5x harder and 1 hard thing 1.5x easier. Totally not worth it!
If you really want to not use a big clunky framework, but at the same time you have a complex enough app that composition and encapsulation is important, you'd be much better off just making your own object hierarchy (ie without extending HTMLElement), skipping all that awkward web component luggage and solely doing what they do best (tie an object to an element).
Or, better yet, get over yourself and just use a framework that does this for you. Your future self will thank you (and your colleagues even more so).
ps. rant time: If only the web browser people had gotten off their high horse and not proposed the word "Web Components"! If they would've just been named "Custom Elements", which is what they are, then we wouldn't have had 5+ years of people mistaking them for a React competitor.
I haven't started using Web Components, but I was under the impression that libraries like Lit address most of the issues you mentioned for devs who don't want to write their own minimal base class, no?
Sure but this page is about not using a framework. Once you're on board with using a framework like Lit, you might as well use Preact or Svelte or a similarly lightweight framework. The "web component" angle adds no value if it's all internal to your app.
Lit is amazing though. It's fast, lean, and easy to learn. In fact, to my experience, the only things about it that are un-ergonomic, are due to the fact that it's built around web components. Lit without web components would be so much better (again, except if you're building something to be distributed to other programmers on any framework). It wouldn't have a single global registry of components, it wouldn't have that attribute mess, and I bet it'd not need a compiler at all (it doesn't need it now either, but is easier/nicer with it).
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!
I do know what you specifically mean when you say that, but… _all_ libraries are leveraging native browser capabilities, even ones which implement a better component model than Web Components.
> it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect.
It has custom syntax, custom directives that look like regular JS functions but cannot be used like regular functions, a custom compiler in the works etc. etc.
They will keep telling you it just a small library and very vanilla though.
And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative to virtual DOMs, etc. The custom html syntax, IMO, is super useful too (eg it lets you workaround The Attribute Mess by passing data straight to properties, as you would in any sane non-web-component framework). And it's a lot closer to regular HTML than eg React's custom HTML syntax (JSX).
> lit-html is a genius alternative to virtual DOMs, etc
It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.
Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.
Can you explain more about how they're "fighting against lit-html" with the directives? I'm curious what's the struggle here.
> Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
Fair point. I don't personally really care about that either. I guess I just meant to be say that it's not all too custom :-)
It's not really a struggle, but when all you have is a string, how do you enforce certain rules and requirements?
E.g. classMap https://lit.dev/docs/templates/directives/#classmap
--- start quote ---
The classMap must be the only expression in the class attribute, but it can be combined with static values
--- end quote ---
So now you have to figure out which attribute this is called from, whether this particular call is allowed in this attribute etc.
So what they do is they parse (with regexes) their "close to HTML" code into a structure not dissimilar to React's, figure all this stuff out, reassemble actual HTML and dump it to the DOM
Based on the JS Framework Benchmarks (so caveats apply), an app built with lit-html (i.e. just the HTML templating part, as I understand it) is about the same size as SolidJS, and an app built with lit (i.e. the full framework) is about the same size as Svelte or Preact, and at a similar order of magnitude to Vue or Mithril.
So at least in terms of minimal bases, all of these frameworks are much of a muchness.
I really agree with you. Custom elements are a great way to distribute primitives. They start creating friction when trying to actually compose applications.
Perhaps my brain has been addled by a decade of React but as the examples became more advanced, they just looked a lot noiser and more complex compared to JSX or Svelte components.
> then we wouldn't have had 5+ years of people mistaking them for a React competitor.
The browser people literally promoted them as a React alternative. Then their goals and role changed every year, and now they are again promoted as an alternative
Yeah what a waste of collective brainspace that was eh. If they had promoted them as "custom elements are the best way to distribute components!" then I bet they'd have been much more widely embraced by now, by merit of not overselling them.
I remember when web components first came out and there was some hype around them, and just being really confused on what they're actually good for. I think it's really telling that since web components came out there's never been a popular framework, website, or company that has heavily leveraged them.
What about Lit?
Reminds me of this classic: http://vanilla-js.com/
Funny story, I have a comment chain here from a few years ago with someone who didn’t realize it wasn’t actually a framework. Total woosh. Lumped it in with the other frameworks and dismissed them all in the same sentence.
Well, it's totally likely. But there is VanJS, which calls itself a vanilla JS framework, which adds to the confusion: https://news.ycombinator.com/item?id=36067983
Also, http only. Tell me you are a site from the before time without telling me you are a site from the before time.
What value would HTTPS possibly add to the website in question?
It makes it harder for ISPs to inject ads: https://superuser.com/questions/1087669/blocking-the-isps-ad...
When you include "No tools" in your requirements, you're locking yourself out of WebAssembly. WebAssembly still requires that you have a C compiler that can target WebAssembly binary format. Zig works well as a compiler for this purpose, even if it's just building C code.
WebAssembly doesn't need to be bloated, I've written a C program that imports nothing, and the resulting WASM file is under 3KB in size, and there's under 10 lines of code to load it up.
Did you find using Zig's compiler better than using LLVM sans emscripten?
Tinygo is also on my list to try for Wasm.
I wouldn't call a website automatically loading 7 scripts on your single visit "vanilla web" though.
Why? The first line of the site explains:
> An explainer for doing web development using only vanilla techniques. No tools, no frameworks — just HTML, CSS, and JavaScript.
You're thinking of a lightweight site, which this isn't claiming to be.
I've learned that people use what they familiar with.
At first, I learned and use plain HTML/CSS/PHP and I thought that was good. At college, they taught .NET framework and for some years, that was my go to techstack. Then I started to learn about more languages and frameworks. At some point, it's hard to switch between them
Now I stick with one thing, unless that platform doesn't support it. This also allow me to be a lot more productive since I know most of the thing needed to be done
Sure I can start with vanilla web, or some new framework but it'll take a lot more of time and just not worth it
As a framework-enjoyer, I'm finding this helpful to leaf through just to learn about modern web platform tech.
Some good patterns here. An Event with a callback (what you're calling [context protocol](https://github.com/webcomponents-cg/community-protocols/blob...)) I think will prove useful.
My main gripe with web components is that while they expose the first half of the tree traversal (from the outside in, via connectedCallback), they don't provide access to the second half, after child elements have been created. (akin to Initialize and Load events from ye olde .NET)
This is the approach I took for my side project website. The idea of installing a framework and dealing with hosting and whatnot just did not interest me.
More importantly, the needs of the site are drop-dead simple so no need to install a Ferrari when all I need is a bicycle.
Plain vanilla site served from Github FTW!
That’s exactly what I do. The projects are small enough that it’s perfect. But it reminds me how insane it would be if it was one of my professional projects.
Interesting article about ditching frameworks. Embarassingly helpful for someone who jumped rather quick into React after learning js basics.
We have a whole generation of devs and designers who "think in react" and it's going to take some time for the culture to decouple itself.
"However, this rich functionality comes at the cost of framework and tooling complexity" this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?
It’s less complex in the sense that you only need an editor and a browser. You don’t need to install npm or Vite.
Updating content in raw DOM methods is as direct as:
1. Get the desired node.
2. Write the content.
That is it. The corresponding code is two lines.
But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control.
That is simple, but many people find that simple is not easy.
It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of experience.
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.
the tools are supposed to make u be able to make products faster and more efficiently and iterate faster on business requirements or whatever problem you are trying to solve. you are treating it like its some toy your supposed to fiddle with or something. there is a reason we aren't coding in binary and use functions to encapsulate and abstract away logic. these frameworks are supposed to provide boilerplate so that you don't have to go through the trouble yourself because somebody already solved it so you can be more productive and build on top.
getting a site up and running with vercel is like 20x faster and more simple than hardcoding .html files man.
If you want to iterate faster then don’t impose unnecessary abstractions. These tools exist so that otherwise unqualified people can participate.
As someone with a 'full stack' history (ie basic front end knowledge compared to a full-timer on that coal face every day), I do notice a lot of the stuff jQuery does is now native to the browser, like being able to use fetch with promises in a few lines of code, or select stuff with querySelector(All)? or xpath. Then all the nice additions to CSS (and HTTP, no more sprites) that weren't possible in the past and remove the need for frameworks.
I tend to rely on Bootstrap so the layout is reasonable on mobile- but that's purely through my own lack of experience.
But I guess someone with a more intimate knowledge can easily get the idea of building a framework. Then add on all the use cases and feature requests...
Some web pages, particularly traditional media websites are absolute hell holes of bloat, but I guess that's more about their ad serving than lean web development.
No one cares how many pedals you have on your guitar pedalboard. But if you hit one wrong note, everyone in the audience will hear it and talk about it. Playing pedals is primarily for you and your team, not your audience.
When I built my new project (https://teskooano.space) I decided to go all vanilla web for it.
No regrets, except I found myself also building a framework....
This website covers a fair bit of React - in particular, it seems Web Components can be used to create components with both state & props.
One can imagine a cross-compiler so you could write React, but have it compiled to React-free javascript - leaving no React dependency in production.
Would be a lift, but looks superficially possible.
What are the blockers to this?
I suspect that's where the new React Compiler will eventually head where based on your code it will try and remove as much React runtime as possible if it's not needed.
Took a look - after the pain of React memoization, that's a super exciting development.
Thanks for the pointer!
Good to understand, but most likely better to stick with react for production stuff anyway
Yup, the 2000 libraries you depend on when you run npm install react won’t have any bugs and will always work together.
/s
Just for anyone reading this and wondering what the dependency footprint of React is:
- React-DOM has one runtime dependency (a cooperative scheduler)
- React itself has no runtime dependencies
It's possible the poster above is referring to build time dependencies. This is harder to assess because there are several options. For example, if compiling JSX using TypeScript, this adds only one more dependency.
As the sibling comment points out, react does not bring in dependencies like that. It is not that heavy but people associate it with heavy things
Am I the only one who (still) does not feel comfortable seeing JavaScript being intertwined into the so-called "vanilla" web in a way that seems more like a hard dependency and not the progressive enhancement we were taught should be the approach for serious public websites?
The page https://plainvanillaweb.com/pages/sites.html uses custom components for all code examples and embedded content. Without JavaScript, it merely shows "enable scripting to view ../XYZ.html" in place of all code examples and demos. Better than having no fallback at all, I suppose, yet still not "navigable".
The fact that it does not even bother to build these custom components on any native element with a similar purpose—like, say, a link that users could follow to see the text document (*), or a plain old iframe (**)—is grim.
Web components are indeed useful for prototyping and personal testing, but are they really beyond the threshold where it is safe to serve them in the wild, potentially harming some users?
(*) I know, view-source: links and embeds are sadly blocked by browsers nowadays. Makes very little sense to me. Someone likely managed to exploit it for some nasty purposes, so now we are "protected", I suppose.
(**) See? In the olden days even iframes were said to have a link fallback inside, for user agents that did not support them.
It depends on the context. What you say makes a lot of sense for web sites, but expecting a web app to use JS strictly as a "progressive enhancement" is IMO unreasonable.
Now, this particular website is indeed a proper website, and so it shouldn't need JS to do its thing. But it's also a website that advocates for a certain way of developing web apps (even if they don't use such terminology themselves), and as such, is essentially a demo for the same.
You're not the only one. I block most subresources by default and was disappointed to see empty figures peppered throughout their articles. I'm learning to not automatically equate advocacy of "vanilla" with advocacy of robustness.
Question - why would you do this in current year? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
What irks me about most about web frameworks is the error stack.
20 lines of anonymous function calling gibberish is so unpalatable.
It's hard to understand what is actual application code in these stacks.
Well, one nice thing about doing things this way is that it'll still be as viable in five years as it is today.
I'm sitting on two UIs at work that nobody can really do anything with, because the cutting-edge, mainstream-acceptable frameworks at the time they are built in are now deprecated, very difficult to even reconstruct with all the library motion, and as a result, effectively frozen because we can't practically tweak them without someone dedicating a week just to put all the pieces back together enough to rebuild the system... and then that week of work has to largely be done again in a year if we have to tweak it again.
Meanwhile the little website I wrote with just vanilla HTML, CSS, & JS is chugging along, and we can and have pushed in the occasional tweak to it without it blowing up the world or requiring someone to spend a week reconstructing some weird specific environment.
I'm actually not against web frameworks in the general sense, but they do need to pull their weight and I think a lot of people underestimate their long-term expense for a lot of sites. Doing a little bit of JS to run a couple of "fetch" commands is not that difficult. It is true that if you start building a large enough site that you will eventually reconstruct your own framework out of necessity, and it'll be inferior to React, but there's a lot of sites under that "large enough" threshold.
Perhaps the best way to think about it is that this is the "standard library" framework that ships in the browsers, and it's worth knowing about it so that you can analyze when it is sufficient for your needs. Because if it is sufficient, it has a lot of advantages to it. If it isn't, then by all means go and get something else... again, I'm definitely not in the camp of "frameworks have no utility". But this should always be part of your analysis because of its unique benefits it has that no other framework has, like its 0KB initial overhead and generally unbeatable performance (because all the other frameworks are built on top of this one).
Performance is irrelevant to 99% of web apps.
Cognitive burden is relevant to 100% of web apps.
When frameworks are used for that 99% of web apps for which they are overkill, performance actually drops.
> frameworks seem to be the lingua franca for a reason
Sure, but theres no evidence that the reason is what you think it is.
The reason could just be "legacy", ie. " this is the way we have always done it".
It actually is kind of about performance.
For me it's mostly about de-tooling your project.
For example - I have a fairly complex app, at least for a side project, but so far I managed to keep everything without a single external dependecy nor any build tool. Now I have to convert it all to react and I'm not very happy about that, I will have to add a ton of tooling, and what's most important for me, I won't be able to make any changes without deploying the tooling beforehand.
Why do you have to convert it to react?
it's a long story, let's just call it "a non-functional requirement" :)
The use of a framework always involves a trade-off between independence, responsibility, and delegation of control.
Mostly for the virtue signaling. There's something to be said for going with the fundamentals, but people who loudly preach fundamentals tend to be, well...
Frameworks are fine when you just need to get a job done quickly. And they're ideal when you're in a typical corporate code factory with average turnover, and for the same reasons Java is ideal there.
React is the new Java.
But when you need something the framework can't provide, good luck. Yes, high performance is typically one of those things. But a well engineered design is almost always another, costing maintainability and flexibility.
This is why you almost always see frameworks slow to a crawl at a certain point in terms of fixing bugs, adding features, or improving performance. I'd guess React did this around like 2019 or so.
> React is the new Java.
Overly hated on and conflated with frameworks, yes.
React requires very little from you. Even less if you don't want to use JSX. But because Facebook pushes puzzlingly heavy starter kits, everyone thinks React needs routers or NextJS. But what barebones React is, at the end of the day, is hardly what I'd call a framework, and is suitable for little JS "islands."
Because of the ridiculous complexity in their setup and operation, their glacially slow performance if it is actually written in JavaScript and not a non-web platform language that compiles to native code, and their extreme volatility and instability/pace of deprecation.
The benchmarks I've seen actually show web components being slightly slower than the best frameworks/libraries.
The idea is: no build steps initially, minimal build steps later on, no dealing with a constant stream of CVEs in transitive dependencies, no slow down in CI/CD, much more readable stack traces and profiling graphs when investigating errors and performance, no massive node_modules folder, etc. Massive worlds of complexity and security holes and stupid janky bullshit all gone. This will probably also be easier to serve as part of the backend API and not require a separate container/app/service just running node.js and can probably just be served as static content, or at least the lack of Node build steps should make that more feasible.
It's a tradeoff some people want to make and others don't. There isn't a right and wrong answer.
I had built a component library with HTML and CSS, and had named it "Vanilla Web" :)
https://vanilla-web.netlify.app/
> Styling.
The problem I found is that my full-SSR project doesn't use any Node.js at all, and it works fine for everything but CSS, because in order to use includes and variables I need a CSS compiler.
For example, I use a CSS library that defines a very nice style class "alib-link" for all links. I would want to set it for all <a> elements, without adding `class="alib-link"` all the time. It's easy with a CSS-preprocrssor, but how to avoid using one?
> I would want to set it for all <a> elements, without adding `class="alib-link"` all the time.
If you need to style anchor links depending on where they point to, you could use an attribute selector: No preprocessing necessary.If you do this with no build step, how can you have cache busting of your component files? or is there an alternative solution that doesn't sacrifice on performance (but also doesn't serve stale files or an inconsistent version between files)?
There’s an article explaining the options on the blog section: https://plainvanillaweb.com/blog/articles/2024-12-16-caching...
I tried to build an app with web components but honestly, the DX is quite bad and I abandoned the shadow DOM for light dom until I abandoned the vanilla tech stack entirely and moved the project to React. It is just so much faster to develop in React in comparison. Also when stuff goes wrong with components they many times just fail silently with no errors given to the console.
You have such a great community with big, very well thought out libraries like Tanstack Query that is pretty nice to work with. I can have backend and front end code in the same repository in a simple way and reuse code.
I also have the project in Phoenix Liveview which is also a much nicer way of using components. The thing is I don't really know which tech stack is gonna win so I made a small prototype in both to see different advantages / disadvantages.
One thing is clear tho, pretty much everything is better than using vanilla components and it's really sad because I really do want to use vanilla components and I want them to be good.
A solid overview with some great tips.
One recommendation is to change the mental model here. In my eyes it isn’t “don’t use a framework”, it’s “build the framework you need”. It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react. My SPA non.io is built like this - one master component that has class functions I want, and one script for generic functions.
> It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react.
The last 10%, OTOH...
Get the first 90% easy, the next 90% is much harder.
With advent LLM driven development,the traditional web frameworks may soon be rendered obsolete.
All the framework abstractions we made for humans coding productivity will need to be re-visited! I support plain vanilla web for this reason.
From the people who brought you vanilla-js.com
http://vanilla-js.com/
In today's episode of I Hate JavaScript Frameworks, So I Built My Own...
I missed the part where they show how to do something similar to ejs or PHP HTML includes for things like header.html and footer.html.
That's how I wrote my website a long time ago.
I'm still using it, and I wonder when I'll be able to get rid of PHP.Love to see this!
Although I do think there is merit to "light" frameworks such as Astro, with its scoped styling and better component syntax. But at the same time, independence is also important.
I started something similar with https://webdev.bryanhogan.com/ which focuses on writing good and scalable HTML and CSS.
Man, the example web components seem to work great if you wish to hide data from scraping and search indexing... And if you try to work around this, you end up with something very very similar to https://stimulus.hotwired.dev/ .
> the example web components seem to work great if you wish to hide data from scraping and search indexing
Interesting. Why do web components have this effect, but some JS frameworks apparently do not? Or do they all?
Is there any clean solution to the innerhtml problem in plain JavaScript applications, that does not require a virtual DOM or component lifecycle AND has Jetbrains IDE support?
I'd like to use lit-html but Jetbrains does not support it - very annoying.
Was wondering what you meant so I looked up "the innerhtml problem" and the top result indeed does list quite a few issues with appending to innerHTML that can be easily avoided. For anyone else interested: https://stackoverflow.com/a/33995479/1201863
https://clock.rt.ht/::code has a sophisticated custom <analog-clock> HTML element!
https://go.rt.ht has other custom elements!
Ironically the style of this site lets it down, the 2006 look (post-css, pre-gradients and big buttons) makes it feel like it's an outdated framework.
Literally use WebFontPicker and choose Raleway or something.
Although I'm liking the use of javascript classes, not for any technical reasons just that it's a defiant middle finger to the React crew (who you now no longer hear from) that cancelled classes.
SPAs are generally not worth it nowadays. Why a >20MB .min.js just for few lines of text content?
Yeah I don't need your shitty onclick hijacks. Thanks.
I've been recently going this route, everything is static. If I can't host them on an S3 bucket, then I'm building it wrong.
Sites are way too bloated nowadays, a lot of the content being served can be static and cached.
Lost me at Web Components. There are many things the web does great, but Web Components is not one of them. Can we move on?
Why do you think web components are not great?
I know not with what tools Web 3.0 will be built, but Web 4.0 will be built with vanilla HTML, CSS and Javascript.
As a react dev I find this fascinating - in the same way I was fascinated by the foraging walk I went on the other day - but was SO HAPPY that supermarkets exist when I saw how much effort it is.
No, it's more like fast food vs grocery store & home cooked meals.
http://youmightnotneedjs.com
Is connected callback still needed over a constructor? I read somewhere it's not needed but couldn't say where that was
If they just had HTML imports and template substitution, you wouldn't need Javascript nor web components for a lot of apps.
I’m tired of SPAs and webpages that don’t render without JavaScript.
The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off.
Now, web developers give you a blank page if you don’t run a megabyte of their shitty code.
No thank you.
> The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off.
I agree. (This should also include CSS, TLS, cookies, and many other things; I often disable CSS, and it should work just as well if CSS is disabled just as much as if pictures or JavaScripts or cookies are disabled.)
However, there are some uses where JavaScripts may be helpful e.g. if a web page has a calculations or something like that implemented by JavaScripts; but that is not an excuse to prevent the documentation from being displayed if JavaScripts are disabled. They should really make documentation and as much other stuff to work even if JavaScripts are disabled (and, depending on what it does, may provide a description of the calculation or of the rules of the game being implemented, or a link to API documentation, or something else like that).
Pictures also might be useful in some articles (but are often overused); but even then, if the picture is not displayed you could use an external program to display them. However, if it can be explained in the text, then it should be explained in the text if possible so that even if you do not have a suitable program to display that picture (or do not want to display that picture, e.g. the file size is too big; or maybe you are using text to speech or a braille display or something else like that) then it will still work.
TLS also should not always be mandatory, either. For things that require user authentication, and for writing, it can be useful to be mandatory (especially if you are using X.509 client authentication; this will be better than using cookies or other methods for authentication, anyways); but for read-only access to public data, TLS should be optional (but the server should still allow it in case the client wants to use TLS for read-only access to public data too).
No, TLS should always be required. We should be moving away from plaintext anything on the wire, if for no other reason than privacy (but also for integrity, injecting scripts into an HTTP response is a nasty attack surface).
TLS shouldn't be required for as long as it remains a heavily centralized thing; to require it would give undue power to root certificate authorities.
Do you have an idea how this could be decentralized?
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 ...
I always appreciate a reminder of this site
my issue with doing web development without frameworks is how to best manage the app state. In react things like redux help with this, but in my experience state management becomes a mess without frameworks, maybe it's a skill issue on my side I don't know.
It’s cool and I wish I had a use case for it.
I have some notes here at andrewmcwatters/custom-elements https://github.com/andrewmcwatters/custom-elements.
My business doesn't use React anymore, and I'm so happy I don't have to do pointless maintenance.
A side note, included in my repository: you update your element's innerHtml from the constructor, not from the connectedCallback. MDN and the web standards seem to be inconsistent on this, and elsewhere people write about it, too.
People talk a lot about data and binding, etc. I think it's weird, it's like people have forgotten how to just use setters. You can call a render() method from a setter, and it does the same thing WebKit et al do when you call an internal setter on an HTML element.
I don't see the value in these frameworks anymore.
I'm seriously starting to wonder do we even need JavaScript. Or images. How much could you do with UTF-8 web page.
If every website did this I wonder if there would be a measurable impact on things like: battery life, performance, and bandwidth usage.
Loved the whole point being made.
Web components are honestly the first time I have seen web stuff in years and thought "that actually looks nice".
Maybe it's time for me to crawl out of my systems-software-only hole and play around with the web again.
The section on Web Components is... teeechnically correct. Unfortunately, it's missing a lot of information on hidden pitfalls of doing things in certain ways
As an example, the examples on `connectedCallback()` don't guard against the fact that this callback gets called every time the element gets inserted into the DOM tree. This could happen because you've removed it to hide it and then added it later to show it again, or it could happen because you've moved it to a new location in the tree (different parent, or re-ordering with respect to its siblings). Or maybe you're not manipulating this object at all! Maybe someone else is moving around a parent element of your custom element. Whatever the case, if you're element's ancestor path in any way gets disconnected and then reconnected from `documentElement`, `connectedCallback()` gets called again.
That means that you have to spend extra effort to make sure anything you do in `connectedCallback()` either gets completely undone in `disconnectedCallback()`, or has some way of checking to make sure it doesn't redo work that has already been done.
There are some other pitfalls involving attributes, child elements, styling, behavior with bundling, etc., that they never really get into. And generally speaking, you're probably only going to find out about them from experience. I don't think I've seen anywhere that goes into Web Component best practices.
Which is a shame, because they are incredibly powerful and I enjoy using them quite a bit. Now that my company has decided to go all in on React, I think they've only really seen the beginner path on both. Web Components as a beginner look harder than React as a beginner. Once you start actually building apps, I find they actually end up having to do largely the same level of manual shenanigans. But I find that I'm doing manual shenanigans to work around React, whereas with Web Components there isn't any magic to work around, but there also isn't a lot of "help" that you'd end up ignoring in most cases anyway.
In theory, “de-frameworking yourself” is cool, but in practice, it’ll just lead to you building what effectively is your own ad hoc less battle-tested, probably less secure, and likely less performant de facto framework.
I’m not convinced it’s worth it.
If you want something à la KISS[0][0], just use Svelte/SvelteKit[1][1].
Nowadays, the primary exception I see to my point here is if your goal is to better understand what’s going on under the hood of many libraries and frameworks.
[0]: https://en.wikipedia.org/wiki/KISS_principle
[1]: https://svelte.dev
Any attempt to show that vanilla web components are somehow a viable solution always read like a parody.
The boilerplate, the innerHTML strings, the long list of caveats, the extra code to make basic things like forms work, manually attaching styles etc. etc.
GPT agrees with me.
The site positions itself as advocating for simplicity and minimalism in web development—stressing plain HTML, CSS, and JavaScript—but then pivots into building the entire project using React. That’s a contradiction.
If the goal is truly "plain vanilla web," introducing React (with its build tools, dependencies, and abstraction layers) runs counter to that ethos. A truly minimalist approach would skip frameworks entirely or at most use small, native JS modules.
So yes, it's philosophically inconsistent. Want to dig into a better alternative stack that sticks to that principle?
I’m building a plain vanilla web application right now.
The main reason is I want direct control of the DOM and despite having 10 years or more react experience, it is too frustrating to deal with the react abstractions when you want direct dom control.
The interesting thing is that it’s the LLM/AI that makes this possible for me. LLMs are incredibly good at plain JavaScript.
With an LLM as capable as Gemini you rarely even need libraries - whatever your goal the LLM can often directly implement it for you, so you end up with few of no dependencies.
From https://plainvanillaweb.com/pages/components.html I see this piece:
What is that kind of magic syntax sugar?! A shorthand for document.getElementById?No, the hash is a red herring. It's a way of signifying a private field on an object.
Ah. Thanks, that hint pointed me to [1]. Seems like it's been supported by every major browser since 2021, and only specified in the upcoming ECMAScript 2026 spec.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
It has a contentious history and largely was forced through by one person in TC39 who focused on a particular corner case
The navigation bar of that site to not stay put, vertically, when you click one of the links.
That in itself undermines a lot of the author's message, as they were not able to reasonably de-framework themselves.
(And - it's not hard to get the navbar right, in any number of ways. But you do have to do a bit of work before you preach things to others.)
I think routing components are mostly out of date now that CSS View Transitions exist.
I think there are two separate things.
The static websites and beautiful designs
With a lot of iframes and widgets, running some kind of services like Disqus chatrooms were
It’s far more secure, too.
aNd jaVaSCripT
There's another solution to the "Plain Vanilla Web". It's called Markdown.
Be wary of building a website without a framework to abstract stuff like DOM usage and page generation. Raw webdev is hard, due to lots of compatibility issues at every level (CSS, HTML, JS) and are moving targets. You shouldn't even try it until you understand protocol design and have implemented some medium complexity standards like IRC and a basic DNS client or server.