Will We Care About Frameworks in the Future? (kinlan.me) 67
Paul Kinlan, who leads the Chrome and the Open Web Developer Relations team at Google, asks and answers the question (with a no.): Frameworks are abstractions over a platform designed for people and teams to accelerate their teams new work and maintenance while improving the consistency and quality of the projects. They also frequently force a certain type of structure and architecture to your code base. This isn't a bad thing, team productivity is an important aspect of any software.
I'm of the belief that software development is entering a radical shift that is currently driven by agents like Replit's and there is a world where a person never actually has to manipulate code directly anymore. As I was making broad and sweeping changes to the functionality of the applications by throwing the Agent a couple of prompts here and there, the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could.
I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?
I'm of the belief that software development is entering a radical shift that is currently driven by agents like Replit's and there is a world where a person never actually has to manipulate code directly anymore. As I was making broad and sweeping changes to the functionality of the applications by throwing the Agent a couple of prompts here and there, the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could.
I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?
Take me to your lizard. (Score:5, Insightful)
"As I watch the code pass by in Replit, I'd noticed that the Python and JavaScript it produced was vanilla and it would frequently duplicate the logic on different screens for the same functionality. It certainly wasn't that type of code that I would craft. I probably would have planned for the removal of repetition. I would have planned for the ability to extend and inherit. I would have planned for testability."
This thing is making bad code. And you're just watching it. Complexity is exploding, unchecked. It won't be maintainable. It won't be extensible. Not even by the thing that built it.
Also, I resent this guy's apparent conflation of patterns with "frameworks".
Re:Take me to your lizard. (Score:4, Funny)
They're not just watching, they're cheering it on, writing articles on the Internet about how great shitty code generators are.
I remember being in high school and thinking Dreamweaver was a great way to make a web page. That lasted right up until the first time I wanted to tweak something and took a look at the HTML it generated.
Re: (Score:2)
That's OK, I don't mind competing for jobs against people who think this crappy code is cool. I don't want to work for companies that think that kind of stuff is OK. Crap begets more crap. Been there, done that, long before AI.
Re: (Score:2)
All of this throwaway code ends up in production with executives leaning massive piles of promised revenue on it. This is not much different from inheriting a pile of steaming crap from Anderson Consulting or Cognizant wizards who whipped up a system in 3 weeks and then disappeared into thin air. It's going to need fixing, enhancing, changing, evolving etc. I don't know what this guy is building, but it doesn't sound interesting or valuable in the first place.
Re: (Score:1)
This is one of the projects that I've built - https://tldr.express/ [tldr.express] - it's on the simple to moderately complex side of things. They are valuable to me and that's how I think about this software - https://paul.kinlan.me/generat... [kinlan.me] and https://paul.kinlan.me/the-dis... [kinlan.me]
I do suspect you won't agree with me at all :D
Re: (Score:1)
I don't think I did conflate patterns and framework, at least in my head I didn't when writing the article. The code that the tools have been generating have been most successful when they've not been using frontend frameworks... and, the patterns that I would have normally followed or seem to be less likely to be used in the code it generates, however the maintenance and broad sweeping changes have not been an issue (and this is the thing that surprised me the most).
> It won't be maintainable. It won't
Re: Take me to your lizard. (Score:2)
Correct. Code generators don't care about quality. All they care about is here and now. And no real programmer will ever want to touch and debug your auto-generated code if anything ever goes wrong.
WebDev (Score:2)
Re: (Score:2)
Frameworks can either help or be a liability.
Re: WebDev (Score:2)
Frameworks are good.
I used Drupal to build a site because I wanted it to do neat stuff and I didn't want to build the security part.
Since I started using it long long ago it has switched to being based on Symfony, which has only made it better. It's frameworks all the way down!
You can reinvent the wheel if you want to. I have other ways to spend my time.
Re: (Score:3)
The only thing AI is going to put out of business are AI companies and maybe whatever cloud service they use that has to rapidly expand and then suddenly sees a 75% drop in revenue because all the AI companies froze to death during the next AI winter.
Re: WebDev (Score:2)
I think you're confusing simple business-card-like webdev with enormous, custom web-based applications.
The future is now (Score:3)
I don't care about frameworks now.
Yes, you may need to understand them if your current codebase uses them, but generally speaking, software engineers are called on to solve new and novel problems; if there already exists a solution to your problem (e.g. a framework, etc...), it is very likely that the business will just buy it, rather than employing you.
Learning frameworks is planning your own obsolescence.
Re: (Score:2)
I will give a pass to browser frameworks. The state of Javascript has improved, but largely stayed deliberately a bit dysfunctional.
The pace of improvement stepped up, but Javascript in the browser continues to be pretty bare bones with a lot of reluctance toward embracing higher order function directly. Besides, Javascript has a monopoly on network access and DOM manipulation in the browser ecosystem, so other languages that may cater to different paradigms cannot exist directly in that ecosystem (yes, com
Re: (Score:3)
If you don't have a problem to solve, then you're not using enough frameworks!
Re: (Score:2)
but generally speaking, software engineers are called on to solve new and novel problems;
I wish that were true, broadly. But after 26+ years in the industry, I've hit a point where it's a very rare occurrence that I'm asked to solve something that presents an actual challenge. It happens, but it's very rare. Most of the time, it's fairly routine.
To someone with 5 - 10 years in the industry, everything is going to feel new and challenging. But the more you learn about the craft and our history in the industry, the more you realize that there is surprisingly very little that's actually new in th
It strongly suggests these are just toys (Score:3)
Anyone who has used Flask, Django, Spring Boot, Rails, etc. doesn't even have to think about why they'd prefer to debug code an AI wrote against a framework vs implementing functionality with raw standard lib functionality.
Every good Java developer has seen the work of devs who decided to raw dog it with servlets to respond to REST instead of using Spring Boot, Micronaut, Quarkus, etc. That sounds precisely what this is generating, if not worse, and that's a resounding HELLLLLL NO.
Re: (Score:3)
Re: (Score:3)
Nobody loves using frameworks. Everybody loves creating frameworks.
Working with just the bare bones is great for simple, small applications. But after a while, almost every developer thinks: hey, I've done this before, I can reuse this code I wrote. I always do it like this (my way, the best way), so let's make it easy to do, make it generic, make abstractions, generate code, etc. So, they start building their own framework.
Re: (Score:2)
Re: (Score:2)
I know, I know: I'm using it wrong. The Marxists say the same thing about their pet religion.
Re: (Score:2)
We started moving to Java before Spring Boot et al existed. We provided our own framework to do that boiler plate stuff in a way that works for our crazy crazy system.
When we started moving to Spring, again, while using quite a bit of Spring Boot stuff we still have created base classes that we extend do do our things like RBAC, etc. and have it support our old style DB
And personally, I like it that way. We can write/create our own utils and such still, we can still leverage Spring Boot, and yes, it is MU
Re: (Score:2)
Micronaut, the land of annotations and interceptors. Stacktraces from hell. Don't try to live debug when one of those interceptors is involved. When everything is working, yeah it's fine.
Frameworks are too big and bloated... (Score:1)
Re:Frameworks are too big and bloated... (Score:4, Insightful)
Parent is insightful, but mods are not (Score:2)
Re: Frameworks are too big and bloated... (Score:2, Informative)
If all I wanted was static pages I could shit that out in Dreamweaver.
But when I want a comment system with security and logins I don't reinvent it. Someone else did the work for me already. And I don't want to think about security.
The "I can do this in my sleep" crowd is sleepwalking through their job, not focusing on quality.
Efficiency used to mean something. (Score:4, Insightful)
Which brings us to efficient code uses less resources and power. But damn that! Lets just build more data centers and power plants - modern coding is going exactly the opposite way of reducing it's environmental footprint.
But now anyone can 'code' in mere minutes with use of that big power gulping data center, the reader can decide if that's really a good thing.
Re: (Score:2)
I guess processing power and memory are no longer a constraint so damn with efficient code.
Guess again.
I've got devices that can play YouTube's videos just fine, but the playback experience is horrible and constantly stuttering. Thus is due to the ridiculous amount of JS that YouTube uses for the UI. It can get so slow that clicking something on the video options menu can take upwards of 15 seconds or more (with the menu already open!) because it needs to animate highlighting each option as the mouse cursor hovered over it long ago. Starting or stopping playback is just as painful. And it gets
Security and consistency trump efficiency (Score:2)
I don't mean coding efficiency, I mean efficient code. Libraries were supposed to solve this, but now everyone includes their own copy of the same library and the 'Agent's' code just duplicates the same things over and over. I guess processing power and memory are no longer a constraint so damn with efficient code. Which brings us to efficient code uses less resources and power. But damn that! Lets just build more data centers and power plants - modern coding is going exactly the opposite way of reducing it's environmental footprint. But now anyone can 'code' in mere minutes with use of that big power gulping data center, the reader can decide if that's really a good thing.
Most organizations choose frameworks for security and consistency from dev to dev over efficiency. You may be a talented programmer, but here's the rub, people like you tend to leave or get promoted. Now someone else will inherit your code. So you may write perfectly lean efficient REST services from core socket functionality. I use industry frameworks like Spring boot.
My vulnerabilities are patched by an external entity and easy to certify as being secure. Yours...well...no one knows if you have a
Re: (Score:2)
Most systems could run with 10-100x lower power if they bothered. Most processor cores are waiting on I/O most of the time unless they're being benchmarked by someone running linpack. Even if I'm running what used to be considered computationally expensive programs natively I'm not seeing a modern Mac M1 or M2 chip using more than 5% of its capacity at 5ms latency and no buffer overruns.
DRY (Score:2)
Don't Repeat Yourself isn't about not repeating code. It's about not repeating knowledge. But keep pushing this constipated AI agenda and see where it gets you.
Re: (Score:2)
When the AI becomes the de facto compiler, it's none of your business how it chooses to arrange code. Do you second guess everything your C compiler does? Do you even understand what it does? I didn't think so, except in the edge cases where some hand tuning is (a) actually beneficial and (b) worth the effort.
Re: (Score:2)
When the AI becomes the de facto compiler, it's none of your business how it chooses to arrange code.
... UNTIL something doesn't work the way its supposed to, and someone has to go in a debug that steaming pile. I trust my compiler because it is designed and tested to generate a deterministic output based on particular input. The LLMs are just barfing up something similar to what someone did on the web somewhere once upon a time, whether it actually accomplishes anything or not.
This is why real programmers will always have a job.
Re: (Score:3)
No I don't second guess the compiler, because I expect it to execute the standard operation it is expected to perform.
Yes I understand what it does. It translates what I write into computer instructions. There's no fuzziness here. It is not going to change the given logic or produce side effects. Ever. In other words, it is a dependable function. I don't care how a compiler arranges my instructions.
Now somehow we have people thinking that a technology with fundamental correctness issues (that is not a "faul
Re: (Score:2)
Do you second guess everything your C compiler does? Do you even understand what it does?
C compilers aren't doing something difficult. It's not magic. If you got a CS degree, you should have full understanding of what they do.
Re: (Score:2)
Re: (Score:2)
But more seriously, how often do you think compilers are doing automatic loop vectorization?
Re: (Score:2)
Don't pretend you know what the compiler is doing in any non-trivial case on an ongoing basis. Could you figure out one loop after much debugging? Sure, but that just reinforces the point.
Re: (Score:2)
Could you figure out one loop after much debugging?
Use the -S flag in GCC or use IDA-Pro, you can just look at the compiler output and know what it did. C++ template metaprogramming takes a bit to figure out, but it's not magic, and it's not even particularly difficult. Debugging isn't helpful.
Maybe I'm smarter than you
You're not smarter than me, but intelligence isn't relevant here. All you need to do is learn to read assembly and you'll stop saying ignorant things. Maybe learn template metaprogramming, too. I had a really good book on C++ metaprogramming; I would recommend it to y
Re: (Score:2)
The real problem comes later when you want to revise the code, and you need to find all the places that are relevant. Of course, computers can do some matching quickly, but given limitations like the halting problem, I'm not sure that is a tractable solution.
Too early (Score:2)
My favorite description.. (Score:5, Insightful)
...of frameworks comes from a guy on youtube.
Frameworks make the first few hours of a project seem easy.
Then they make it much harder as you run into quirks, bugs and rigid design rules that make it nearly impossible to do what you want.
Frameworks were designed to allow cheap, low talent workers to quickly churn out mediocre code.
Today's AI code generators continue the trend and make it worse.
Re: My favorite description.. (Score:3)
Maybe AI generators have been trained on the mediocre code quickly churned out by cheap, low talent workers?
Re: (Score:2)
Re:My favorite description.. (Score:5, Insightful)
I agree with some this assessment but strongly disagree with the rest.
What distinguishes a framework from a library is the "hollywood principle" : "Don't call us, we'll call you."
Libraries expose symbols that your application can consume and call into. Libraries sit there passively, waiting to be invoked.
Frameworks, on the other hand, are skeleton applications. They take a very active role, and call into your code rather than the other way around.
Both exist to cut down on development time, but a framework is by necessity a lot more opinionated and active than a library. With a framework, you are buying into its architectural design decisions as far as how your application will be structured and execute at runtime.
Therefore, the decision to adopt a particular framework must be made with care. Choosing the right framework is important. Choosing the wrong framework leads to the problems you described.
The last people on earth that I would want to be choosing frameworks are "low talent workers [who I expect to] quickly churn out mediocre code."
As a Principal with nearly 30 years experience in the industry, I LOVE frameworks. I don't want to write everything low level. I want the freedom to focus on the unique domain problems introduced by the specifics of my application. I don't want to be implementing a front controller or a router from scratch every time I start a new project, for example. And you're half-right in the sense that I've got a pool of talent that I need to lead, and this talent pool runs the gamut as far as experience level. So I want to give them as few foot-guns as possible. Therefore, finding a good framework that was designed by experienced engineers who have developed "those types of" applications (the specific category of applications that the framework is well suited towards) is essential.
Re: (Score:3)
Re: (Score:2)
My experience with frameworks is that they tend not to be maintained very long and it's not uncommon for them to be depreciated altogether. When that happens the developers are left in a real difficult situation. It's reasonably straightforward to replace to depreciated library but a depreciated framework probably means that the entire application needs to be re-written.
Dealing with an LLM for coding... (Score:2)
Dealing with an LLM for coding is a lot like dealing with a barely functional entry level programmer that will not learn.
As someone forced to deal with outsourcing to the lowest bidder, the 'make use of LLM' had a very familiar feeling to dealing with unqualified people crammed through the outsourcing firm to grift my employers, except:
-With the human, at some point you stop and say "ok, I have no idea how you are screwing up, and you can't seem to fix it, I have to look at the code and specifically figure
guy doen't care about good code (Score:5, Insightful)
From TFA:
"the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could."
So, the AI to writes crappy, bloated, unmaintainable software, and he doesn't care. Good luck when the customers come complaining, the AI continues to fuck up your code more and more, and no programmer will ever want to touch it.
Of course, lots of human programmers write crap too. So if you just want to replace crap with more crap, only cheaper, go for it.
Well, is it secure? (Score:3)
Re: (Score:2)
You worry too much. Just use AI to scan for security issues. What could possibly go wrong?
Modern frameworks are just APIs and compilers. (Score:4, Interesting)
For the web that is anyway. I'm a seasoned web-dev and been working the field for 24 years and have always closely followed developments. Browsers are 99% compatible, have all the key web standards implemented and then mountains of modern extra stuff on top. This all shows up in regular contemporary web-dev which has the avantgarde of web frameworks shrinking in the last 5-7 years anyway. Google Polymer has long since been discontinued and has been replaced by Lit - a very thin ~5KB standardized quasi-cosmetic layer on top of Shadow-DOM and JS template literals, Vue is moving fast to becoming a compact compiler like Svelte and Elm and the Angular team has caught on too and is moving rapidly towards the "compiler" style of web toolkits.
Laravel is basically just 100 different ways to do PHP in whatever way you fancy with truckloads of magic sprinkled in/dumped on and Symfony is a toolkit that combines all the downsides of PHP with all the downsides of Java.
Tailwind and similar solutions are basically just standardized APIs for CSS and/or HTML, with tools for tree-shaking (web-speak for "dead code elimination"), cleanup and rapid development added in.
The vast majority of the web can be done with preconfectioned components these days anyway and most of it already is. The rest is automated with a vast amount of web toolchains that have reached peak feature-bloat roughly 5 years ago and are thinning down again to make things easier, faster, less volatile and get rid of old compatibility hacks for Internet Explorer that we don't need anymore.
What frameworks have done on the feature-side is covered by modern browsers. What they do for development will be handled by AI.
This is late-game for humans doing web stuff. In a few years AI is going to be spitting out pure binary or WASM and I'll have even less to do on that front.
The Google guy is basically right about his assessment.
Re: Modern frameworks are just APIs and compilers. (Score:1)
"Symfony is a toolkit that combines all the downsides of PHP with all the downsides of Java."
I accomplish more with less code now that Drupal is based on Symfony. Isn't that the opposite of Java?
Re: (Score:1)
Thank you.
Geezer stack-bloat rant (Score:2)
Domain-fitting tools don't need frameworks. Desktop-based IDE's from the 90's made creating and managing CRUD apps a snap (when mature), took 1/3 the people and 1/3 the code to get the same app. The app code almost reads like pseudo-code.
The bloated web stacks turned CRUD bicycle science into rocket science. Many of the productivity-oriented things of those IDE tools had could be done over HTTP with the right standards, but everyone forces them through DOM/CSS/JS, which are ill-suited for CRUD and will prob
Proliferation of DSLs (Score:2)
I've always believed the future would be in the proliferation of DSLs with a declarative flare and lots of built in intelligence to effectively compile "what" into "how". If I want to create a UI there is a language for UIs. If I want to create a communications protocol, access a data store, run a physics simulation there are languages for each of these. All languages are designed for their particular domains with intelligence behind the scenes to allow operators to focus on what they want and avoid spen
Re: (Score:2)
A DSL is great if you're the person who created it. For the rest of us, your DSL sucks! The Groovy language on the Java platform was supposed to be great because it let you build DSLs with ease. That turned out to be more of a curse on the programming world than anything beneficial.
Fundamental flaws in program design are still here (Score:2)
Decades ago, there was a basic idea, you can write code, and get things to work, but on the flip side, writing code that is documented and could be understood by others was generally seen as a good idea, so others could help find problems in the code. You also have the idea of, coming up with a design for a program before you worry about the actual code. By having a good design, you will hopefully avoid the final program being a mess that is very difficult to find bugs. For multi-threaded code, you wa
Of course they will (Score:2)
So an LLM/AI zealot says AI will win (Score:2)
He is a 100% blue pill guy. The only question is did he use AI/LLM to generate the answer. Since there seem to be no hallucinations or odd turns of phrase I would guess not. If AI/LLM is the ultimate tool that does everything,why isn't he using it for this obviously trivial task? He's not eating
will there be a need for frameworks in the future? (Score:2)
First of all, frameworks are generally an antipattern; what you want is libraries [brandons.me] (though in certain cases it can be beneficial to have, and use, a small framework built on top of a larger library in order to encourage a standardized usage pattern).
Second, the answer is yes, there is still a need for better libraries, and no matter how good AIs get, this will remain the case. This is because libraries implement abstractions, and creating good abstractions is a fundamental activity of advanced intelligenc
Re: (Score:2)
UI (non) standards limit the power of mix-and-match libraries because UI's needed to follow strict standards or else mayhem results. You'd have to reinvent most the library for the next UI framework fad.
If we shift the UI to the browser (GUI browser) then we can focus on domain-specific libraries instead of taming wild mustang UI frameworks that will fall off the fad cycle in a few years anyhow, leaving nobody around who can fix them in 7 y
If you build the AI correctly... (Score:1)
LLM's can't do this because they can't reason, and can't plan, and can't optimize. Next gen ones that can refer to and build canonical data sources, and do basic reasoning and planning should arrive at similar solutions. They will still be horror shows for humans to try to work with, but they will produce better, and more secure, and more resil
Frameworks arose from a need (Score:2)
Common frameworks arose from highly skilled programmers recognizing cross-cutting concerns in their applications that would be better handled in a more consistent and less tedious fashion. Having authentication and authorization code for every page is nonsensical. Confirming that exa
Re: (Score:2)
And yes, I program for use cases that can be really complex, multi-user (thousands of users at the same time) and with security in mind a