Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

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?

Will We Care About Frameworks in the Future?

Comments Filter:
  • by Pseudonymous Powers ( 4097097 ) on Wednesday November 13, 2024 @10:28AM (#64942543)

    "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".

    • by ceoyoyo ( 59147 ) on Wednesday November 13, 2024 @01:37PM (#64943115)

      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.

      • 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.

    • 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.

    • by Kinlan ( 138030 )

      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

    • 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.

  • Took me a minute to realize they were talking about web development. No, frameworks are just abstractions over HTML, Javascript, and CSS. They were never necessary. I hope AI puts webdevs out of business tbh
    • by Z00L00K ( 682162 )

      Frameworks can either help or be a liability.

    • 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.

    • by ebunga ( 95613 )

      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.

    • I think you're confusing simple business-card-like webdev with enormous, custom web-based applications.

  • by gillbates ( 106458 ) on Wednesday November 13, 2024 @10:39AM (#64942561) Homepage Journal

    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.

    • by Junta ( 36770 )

      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

    • If you don't have a problem to solve, then you're not using enough frameworks!

    • 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

  • by DeplorableCodeMonkey ( 4828467 ) on Wednesday November 13, 2024 @10:48AM (#64942591)

    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.

    • Funny thing is, I've always seen the opposite experience. That it was always simpler to implement your own servlet to do what you needed the way you needed it than having to rely on crap like these javascript "frameworks".
      • 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.

        • My approach to these situations is to actually build a set of libraries with the things I use the most, where the patterns to be used are more defined on paper than enforced via code. So if you need to do something a certain way on ten different pages you can use the same code, but where if on the next page you need to do something a little different you are not forced to do the same as the ten previous pages because of a framework. Consider it a "quasi-framework" but that leaves out the neurosis of trying
    • I'd rather go back to waiting tables than work with Django, Rails, etc. Life is way too short to interact with those steaming piles of crap, and the mentality of people who do like working with them is something I can also do without.

      I know, I know: I'm using it wrong. The Marxists say the same thing about their pet religion.
    • 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

    • 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.

  • ...specifically PHP ones. You have a framework consisting of 40,000 files just to design a website that has 15 webpages. This is nonsensical. Just write the 15 webpages and be done with it. Some light templating and include files and you're done.
  • by Fly Swatter ( 30498 ) on Wednesday November 13, 2024 @11:06AM (#64942635) Homepage
    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.
    • 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

    • 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

    • 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.

  • 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.

    • Antiquated thinking.

      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.
      • 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.

      • 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

      • 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.

        • Yeah, you're not doing loop vectorization or template metaprogramming in your head.
          • ok, first of all, you are an idiot, because C doesn't have template metaprogramming, that's C++.

            But more seriously, how often do you think compilers are doing automatic loop vectorization?
            • Maybe I'm smarter than you because I'm not the one who walked into a trap for pedants. ;-)

              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.
              • 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

    • It's not a problem to have repeated code when you are writing code, although it does take a little more time to type.

      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.
  • It seems just a little bit too soon to have so much reliance on AI that a human could never figure out what was going on if the AI all of a sudden refused to make a modification. Sure, it may build the page ok in the beginning but what about after modification 20, 50, 100...
  • by MpVpRb ( 1423381 ) on Wednesday November 13, 2024 @11:12AM (#64942657)

    ...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.

    • Maybe AI generators have been trained on the mediocre code quickly churned out by cheap, low talent workers?

    • This.
    • by garett_spencley ( 193892 ) on Wednesday November 13, 2024 @11:43AM (#64942763) Journal

      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.

      • by mugnyte ( 203225 )
        I can agree with most of your sentiment. Here are where we disagree: The structurally-opinionated "framework" becomes a new direction for the software portfolio management. Unlike editors or even OS, frameworks are now monitored, updated, kept in the upgrade-test loop. This is both good and bad depending on how you view change: Vulnerabilities and be closed, but new ones opened; bloat added but more commodification of features, reducing what your team writes. They react more to upgrades at the cost of
    • by bartle ( 447377 )

      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 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

  • by kwikrick ( 755625 ) on Wednesday November 13, 2024 @11:52AM (#64942789) Journal

    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.

     

  • by xanthos ( 73578 ) <[xanthos] [at] [toke.com]> on Wednesday November 13, 2024 @12:01PM (#64942813)
    The more you use code written by someone/something else the more you will be dependent upon your vulnerability assessment tools to sniff out the problems. Which begs the question, if someone is deferring to AI to write their code, how likely is it that they will be bothering to extensively test the code?
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Wednesday November 13, 2024 @12:28PM (#64942893)

    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.

    • "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?

    • by Kinlan ( 138030 )

      Thank you.

    • 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

  • 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

    • 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.

  • 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

  • The world of software development is so beholden by fads that it puts the world of fashion to shame.
  • This post has zero information. It's like confidently predicting that the sun rises in the east. If he had said that AI/LLM solution would have any problems under any conceivable conditions ever that would be news.

    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

  • 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

    • by Tablizer ( 95088 )

      Frameworks are generally an antipattern; what you want is libraries

      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

  • It will do exactly what human programmers have done over the last 75 years, and move from spaghetti, and duplication, to libraries, objects, and logic management.

    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
  • The comments so far are pretty much what I predicted. Most of them are along the lines of frameworks being overly complicated and only useful for low skill programmers. Although I'm not surprised, it's still disappointing.

    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

    • The problem with most frameworks I've tested is that sooner or later they give me the impression that they were written by idiots with no connection to reality. Where they try to impose a pattern that usually only works for a very specific and basic use case and that fails terribly (whether in bugs or performance) as soon as you start introducing more complex use cases.

      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

Dennis Ritchie is twice as bright as Steve Jobs, and only half wrong. -- Jim Gettys

Working...