Tools like PLC ladder logic, COBOL batch code, and MATLAB/Simulink sit outside the web stack because they target hardware, mainframes, or engineering.
If you’re mapping the web stack, it helps to spot what sits outside of it. Plenty of languages and platforms power other domains—factory lines, mainframe ledgers, scientific modeling—that don’t ship HTML, CSS, and JavaScript to a browser. This guide names common candidates people often assume belong in front-end or back-end work when they don’t. Where small bridges exist, you’ll see how teams connect those worlds to a site or API without forcing a square peg into a round hole.
What “Web Tech” Actually Means
On the open web, browsers render documents and apps by fetching resources over HTTP, parsing HTML for structure, applying CSS for presentation, and executing JavaScript plus Web APIs for behavior. Servers respond with those resources or with JSON over endpoints. When a tool can’t output these primitives—or can do so only through roundabout export steps—it usually lives outside the web stack.
Technologies Not Typically Used For Website Development
Here’s a broad, working list. These technologies are valuable in their lanes, but they aren’t how you build client-side interfaces or standard server endpoints.
| Technology | Typical Domain | Why It’s Outside Web Work |
|---|---|---|
| Ladder Logic (PLC) | Industrial control | Targets field devices; no browser runtime |
| Structured Text (IEC 61131-3) | Automation | Runs on controllers; not for HTTP apps |
| COBOL | Mainframe batch/OLTP | Business data processing; terminal UIs |
| ABAP | ERP customization | Tied to SAP stacks; separate from browser code |
| Fortran | HPC/numerical | Compiles to native; used for simulation jobs |
| MATLAB/Simulink | Model-based design | Graphs and C/C++ codegen, not DOM output |
| VHDL/Verilog | Chip design | Describes hardware; no HTTP endpoints |
| LabVIEW | Test & measurement | Instrument control; GUIs outside the DOM |
| RPG | IBM i systems | Business logic on AS/400; green-screen heritage |
| Objective-C (iOS/macOS) | Native apps | Compiles to platform binaries, not web assets |
| SwiftUI/Jetpack Compose | Mobile UI | Native UI frameworks, not HTML/CSS |
| Unreal/Unity Blueprints | Game engines | Real-time 3D; exports binaries, not pages |
| CUDA/OpenCL | GPU compute | Accelerates kernels; separate from the DOM |
| ROS | Robotics | Message-passing for robots; not for browsers |
| LaTeX | Typesetting | Produces PDFs; not interactive web UI |
| Excel Macros (VBA) | Office automation | Desktop automation; not a web runtime |
| Shell Scripting | Ops/automation | CLI workflows; used around servers, not in browsers |
Why These Don’t Fit Day-To-Day Web Work
Each item above misses one or more web building blocks. Some have no browser runtime, some target hardware, and some operate in batch jobs far away from request-response traffic. When teams need data or results from those systems, they add an adapter—a service layer that speaks HTTP or publishes messages—so a site or API can consume it without mixing concerns.
Borderline Cases And Crossovers
A few platforms can appear near the web without being part of it. The trick is to watch what actually reaches the browser or a public HTTP endpoint. If a workflow ends in a binary for a robot arm, that’s not web. If it ends in HTML, CSS, and JavaScript—or data an app can fetch over HTTP—then it touches the web, even if the source tool started elsewhere.
How Teams Bridge Non-Web Systems To Sites
Common bridges include message queues, scheduled jobs that export CSV or JSON, and small gateway services that expose a REST or GraphQL layer. Those bridges translate formats and stitch authentication, rate limits, and caching around the edge so browsers and servers speak cleanly with legacy or industrial stacks.
Checklist: Is A Technology Part Of The Web Stack?
- Does it run in a browser without plugins? If no, it isn’t client tech.
- Can a server built with it speak HTTP and serve HTML/CSS/JS cleanly?
- Is there a direct path to Web APIs or the DOM without code generation hoops?
- Does the workflow end in HTML, CSS, JavaScript, or JSON delivered over HTTP?
- If not, plan an integration layer rather than forcing it into the stack.
Common Misconceptions New Devs Run Into
Newcomers sometimes think any programming language can build a site. That hunch comes from seeing many languages on the server. The browser side is different: the runtime is fixed. HTML, CSS, and JavaScript (plus WebAssembly modules compiled from other languages) are what run in a typical client. Everything else must feed those primitives or sit behind an HTTP interface.
When Non-Web Tools Still Matter For A Web Project
Plenty of web apps depend on results produced outside the browser: plant sensor streams, numerical models, or enterprise ledgers. The best path is to keep each tool in its lane, then agree on clean interfaces. That preserves performance where it’s needed—near hardware or batch throughput—while keeping your site maintainable and your front end simple.
Starter Stack: What To Learn For Real Web Work
Focus on platform pieces every browser implements and every host can serve. Learn semantic HTML, modern CSS, and JavaScript fundamentals. Study the HTTP request/response model and how browsers fetch documents and assets. Then add a server runtime you enjoy and a database. Frameworks come next once you’re comfortable with the platform pieces and can judge trade-offs on routing, rendering, and data fetching.
Skill Roadmap
- HTML semantics, forms, and accessibility patterns.
- CSS layout with flexbox and grid; responsive images.
- JavaScript, Web APIs, fetch, and basic performance tuning.
- A server runtime (Node.js, Deno, Python, Go, etc.) that can return HTML and JSON.
- Datastores (PostgreSQL, SQLite, document stores) and basic SQL.
- Build tools, bundling, code splitting, and deployment basics.
- Defense basics: content security policy, headers, and auth flows.
Second Table: Edge Cases And Bridges
This matrix lists tools that sometimes surface in web projects through exports or gateways. They don’t run in the client, but they can feed a site when paired with the right interface.
| Tool/Platform | Typical Domain | How It Feeds A Site |
|---|---|---|
| MATLAB/Simulink | Control/system models | Export CSV/JSON; a gateway serves data to the app |
| Fortran/HPC Jobs | Scientific compute | Batch results posted to an API for charts |
| PLC Runtimes | Factory floors | Field gateway publishes MQTT; backend translates to HTTP |
| LabVIEW | Instrumentation | Writes to a store that a server exposes via an endpoint |
| Legacy Mainframes | Enterprise finance | Adapters mirror records into a web-facing service |
| Game Engines | 3D apps | Export telemetry that powers dashboards, not the client UI |
Practical Scenarios And Decisions
Factory Telemetry Dashboard
An operations team wants live line stats on a web dashboard. PLCs speak industrial buses, not browsers. A field gateway collects values, pushes them to a message queue, and a small web service exposes filtered JSON. The front end renders charts from that API. If timing matters, the pipeline also buffers spikes and applies sampling so charts stay smooth.
Risk Reports From A Mainframe
A bank needs nightly summaries on an internal portal. COBOL jobs still crunch transactions. A bridge job extracts results into CSV, a loader inserts the data into a relational store, and a web server ships the reports to staff in HTML. This keeps the ledger logic stable while giving staff a fast, searchable view.
Publishing Simulation Results
Researchers run long numerical jobs on a cluster. The code writes NetCDF or CSV. A tiny ingestion service converts files to database rows and offers endpoints. The site fetches those endpoints to draw interactive visuals. When a run finishes, a webhook kicks the ingestion task so the charts refresh on the next page load.
Deeper Clarity: What Defines “Web” At The Spec Level
The platform’s core is a set of living and widely implemented specs. Browsers parse HTML for structure, apply CSS to style, and execute JavaScript to add behavior. Those pieces ride over HTTP, which defines how clients request resources and how servers reply. When a tool can’t speak those pieces directly, it sits nearby rather than inside the stack.
How To Talk About This With Stakeholders
When someone proposes a tool from outside the stack, steer the chat to desired outcomes. Ask what the browser should display, how fresh the data must be, and who owns the integration surface. If the source is a controller, a mainframe, or a lab bench, propose a clear bridge: an ingestion job, a message bus, or a small service that exposes JSON. That keeps each system strong in its lane while giving the site clean inputs.
Method Notes
Standards pages and vendor docs informed the scope here. MDN explains how HTTP fetches resources and underpins client-server exchanges, which is the spine of page delivery. For legacy enterprise work, IBM’s overview of COBOL shows where that language fits: large-scale business processing on mainframes, far from the browser. Together, those references help draw clear lines between “feeds the web” and “is the web.”