What we use JavaScript for
Most of our JavaScript work goes into shop front ends. Filters and facets that narrow down a catalogue without reloading the page on every click. Cart and variants that react immediately. Scale prices, minimum quantities and order templates in a B2B context. Then there are forms that do more than submit: dependencies between fields, checks before sending, uploads with feedback. In TYPO3 and WordPress projects the volume is smaller; the requirements are the same.
The second area is the editorial side. Editors, previews, drag-and-drop ordering, small tools that take work off the editorial team. Different rules apply here than in the public front end: a back-office tool may require JavaScript, because nobody sees it without logging in and no search engine has to read it. We make that distinction deliberately — it decides how much effort goes into fallback behaviour and keyboard operation.
How we work with it
We build from the bottom up. First the markup that works completely without JavaScript: links are links, forms submit, content sits in the HTML. Then the enhancement — catching events, loading parts of the page, making states visible. This is not a nostalgic principle. It is the only way of building where a poor connection, a blocked script or a screen reader does not lead to total failure.
Technically we stay close to the standard. Modern browser APIs instead of libraries for things the browser can already do. Bundling with Vite, and in Shopware with its own build. For larger amounts of code we switch to TypeScript. Accessibility is built in, not retrofitted: focus handling, ARIA only where needed, operation without a mouse. Since June 2025 the German Accessibility Improvement Act (Barrierefreiheitsstärkungsgesetz, BFSG) has made this an obligation for many shops — technically it was already the right thing to do.
Limits: when we advise against JavaScript
We are not a JavaScript front-end house, and that is a decision. For content pages, shops and portals we build server-rendered HTML with PHP 8, Symfony, Shopware 6 or TYPO3. Build a product page as a single-page application and you spend the following months clearing up after search engines, screen readers and your own loading behaviour — paying for server-side rendering, hydration and routing to get back what you were given for free. A product page needs no framework in order to be a product page.
There are cases where a real application in the browser is the right answer: configurators with many dependencies, planning tools, interfaces behind a login that have to work without page changes. We build those too — as a defined area, not as a rebuild of the whole website. For large React or Vue applications as the main product, we are not the right address. We would rather say so in advance than in the third week of a project.