This post is specifically about internal applications - the member portal, the staff scheduling tool, the shift rota, the grant management system. Software used by a known, bounded set of people who work for or with the organization. Not a public website that anyone on the internet might open on any device. That distinction matters for everything that follows.
Defining a modern browser baseline for this kind of application is an act of simplification. Not a compromise, not a limitation imposed on users - a deliberate decision to remove an entire class of complexity from the codebase so that what remains is clean, maintainable, and honest about what it requires. Every polyfill you don't write, every compatibility workaround you don't add, every conditional branch you don't test is code that never existed and never needed to. That is the argument. The rest is explaining why the objections don't hold.
There is a category of decision that every organization makes without thinking of it as a decision: the tools the people who use your software are allowed to bring to the table. You specify the server, the database, the runtime. You have opinions about the editor your team uses and the node version that runs in CI. And then, somewhere between the architecture diagram and the first pull request, the question of which browsers you support gets answered with "all of them" - and nobody pushes back, because pushing back sounds like you don't care about users. I want to push back on that assumption directly, because the browser is the same category of decision as everything else and treating it as a given rather than a choice has a real cost that accumulates with every feature you add.
Every Other Tool Is a Decision
When an organization chooses office space, they don't ask the employees to vote on the building - they evaluate the options, pick one, and the employees work there. When they choose a cloud provider, they don't survey the staff. When they buy furniture, replace the coffee machine, pick the accounting software, these are business decisions made by the people running the organization based on what the organization needs, not on what any individual preference dictates, and the browser belongs in exactly that category.
The people who use your software are bringing a tool to the interaction. You have every right to specify what that tool should be. Not arbitrarily - there are good reasons to choose a baseline, and the reasoning should be documented and explained to users who ask. But the idea that supporting every version of every browser back to whenever is a moral obligation rather than a technical choice made by default is one that deserves examination.
A modern browser is not a luxury. It is a free, automatic update that every major vendor has been pushing silently in the background for years. The staff member on a five-year-old browser version is almost certainly there by policy, by neglect, or by an IT department that locked updates in 2019 and moved on. Those are real scenarios, and they have real solutions - a conversation with IT, a policy update, a machine refresh. None of them require you to write the application for the oldest denominator in the room.
What Backwards Compatibility Actually Costs
The polyfill exists because a browser doesn't support something. The workaround exists because a CSS property behaves differently in an older rendering engine. The test case exists because the layout breaks on a version that nobody on the team has installed. The conditional exists because a JavaScript API arrived in version X and you need to handle the case where it hasn't. All of this is code that wouldn't exist if you had stated a baseline from the start.
This is not a small cost. It is cumulative, invisible, and paid continuously. Every new feature you build gets weighted down by the obligation to make it work somewhere it was never designed to work. Every developer on the team carries a mental model of what they can and cannot use. Every CSS trick that would simplify the layout gets set aside because it doesn't have the coverage numbers.
And then there is the testing. A bug that only reproduces on an old browser version in a specific OS combination is a bug that takes a disproportionate amount of time to find, diagnose, and fix - and fixing it usually involves adding more special-case code that will need to be maintained long after the browser in question has a single-digit market share.
The cost is borne by the developers and the organization. The user with the old browser pays nothing for the accommodation.
Security Is Not a Side Argument
Old browsers do not receive security patches. This is not a matter of policy or priority - it is the natural end state of software that has stopped being actively maintained. A user connecting to your application on an unpatched browser is a user whose traffic, session, and credentials are handled by software with known, publicly documented vulnerabilities.
You are not doing that user a favor by continuing to support their environment. You are validating a choice that puts them at risk and, in some configurations, puts the application and its other users at risk alongside them. A modern baseline is not just a developer convenience. It is a security posture.
What "Modern Baseline" Means in Practice
This is not about using experimental APIs that shipped last Tuesday. A modern baseline means the last two versions of Chromium-based browsers, Firefox, and Safari - a definition that covers the overwhelming majority of devices in any managed or semi-managed organizational environment. For internal applications used by staff on organization-issued or personally maintained hardware, the number of people this leaves out is effectively zero, and those people have a direct line to someone who can help them update.
The features that live inside that baseline are not exotic. CSS Grid. Custom properties. Native form validation. The Fetch API. ES modules. Intersection Observer. Web components. These are things that have been stable for years, that work consistently across the covered browsers, and that allow you to write clean, maintainable, readable code without a build pipeline to smooth over the gaps.
The features you're polyfilling today were finalized before some of your junior developers finished university.
You Equip the Staff, Not the Other Way Around
A useful way to think about this: a company equips its staff with the tools needed to do the job. A new employee doesn't bring their own chair and expect the floor plan to move around it. The browser is a tool. For an internal application, the organization gets to specify which one.
Your application is the product. You define what it requires. A staff member on an unsupported browser gets a clear message: this application requires a current browser, here is the link, IT can help. What you do not do is rewrite the application around a tool that creates more problems than the staff member it belongs to.
Reepolee's Position
Reepolee generates applications that assume a modern browser baseline. The templates use modern CSS, native browser APIs, and ES module syntax. There are no polyfill layers by default, no compatibility shims, no conditional code paths for rendering engines that haven't been current since before the project existed.
This is a deliberate choice and a constraint that has consequences: it means the generated code is clean, readable, and does not carry the weight of a decade of browser compatibility workarounds. It means a developer reading a template can use what the browser natively offers without asking whether it's safe. It means the CSS does what CSS is designed to do, not what CSS had to do before the specification caught up.
Polyfills can be added - but that becomes a conscious, explicit decision for a specific feature that needs it, not a default layer applied to everything. Declarative Partial Updates with streaming is one such case: a useful capability that sits ahead of full cross-browser native support, worth polyfilling for the applications that need it, and easy to add precisely because the baseline is clean enough that one targeted addition doesn't disappear into noise.
The direction Reepolee is moving in is toward APIs that TC39 is actively exploring and confirming - the standards process, not the framework cycle. That is a different compass than following what is popular in the ecosystem this month. Standards move slowly and deliberately, which means the code written against them tends to stay correct longer, require less rework, and carry less baggage than code written against abstractions that the ecosystem will quietly deprecate in three years.
The applications Reepolee is built for - internal tools, booking systems, volunteer portals, staff-facing administration panels - are used by people on organization-managed or personally maintained devices. Those people can be asked to use a current browser. In most cases they already are. The edge cases are manageable, and the right way to manage them is a polite notice explaining the requirement, not a codebase weighted down by trying to serve everyone at once.
Define your baseline, state it clearly in the project documentation, and build to it without apology, because the application you ship will be cleaner and more maintainable for having made that decision explicitly rather than letting it happen by default.