Nine unlikely trends shaping software development
InfoWorld ·
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” Was Mark Twain thinking of software development when he wrote those words? ly:Arial;<br> mso-font-kerning:0pt;<br> mso-ligatures:none;<br> mso-ansi-language:EN;}.MsoPapDefault<br> {mso-style-type:export-only;<br> line-height:115%;}div.WordSection1<br> {page:Wor Software progresses in various ways. Mainly, we make a deliberate effort to improve things, and take up opportunities when they present themselves. Sometimes, we tackle a challenge for its own sake, like climbing the mountain “because it’s there.” That is, sometimes we are captivated by the inherent possibility in a project and just go after it. And out of this chaotic mix, we often rework, rediscover, or repurpose ideas in surprising ways. Most surprising of all, sometimes those ways turn back upon themselves—an old idea rises again to overtake a newer idea. Here are nine such examples, unfolding right now. Plain JS beats TypeScript Just when you think something is a done deal, a dead certainty, the universe will rudely contradict you. It seemed obvious that TypeScript was going to absorb the internet’s entire codebase. The simple idea of adding types to JavaScript made it a radically popular option for both programmers and the enterprise. But now it looks like we’re moving toward a future where JavaScript will absorb TypeScript instead. Not only are there efforts to make TypeScript-inspired typing a feature of JS (“ types as comments ”), but there’s a big effort to turn TypeScript into something like a linting step in the IDE. This is the new “ type stripping ” approach, with runtimes like Node.js replacing the type with blank space at run time, leaving plain old JS as the executable and entirely eliminating the unwieldy compilation step. In short, TypeScript is becoming a fancy linter for JavaScript. SQL beats ORMs SQL , invented in the 1970s, was a monumental breakthrough in data management. Alongside some other foundational technologies, it helped fuel the expansive growth of the internet. But unlike other foundational tech like COBOL , SQL has a special characteristic we often overlook — it is a fundamental, irreducible way of manipulating information. Of course, SQL is not the only way to deal with data. But relational data structures give us a rigorous and universal approach. Therefore it is understandable, if surprising, that SQL is seeing a resurgence after the hard pendulum swung toward NoSQL databases and object-relational mapping layers (ORMs). The very trait that some find objectionable, the schematic strictness, makes SQL a stable platform. SQL is now making its way into the browser , via WebAssembly (Wasm), offering a single data idiom across the entire network. SQL also is finding its way back into the server-side codebase, with simpler wrappers like JOOQ offering more direct access to SQL than ORMs like Hibernate. Why? Simply because abstractions inevitably add friction. It is a dicey calculus to trade the immediacy of SQL for the broad power of an ORM. Local IDE beats cloud dev environments The cloud IDE is the obvious heir to the local development environment. So why are we still glued to our local IDEs? It’s not inertia. It’s not just because that’s what we are used to. Part of it is the same “buy versus rent” mentality that is working counter to cloud deployments. Part of it is the highly personal feel of the local IDE. But it’s also the fact that modern laptops are absolute beasts. Even a modest business laptop will give a developer lightning fast IDE iterations. Although developers still tend to rely on a remote AI back end to furnish the ubiquitous need for AI power, the rest of the system fits comfortably in the local resources, where RAM and SSD deliver almost instantaneous results. Monolith beats microservices Microservices have their place. They are massively powerful when the situation calls for them. But—and it’s a big “but”—they are a gaping pit of overengineering and complexity when used willy-nilly. If the phrase “debugging Kubernetes” isn’t enough to make you shudder, consider that microservices inherently imply network latency at every service edge. The monolithic server model eliminates both of these drawbacks at the outset. Of course, one still needs to architect a monolithic server properly, or complexity will overwhelm its implementation as well. Plus, we have to acknowledge that addressing high availability and other QoS concerns increases the number of moving parts. But the tiered layers of the monolithic stack (data/service/UI) amount to a far simpler mental model. And it isn’t really an “either/or” situation. Most applications these days will incorporate some remote services (be they in-house apps or third-party apps), even when using a central server-side stack. But the tide has turned, and there has been a distinct shift in the momentum away from microservices and toward the monolith. In practice, it’s just a matter of identifying the path of least resistance—the minimum complexity that will solve the problem—rather than honoring what is considered “the way.” The desire for simplicity naturally guides architects toward monolithic designs whenever appropriate. Happy path beats integration Integrating well-tested tools into a cohesive whole is much smarter than building a comprehensive, bespoke solution… isn’t it? For the last several years, the “ Jamstack ” (JavaScript, APIs, and markup) and the “ modern data stack ” (combining best-of-breed, cloud-based data management tools) exemplified this philosophy: never build what you can rent. We were told to mix and match a dozen specialized SaaS platforms—one for authentication, one for the database, one for search, one for hosting, etc.—and glue them all together with APIs. But the reality of this approach is an oppressive integration burden. Instead of writing business logic, senior developers spend their days writing glue code to keep third-party APIs talking to each other. When one service updates its SDK, the distributed house of cards goes wobbly. The industry is now leaning back into “batteries included” frameworks. The philosophy pioneered by Rails and Django, and modernized by frameworks like Next.js and Spring Boot , is reasserting itself. This means we rely on a highly opinionated ecosystem—a “golden path.” While a meta-framework like Next.js or Spring Boot may lack its own proprietary database, it provides deeply integrated scaffolding (like NextAuth or Spring Security). It gives developers a cohesive, pre-wired environment. You still bring your own database or auth provider, but the framework entirely eliminates the brittle glue code. After years of vendor fatigue, developers are realizing that submitting to a unified, opinionated ecosystem is the ultimate path to velocity. On-prem metal beats cloud When Larry Ellison ridiculed the cloud “revolution” as a pointless fad … is it possible he was right? Probably not. But the enthusiasm with which the industry pressed toward cloud infrastructure felt overly extreme. At times it seemed almost cultish, as though there was something inherently wrong with running processes on iron that you own. Of course, there is plenty of benefit to be had in the cloud. But the industry has gradually reawakened to that eternal, fundamental question: “What’s the right tool for the job?” It’s simply a fact that sometimes an organization is better served to run the compute, storage, and/or network in-house. There are plenty of advantages to running systems on-premises, such as internal expertise, cost controls, predictable billing, and data sovereignty, that can tip the balance against the need to provision and manage their resources. Specialized engineering beats full-stack developer This is nothing new. It is not possible to master every aspect of the multi-headed hydra known as web development. The typical job description for a full-stack developer reads like an entire IT department . This is just not humanly possible. If you understand CSS grid layout like the back of your hand, it will push the knowledge of database design right out of active memory. Naturally, there are savants out there who can play the drums, the guitar, and the trumpet and sing beautifully. But for most of us, it’s just not possible. We need to rely on others to bridge the gaps. Whether that bridge is an AI agent, another person, or a library, we can intelligently compose a complete stack by using these resources. By the time someone becomes a senior engineer, they will have had their hands on many different parts of the software technology toolscape. That is obviously highly valuable. In that sense you could call them a “full-stack” engineer. But what we really mean is they have a good understanding of how all the parts hang together, and they are able to combine the various parts effectively. It is also why true full-stack developers usually don’t retire. They become managers. Wasm beats Docker Docker was a great and influential idea. Make a portable processing unit that you can drop anywhere. But in practice, Docker can become quite unwieldy and its config files can be fiddly. In fact, there are times when I find the whole mental model a bit clunky. You have your actual software and its various environmental needs, and then there is Docker standing in between them as an extra layer of abstraction. But Wasm. Wasm takes your code and boils it down to a portable binary (analogous to a native executable). Bam! That’s it. It is the same level of directness as running a .exe in DOS in the 1990s. Simple. And, it’s fast . Whereas Docker has to boot up a Linux user space and virtualized file system, Wasm runtimes are designed for minimal overhead. Some of them even compile down to machine code. Of course, Docker is a well-understood part of the enterprise, with a wealth of tooling around it. It will remain an important tool. But Wasm has picked up momentum out of the experimental phase and is now becoming a truly disruptive innovation. Java beats Node, Go, Rust, et al. Thirty-year-old Java has suffered a reputation of being something of a relic. It was a lumbering, verbose, boilerplate-heavy behemoth, people said. Who needs “old Java” or “grandpa Java” when we have modern ecosystems like Node.js for async I/O, Go for lightweight concurrency, and Rust for pure speed, people thought. But it turns out that grandpa knows what he is doing. Sure, complaints like the need for public static void main just to run a small program are perfectly legitimate. But look more closely and you’ll find features that are state-of-the-art. In particular, what makes Java a server-side juggernaut is virtual threads (along with related upgrades like structured concurrency ). Virtual threads push the threading into the JVM, where the platform juggles them for you. This makes concurrency a service, similar to memory management. Virtual threads allow Java servers to scale to potentially millions of parallel requests with a single import change. Plus, virtual threads are completely compatible with the older thread APIs. Oddly, the must-try language of 2026 might be the one invented in the 1990s. Be open minded My advice, as a hoary old dude rocking in the rocking chair on the porch, is to remain open minded. When I started programming web apps, it looked like CGI and Perl would remain the king of the hill. Stay agile out there, people. And be sure to try HTMX . You’ll find a handy guide for getting started here .
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” Was Mark Twain thinking of software development when he wrote those words? ly:Arial;<br> mso-font-kerning:0pt;<br> mso-ligatures:none;<br> mso-ansi-language:EN;}.MsoPapDefault<br> {mso-style-type:export-only;<br> line-height:115%;}div.WordSection1<br> {page:Wor Software progresses in various ways. Mainly, we make a deliberate effort to improve things, and take up opportunities when they present themselves. Sometimes, we tackle a challenge for its own sake, like climbing the mountain “because it’s there.” That is, sometimes we are captivated by the inherent possibility in a project and just go after it. And out of this chaotic mix, we often rework, rediscover, or repurpose ideas in surprising ways. Most surprising of all, sometimes those ways turn back upon themselves—an old idea rises again to overtake a newer idea. Here are nine such examples, unfolding right now. Plain JS beats TypeScript Just when you think something is a done deal, a dead certainty, the universe will rudely contradict you. It seemed obvious that TypeScript was going to absorb the internet’s entire codebase. The simple idea of adding types to JavaScript made it a radically popular option for both programmers and the enterprise. But now it looks like we’re moving toward a future where JavaScript will absorb TypeScript instead. Not only are there efforts to make TypeScript-inspired typing a feature of JS (“ types as comments ”), but there’s a big effort to turn TypeScript into something like a linting step in the IDE. This is the new “ type stripping ” approach, with runtimes like Node.js replacing the type with blank space at run time, leaving plain old JS as the executable and entirely eliminating the unwieldy compilation step. In short, TypeScript is becoming a fancy linter for JavaScript. SQL beats ORMs SQL , invented in the 1970s, was a monumental breakthrough in data management. Alongside some other foundational technologies, it helped fuel the expansive growth of the internet. But unlike other foundational tech like COBOL , SQL has a special characteristic we often overlook — it is a fundamental, irreducible way of manipulating information. Of course, SQL is not the only way to deal with data. But relational data structures give us a rigorous and universal approach. Therefore it is understandable, if surprising, that SQL is seeing a resurgence after the hard pendulum swung toward NoSQL databases and object-relational mapping layers (ORMs). The very trait that some find objectionable, the schematic strictness, makes SQL a stable platform. SQL is now making its way into the browser , via WebAssembly (Wasm), offering a single data idiom across the entire network. SQL also is finding its way back into the server-side codebase, with simpler wrappers like JOOQ offering more direct access to SQL than ORMs like Hibernate. Why? Simply because abstractions inevitably add friction. It is a dicey calculus to trade the immediacy of SQL for the broad power of an ORM. Local IDE beats cloud dev environments The cloud IDE is the obvious heir to the local development environment. So why are we still glued to our local IDEs? It’s not inertia. It’s not just because that’s what we are used to. Part of it is the same “buy versus rent” mentality that is working counter to cloud deployments. Part of it is the highly personal feel of the local IDE. But it’s also the fact that modern laptops are absolute beasts. Even a modest business laptop will give a developer lightning fast IDE iterations. Although developers still tend to rely on a remote AI back end to furnish the ubiquitous need for AI power, the rest of the system fits comfortably in the local resources, where RAM and SSD deliver almost instantaneous results. Monolith beats microservices Microservices have their place. They are massively powerful when the situation calls for them. But—and it’s a big “but”—they are a gaping pit of overengineering and complexity when used willy-nilly. If the phrase “debugging Kubernetes” isn’t enough to make you shudder, consider that microservices inherently imply network latency at every service edge. The monolithic server model eliminates both of these drawbacks at the outset. Of course, one still needs to architect a monolithic server properly, or complexity will overwhelm its implementation as well. Plus, we have to acknowledge that addressing high availability and other QoS concerns increases the number of moving parts. But the tiered layers of the monolithic stack (data/service/UI) amount to a far simpler mental model. And it isn’t really an “either/or” situation. Most applications these days will incorporate some remote services (be they in-house apps or third-party apps), even when using a central server-side stack. But the tide has turned, and there has been a distinct shift in the momentum away from microservices and toward the monolith. In practice, it’s just a matter of identifying the path of least resistance—the minimum complexity that will solve the problem—rather than honoring what is considered “the way.” The desire for simplicity naturally guides architects toward monolithic designs whenever appropriate. Happy path beats integration Integrating well-tested tools into a cohesive whole is much smarter than building a comprehensive, bespoke solution… isn’t it? For the last several years, the “ Jamstack ” (JavaScript, APIs, and markup) and the “ modern data stack ” (combining best-of-breed, cloud-based data management tools) exemplified this philosophy: never build what you can rent. We were told to mix and match a dozen specialized SaaS platforms—one for authentication, one for the database, one for search, one for hosting, etc.—and glue them all together with APIs. But the reality of this approach is an oppressive integration burden. Instead of writing business logic, senior developers spend their days writing glue code to keep third-party APIs talking to each other. When one service updates its SDK, the distributed house of cards goes wobbly. The industry is now leaning back into “batteries included” frameworks. The philosophy pioneered by Rails and Django, and modernized by frameworks like Next.js and Spring Boot , is reasserting itself. This means we rely on a highly opinionated ecosystem—a “golden path.” While a meta-framework like Next.js or Spring Boot may lack its own proprietary database, it provides deeply integrated scaffolding (like NextAuth or Spring Security). It gives developers a cohesive, pre-wired environment. You still bring your own database or auth provider, but the framework entirely eliminates the brittle glue code. After years of vendor fatigue, developers are realizing that submitting to a unified, opinionated ecosystem is the ultimate path to velocity. On-prem metal beats cloud When Larry Ellison ridiculed the cloud “revolution” as a pointless fad … is it possible he was right? Probably not. But the enthusiasm with which the industry pressed toward cloud infrastructure felt overly extreme. At times it seemed almost cultish, as though there was something inherently wrong with running processes on iron that you own. Of course, there is plenty of benefit to be had in the cloud. But the industry has gradually reawakened to that eternal, fundamental question: “What’s the right tool for the job?” It’s simply a fact that sometimes an organization is better served to run the compute, storage, and/or network in-house. There are plenty of advantages to running systems on-premises, such as internal expertise, cost controls, predictable billing, and data sovereignty, that can tip the balance against the need to provision and manage their resources. Specialized engineering beats full-stack developer This is nothing new. It is not possible to master every aspect of the multi-headed hydra known as web development. The typical job description for a full-stack developer reads like an entire IT department . This is just not humanly possible. If you understand CSS grid layout like the back of your hand, it will push the knowledge of database design right out of active memory. Naturally, there are savants out there who can play the drums, the guitar, and the trumpet and sing beautifully. But for most of us, it’s just not possible. We need to rely on others to bridge the gaps. Whether that bridge is an AI agent, another person, or a library, we can intelligently compose a complete stack by using these resources. By the time someone becomes a senior engineer, they will have had their hands on many different parts of the software technology toolscape. That is obviously highly valuable. In that sense you could call them a “full-stack” engineer. But what we really mean is they have a good understanding of how all the parts hang together, and they are able to combine the various parts effectively. It is also why true full-stack developers usually don’t retire. They become managers. Wasm beats Docker Docker was a great and influential idea. Make a portable processing unit that you can drop anywhere. But in practice, Docker can become quite unwieldy and its config files can be fiddly. In fact, there are times when I find the whole mental model a bit clunky. You have your actual software and its various environmental needs, and then there is Docker standing in between them as an extra layer of abstraction. But Wasm. Wasm takes your code and boils it down to a portable binary (analogous to a native executable). Bam! That’s it. It is the same level of directness as running a .exe in DOS in the 1990s. Simple. And, it’s fast . Whereas Docker has to boot up a Linux user space and virtualized file system, Wasm runtimes are designed for minimal overhead. Some of them even compile down to machine code. Of course, Docker is a well-understood part of the enterprise, with a wealth of tooling around it. It will remain an important tool. But Wasm has picked up momentum out of the experimental phase and is now becoming a truly disruptive innovation. Java beats Node, Go, Rust, et al. Thirty-year-old Java has suffered a reputation of being something of a relic. It was a lumbering, verbose, boilerplate-heavy behemoth, people said. Who needs “old Java” or “grandpa Java” when we have modern ecosystems like Node.js for async I/O, Go for lightweight concurrency, and Rust for pure speed, people thought. But it turns out that grandpa knows what he is doing. Sure, complaints like the need for public static void main just to run a small program are perfectly legitimate. But look more closely and you’ll find features that are state-of-the-art. In particular, what makes Java a server-side juggernaut is virtual threads (along with related upgrades like structured concurrency ). Virtual threads push the threading into the JVM, where the platform juggles them for you. This makes concurrency a service, similar to memory management. Virtual threads allow Java servers to scale to potentially millions of parallel requests with a single import change. Plus, virtual threads are completely compatible with the older thread APIs. Oddly, the must-try language of 2026 might be the one invented in the 1990s. Be open minded My advice, as a hoary old dude rocking in the rocking chair on the porch, is to remain open minded. When I started programming web apps, it looked like CGI and Perl would remain the king of the hill. Stay agile out there, people. And be sure to try HTMX . You’ll find a handy guide for getting started here .