iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Software development does not always move from old tools to new ones. Some teams find that a simpler or more direct approach works better than the latest layer of abstraction. In a September 28, 2026 InfoWorld feature, contributing writer Matthew Tyson describes nine such shifts—from SQL and local IDEs to monoliths and Java virtual threads. They are editorial observations, not a ranked list or a measurement of industry-wide adoption.
The common thread is not that newer tools have failed or that older ones are always better. It is that every tool has a cost: integration work, operational complexity, abstraction, or friction. Tyson’s test is to choose “the path of least resistance—the minimum complexity that will solve the problem.” That makes the trends below conditional choices, not universal prescriptions.
1. JavaScript may remain the executable code, with types handled by tooling
TypeScript adds static checking and other development-time capabilities, but it also introduces a compilation step before code runs as JavaScript. Tyson points to proposals for JavaScript types expressed as comments and to runtime type stripping, including in Node.js, as signs that some type-related work could happen without making TypeScript compilation mandatory.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
This is a possible direction, not evidence that TypeScript is obsolete. A team may still prefer its type system, compiler checks, and established workflow. The practical question is whether those benefits justify the extra build step for a particular project. JavaScript with tooling-assisted checks could suit teams seeking a simpler runtime path; TypeScript remains useful when its stronger development-time structure earns its place.
#1 Best Overall
2. SQL can be a better fit than an ORM-heavy data layer
An object-relational mapper (ORM) can make routine database work more convenient, but its abstraction can get in the way when developers need to reason directly about relational data or query behavior. Tyson’s argument is for using SQL where directness helps, rather than treating an ORM as the default for every interaction.
He points to SQL in WebAssembly contexts and to jOOQ as a more direct server-side approach than Hibernate. Those examples illustrate different ways to work closer to SQL; they do not establish that ORM use is declining overall. Keep an ORM when it makes common operations clearer and easier to maintain. Favor more direct SQL access when the abstraction creates more translation or friction than it removes.
3. Local IDEs remain useful alongside cloud development environments
Cloud development environments offer remote workspaces, while a local IDE can make day-to-day editing feel responsive on a modern laptop. Tyson notes that local RAM and SSD resources can do much of the work, even when AI features depend on remote back ends.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →That is a qualitative observation, not a laptop benchmark or a recommendation for a particular configuration. The choice depends on where the team wants its development environment to run: local work can reduce reliance on a remote workspace for ordinary editing, while cloud environments can still be useful when remote access or centralized environments suit the workflow. AI features may also have a remote dependency regardless of where the editor runs.
4. A monolith can be simpler than microservices for the system at hand
Microservices split a system across service and network boundaries. Those boundaries can help in appropriate architectures, but they also bring operational work and make communication between parts of the system a concern. If a project does not need that distribution, a monolith may avoid complexity that does not solve a real problem.
A monolith is not automatically easy to operate or well structured: it still needs sound architecture, and availability and quality-of-service needs can add complexity. The decision is not “monoliths are better.” It is whether the benefits of separate services justify their network and operational costs for this system.
5. Integrated frameworks can reduce the glue between tools
Building an application by connecting many separate services can provide flexibility, but each connection creates integration work and potential brittleness. Tyson points to “batteries included” frameworks such as Rails, Django, Next.js, and Spring Boot as ways to start with a more integrated path.
Integration does not mean a framework supplies every service a team needs. Supporting services such as databases and authentication providers may still be part of the system. An integrated framework is most compelling when its conventions and built-in pieces reduce coordination work; separate tools remain reasonable when the flexibility is worth the added integration effort.
6. On-premises infrastructure can suit some workloads better than cloud by default
Cloud infrastructure offers managed capabilities, but it is not automatically the lowest-complexity or best-fitting option for every workload. Tyson lists existing internal expertise, cost controls, predictable billing, and data sovereignty as possible reasons to run compute, storage, or networking in-house.
Rank #4
Those considerations do not make on-premises infrastructure universally cheaper or simpler, just as cloud is not automatically the right answer. Compare the specific workload and operating context: what the team can manage, how it needs to control costs, and what requirements apply to its data. Cloud benefits still matter when they outweigh the value of in-house control.
7. Specialized engineers can be more realistic than universal full-stack mastery
Web development spans enough areas that expecting every developer to master the entire stack can be unrealistic. Tyson’s alternative is to let people build deeper expertise and bridge gaps through colleagues, libraries, or AI agents. He still values senior engineers who can understand how the pieces fit together.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →This is a division-of-expertise argument, not a case for developers to ignore the rest of a system. A team can combine specialists with people who understand the interfaces between their areas. Libraries and AI agents may help with that coordination, but the source does not establish that they replace cross-system judgment or expertise.
Best Value
8. WebAssembly may be a useful alternative alongside Docker
Tyson presents WebAssembly (Wasm) binaries and lightweight runtimes as a potentially more direct, lower-overhead option for some workloads. Docker, meanwhile, retains its enterprise tooling and role. The point is to consider the workload and runtime needs rather than assuming that one deployment approach should replace the other.
The feature supplies no comparative performance measurements, so lower overhead should be treated as a possibility, not a guaranteed result. Portability and performance depend on the workload and surrounding runtime. Docker remains useful where its tooling and ecosystem fit; Wasm is worth considering where its execution model meets the need without adding unwanted complexity.
9. Java virtual threads renew interest in Java for concurrent work
Java virtual threads and related concurrency features offer another way to handle many concurrent tasks while remaining compatible with older thread APIs, according to Tyson. That combination can make the approach relevant to teams working in existing Java systems as well as those considering Java for concurrent services.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe feature does not provide a benchmark or independently established capacity figure. Its mention of very high concurrency should not be read as a promise that a server can handle a fixed number of requests: actual capacity depends on the application and its operating conditions. Evaluate virtual threads against the system’s concurrency needs rather than treating them as a capacity guarantee.
How to decide whether a “reverse” trend applies to your project
Each example is a prompt to compare costs and benefits, not a reason to change tools for its own sake. Before adopting a simpler-looking approach, ask:
- What problem does the extra layer solve? Keep an abstraction, service boundary, or managed platform when its benefits address a real need.
- What complexity does it add? Account for compilation, integration, network boundaries, and operating responsibilities—not only initial setup.
- What does the team need to manage directly? Local versus cloud development and on-premises versus cloud infrastructure place work in different environments.
- What evidence would settle the choice? For performance- or capacity-sensitive decisions, test the actual workload; the examples in Tyson’s feature do not supply comparative benchmarks.
Across all nine shifts, the useful question is whether a tool’s added capability pays for the complexity it brings. The answer can differ between projects—and even between parts of the same system.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
