Hacker News Reader

Comment by austin-cheney | Hacker News Reader

The are some very real costs to JavaScript frameworks. These frameworks do not exist to empower developers. They exist to:

* so that employers do not have to invest in training developers.

* to ease candidate selection at hiring, which greases the wheels of hiring/firing

In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks. This is Invented Here syndrome, and it reflects that internal developers cannot write software and employers will not invest in maintenance.

The larger costs there are human costs, the inability to efficiently solve any problem outside the constraints imposed by the framework.

View on HN

> so that employers do not have to invest in training developers.

This does not make sense to me. What do you classify as employer here? Front end frameworks are usually pushed by developers, not management. If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.

The push to create a SPA with react and other bollocks is purely pressure from implementers. There is not a day that I don't see devs that are more interested in making "beautiful code" and architecture despite the actual requirements they were trying to solve for. Ai is changing that, I hope for the better, but only time will tell.

The frameworks are almost always listed in the job requirements.

Why wouldn't they be?? That says nothing about who's pushing it. Companies ask for it because developers use it. That's what makes hiring easier.

Individual contributors are almost never writing job postings or performing hiring.

I didn't say they did. I said companies writing those job descriptions does not establish causality. You've got it reversed.

But developers tell the company to use it because they need it on their resume for the next gig.

I've seen sssoooo many startups use tech stacks that are completely unsuitable for their use case, but the developers are keen to use that stack because it's the latest hotness and it looks good on their resume.

> If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.

The reason we moved away from this and into functional/reactive programming with things like React is that it eventually creates a mess too big to untangle. We made this experience with human developers and I made exactly the same experience with LLMs, trying to go "vanilla". It works for a while but the defect rate rises quickly und the LLM spends a large amount of time navigating the mess it created. I ended up with React again because it lets you express a lot of stuff as pure transforms, which are easy to reason about for human and LLM alike, and the LLM knows it very well out of the gate.

And by "React" I don't mean "react router" and all the other unstable crap in the ecosystem. React itself is stable and that is extremely important for LLMs, otherwise it will constantly conflate what the API actually looks like now. Breaking API changes are poison, worse than going with an in-house library that the LLM doesn't know how to use, because at least then it will look it up straight away, rather than messing it up (because it _thought_ it knew how it is supposed to work) and _then_ looking it up..

A lot of times, most web app would be way better with purely server rendered pages. SPAs usually introduce a needless artificial separation. Too many times, I’ve seen an API that is tightly coupled with the web frontend instead of being agnostic and then starts being a maintenance nightmare because you have to coordinate across whole codebase because any Change Request updates the interface.

If you want an nice interactive interface SSR just won't do, it will inevitably leak. The separation between pure data and how that translates into UI through a wire interface is both natural and arguably desirable for many reasons. Typescript is a good language for UI. Java is a good language for backend. I disagree that evolving the API necessitates UI changes, or vice versa. You do need some amount of coordination of course, but if you can have developers do SSR, you can also have them do both SPA frontend and REST backend work - now more than ever.

Unless the interactivity would have span page reload, there’s no need for SPA. Figma, Spotify and Google Docs are food candidates for SPA as they have state that need to survive page navigation.

But in most web apps, interactive widgets are just little islands in the page. The higher concerns are routing, authorization,… which are already handled by the browser/server interaction.

>there’s no need for SPA

Many people phrase it like this, insisting that server-rendered HTML is simpler. To me, SPA's are the simpler approach. They remind me more of the .EXE's I used to ship.

The complexity is in the host of tools, libraries, and processes to build and deploy the SPA.

As long as you stick close to first-party defaults, you can circumvent almost all of that. I've had far less trouble with build steps in SPAs that follow this philosophy, than with most native environments. It only becomes an issue if you need to layer tons of individual dependencies for things to work.

I also stay away from dynamic prerendering and/or hydrating. If an SPA can't be hosted statically, it should have a very good reason.

IMO building around Vue has really paid off over the last decade. They fixed the frequent Webpack config issues with Vite, they fixed the frequent Jest issues with Vitest, they improved build times a lot with Rolldown and oxc, they fixed all the annoying linter/formatter config stuff with oxfmt & oxlint, and Vue itself prevents tons of issues that plague React projects.

I maintain a large reservations platform that I built as a SPA. Reservation systems are something that definitely needs to maintain state across pages, and where for instance the status of a customer's upcoming or cancelled reservations aren't simply walled off in a widget, but have effects across what actions are available to the customer. So it's surprising that so many of them are these terrible, slow and disjointed frankenstein SSR sites. (Think e.g. British Airways).

As with any SPA it should also be considered a problem if widgets updated themselves out of sync. My bank's reactive has this problem, and it's maddening. So my approach is to have all widgets and UI refresh upon central events from a single source of truth that's progressively updated as a data bundle from the server. Long poll the whole set of customer data, refresh it immediately after actions, and have those both trigger events that are recognized by all my vanilla widgets. What are we talking about? 15k over the wire every 30 seconds or on demand? Widgets that know how to adjust if something relevant to them changes? No big deal.

It's a different paradigm from either reactive or server side rendering, and the main advantage to me is the data consistency, as well as the development ergonomics of essentially having every UX element be just a view of the same data.

SSR on reservation systems looks incredibly cumbersome to me. Especially all those that still use crazy GET strings to hold state. "Pages" and user state are a front end concept.

“Pages” is indeed a presentation concern, but state isn’t. Often in SSR, user state is stored server side and identified by a cookie. You only need this cookie on the presentation side and not have to store a copy of the whole state like you usually do in a SPA.

In most SPA, state is distributed with two copies floating around. Even if you do restrict the update flow, it’s still a lot of works to keep it consistent. That’s good enough when it’s partitioned and each side take care of its own state, but in most cases, the intersection is very large.

With SSR, the “page” is a dead copy. The only source of truth is the backend.

> In most SPA, state is distributed with two copies floating around.

In all client-server systems, state is distributed with "two copies floating around". The difference between SSR and REST+SPA is that in the SSR, your server code is creating the markup to make it presentable to an end-user, but it's still fundamentally a copy of the state that exists on the server, and it's not obvious why the transformation to markup rather than structured data (like JSON) is desirable on the server. If anything, with SSR you need to copy more state from the client to the server, where it doesn't really belong.

Either one can show a user stale data. Both need backend checks on user actions to make sure the user's view is current.

In my SPAs, server calls and the state copies they return to the client are numbered sequentially from the start of each session. A server response with a number earlier than the last client call is ignored. That mostly takes care of race conditions that arise from latency. Fundamentally this is similar to SSR in that the client will not update until the server sends new data... there is no client-side modification of the client data copy, ever, so it can never diverge from the last known server state. That would of course be a disaster. The difference is that the page can change progressively without reload, and the state is available between "pages" without more calls to the server.

This is exactly the approach I advocate for, always rerendering whole app on any data update. The components are very simple, basically just views parameterized by passed in props. The data fetch is in one place. Components notify top level on data change which necessitates a fetch/rerender

Unfortunately I get shouted down by those who think we must be maximally efficient even though in makes little difference in render time, and hate “prop drilling”

From my own experience, I suspect you are conflating correlation and causation.

I have seen countless "founding engineer" job ads with every little detail of the desired stack/architecture spelled out: Java/Spring/MySQL/Linux/Log4J, C#/RabbitMQ/MSSQL/SSIS/Windows, etc. Non-technical founders/recruiters/etc don't want to "leave things to chance", and will happily overly specify the constraints, mostly informed by popularity ("Nobody Gets Fired For Buying IBM"), rather than leave the solution space unconstrained for some "generalist" to choose. I mean, how do you even know someone is competent if you can't grill them on a concrete set of buzzwords?! The horrors! So of course the recruiters gotta make up constraints to find someone "qualified".

Heck, I've personally seen this pattern at every step of company growth, from 5 employees to hundreds. I've watched as my employer's recruiters would explicitly seek tons of things we weren't yet using. Why? Because when performance isn't as desired, the first thought is not "hey, maybe our approach to managing people and projects is dysfunctional", but rather "maybe we just haven't found the silver bullet yet; let's go shopping". In my experience over 20 years, that represents 99% of the cases where new crap gets introduced: Scrum, Jira, SQL Server Integration Services (SSIS), front/back end frameworks, consultants ("our developers must be idiots, so let's get outside experts"), etc.

I think it is true that there are cases where developers will push for things like particular front end frameworks, but that's almost always the exceptionally rare case where there's any resistance to push against: few companies aren't already using the stack du jour, so most developers (especially greenhorns) will have bought into that stack ('cause "gotta pay the bills"), so a new developer brought into a nonconforming engineering org will quite likely want to use the tools they know and thus push for it. The real culprits, though, are usually the non-engineers: founders/recruiters/etc who create a financial imperative to adopt whatever is trending, which results in developers who spread that popular mediocrity elsewhere.

> If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.

This is backwards. The pressure from the business/product side is to create more and more interactive applications. Jquery hit its limits supporting that reasonably, sometime around the early 2010s.

>> Front end frameworks are usually pushed by developers, not management.

The last ten years I spent as a front-end "full stack" dev and every time there was some new shiny JS framework, all the devs would get out their tiki torches and pitchforks, go to management and tell them they should really really move to this new framework because blah blah blah.

In less than five years our department did this:

backbone -> angular -> react -> ember -> next -> vue -> svelte -> and finally back to angular/react which is what a majority of what we build with now.

Doing this insanity also created a way for mangers to make sure their year-end reviews looked good and polished. Every time an app that was built on a framework a few years old, suddenly a manager would declare it "dead" and needed to be re-built in record time (because the new framework allows devs to build Rome in a few days time). We would bust ass, usually hitting the deadline with something put together with duct tape and code no dev would willingly sign off on. Manager gets their raise and bonus at the expense of a host of devs running for the door.

Rinse, repeat. But 100% of the framework changes were always pushed the hardest by the devs.

> These frameworks do not exist to empower developers

I don't think we should discount the overhead that goes into making a component system with state management, and how much that simplifies application design as it allows you just to focus on data flow. The leap from a render function with a declarative dom DSL to something with state management in terms of complexity is nontrivial, and the amount of code you can you clean up with going from one to the other is also massive.

I get everyones definition of a framework slightly differs, mine is mostly when there's some level of inversion of control that you need to buy into through an app, and I think component system fits that description. Even so it may be a less contested kind of a framework.

Rich Hickey created the Clojure programming language to avoid complexity, and so it very deliberately does not employ OOP.

Component systems are the new OOP. They are numerically complex. People think they are all the rave and I don't know why, but then people also think OOP is generally all the rave and I don't think they know why.

You don't need component systems, but if you choose to go down that path just realize everything is far more work because there is tremendous amounts of duplication both explicitly in your logic and under the hood where you are not looking. Most people who believe they need this are locked into an enormous framework and deliberately avoid looking under the hood, because its a giant scary beast they believe they cannot live without.

If you want simple you will do everything in your power to avoid component systems, because simple does not mean easy. Rich explains it better in what might be the best computer science talk ever given: Simple Made Easy

https://www.infoq.com/presentations/Simple-Made-Easy/

React Components are actually a far cry from OOP

React is actually more functional than anything else.

Of course if you actually try to be pure functional many developers will scream at you “prop drilling! Code smell!” But to me that it is a much lesser evil than useContext() and what is essentially global variables

An important trait of good functional code is use of persistent data structures. JS code using React is anything but that with state hidden across numerous tiny functional closures.

The only language/framework that is truly functional in that sense is Elm.

I say this as someone who has done their fair share of Haskell, this just isn't a problem in practice, unless you're inexperienced or working with no experienced people.

I get this isn't everyone, and not everyone has the luxury to work in settings where this is a nonissue, but in those settings it sounds like the technology is being used as a restraint jacket for dysfunctional organisation.

When its been a problem, its always because the organisation was dysfunctional, "design" and "engineering" was what people did post humorously to justify spending time on their hobby horse.

Like 99% of components I've written project props on into other components and interpret them in purely. I often manage application state in external stores, which are decoupled from the view.

I should have mentioned language/framework for JS. The thing with Elm is that it gives a straightforward way (even if verbose) to design the whole app around persistent data structures. That gives so many benefits especially long term (time-travelling debugging support, easy insights into app state, full coverage by unit tests etc.). On the other hand my experience with React is that the state hidden in all those functional hooks is hard to debug and reason about with completely unpredictable and non-intuitive behaviour. I think the switch from class components to hooks was a big mistake.

If all you're doing is generating static HTML sure, I'm sure your toy library templating system or whatever pure declarative functions Rich Hickey gave you permission to write works perfectly fine.

But I'm talking about interactive UIs which need state, as the environment its running in (the browser) is inherently stateful, and there are efficiency gains from doing so.

This isn't just an OOP thing, even in Elm & Purescript there are similar libraries for stateful UI. In you're doing anything like that in Closure or Clojurescript or whatever, I guarantee you its built on similar data structures and its foundation has many equilivant constructs.

I have no idea what you are talking about.

My large SPA achieves full page load with state restoration in under 150ms. You don’t need React or components to achieve simplified state management.

Extraordinary claims require extraordinary evidence. Let‘s see it.

It’s not that extraordinary. HN loads even faster. The React approach just isn’t fast. I recommend visiting multiple sites and using Chrome’s performance tab.

HN is not a complicated website. At all.

> The React approach just isn’t fast.

React is pretty damn fast and it's not even the fastest framework out there.

You‘re advocating for functional programming and then you go on to disregard a functional approach as the new OOP. Once again, your comment makes little sense.

You clearly did not understand the comment or watch the linked talk. You saw only what you wanted to see.

I just saw that I wasted time debating a person that named an anti-framework law after themselves in their HN profile. So nevermind.

How you can make this argument then present the most unreadable memory hog mess of a language that’s really just functional sugar on top of Java as the example is hilarious. You must be trolling.

Clojure supports multiple run time environments including JVM, V8, and .NET. It is not syntactic sugar on Java and I did not use it as an example.

Maybe in the much later stages of their lifecycle but probably most if not all JavaScript frameworks start to empower developers seeing as they are made by developers.

Would you mind elaborating? React[1][2], Angluar[3], and jQuery[4] all started as personal projects to abstract architecture for use by other people. These things started in an age of JavaScript years before TypeScript was imagined when writing large expansive architectures in JavaScript was a real risk. Full stack was not a thing yet and IE was still very real. However, most developers at the time were not writing large applications, at least not in this language. The primary concern for most developers was make things easy. I remember this was the intended selling point of AngularJS (first version) and it looked like garbage for Java developers.

[1] https://blog.risingstack.com/the-history-of-react-js-on-a-ti...

[2] https://medium.com/@sjarancio/reactjs-a-brief-history-3c1e96...

[3] https://medium.com/the-startup-lab-blog/the-history-of-angul...

[4] https://medium.com/@andrewchall92/how-jquery-was-born-a-brie...

Now if you have written your own applications nearly 60-80% of it executes outside the browser even when the only interface and use case is in the browser. The current common use case for these frameworks is that most developers cannot write original software and when they try they either fail, with plenty of face-saving excuses, or just create something that looks identical to their favorite framework. This is the primary problem these frameworks currently exist to solve for.

I think mostly your comment seems to agree with what I remember, except that even during the hayday of jQuery, "full stack development" definitely was a thing, as I myself entered my professional career as a "frontend + Zend Framework" developer essentially, and was hired as such after a short internship. Before we were called "full stack developers", I think the title was basically "webmaster", at least that's what seems to get closest to it, these were to people who knew the entire stack and maintained it, maybe this is what you're alluding to.

>The current common use case for these frameworks is that most developers cannot write original software

It most certainly is not.

It absolutely is and comes with all kinds of bullshit posturing from people simultaneously explaining how awesome they are while qualifying what they can’t do without their framework. It is the kind of lies I see from my autistic kiddo where they know they have fucked up and try to paint a rosy picture in 6 or more conflicting stories.

It’s really simple. You can write an original application in your own code or you just can’t. I don’t care about all the excuses, because it just isn’t that challenging. It’s not for everyone.

> It’s really simple. You can write an original application in your own code or you just can’t. I don’t care about all the excuses, because it just isn’t that challenging. It’s not for everyone.

This is insane goalpost moving. What defines an original application? Do I have to write the entire browser? Do I have to write the JavaScript engine? Which JavaScript version am I allowed to use? Can I use TypeScript and transpile?

Software engineers are called such because they use the tooling available to them to create something original. It would be idiotic to not take full advantage of available tooling to do that.

Lots of people can, but why should they if their clients are not paying for it? Even worse, if they switch developers, they now need to onboard them into bespoke solutions with little to no public documentation.

I would never hire you and people with that purist of a mindset.

In my last job I worked with someone who went on holy wars to troll people without evidence. I am not interested in working with anyone who seeks conventions over measures.

Is the "troll" still working there?

He was fired for a variety of things like withholding client communications, poor performance, absenteeism, lack of project awareness/status. It was pretty bad since he was in a leadership position as the Task Order Project Manager for a very high visibility project.

> I am not interested in working with anyone who seeks conventions over measures.

This is exactly what you're doing. You're seeking the convention of building your own over the measure of valueable developer time

Why do you keep being arrogant and wrong? Developers use frameworks because their clients are not paying them to reinvent existing stuff, not because they‘re all horrible at their job (you, of course, are the best of all)

> In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks.

But this is... true? Non-core software gets the shaft in resources / development, especially at non-software companies. And for most companies the underlying web architecture are not a core business. For Facebook, Amazon, Google it is, that is why they are often the ones making frameworks.

Fact is frontend development is very complicated and the platform doesn't provide enough support for large projects.

Internally written software does suck? NIH syndrome is always referenced as a warning not as an aspirational thing, even smaller companies need to focus on their business model not JavaScript frameworks.

That said, almost every JS framework degrades to... a browser, do whatever you want, I find it hard to believe any have actually limited your ability to accomplish something unless it was truly beyond the ability of a web browser.

I am not sure what you mean by limiting my ability. When you aren’t using a framework you have maximum freedom to determine all design decisions in the code.

It feels like you've invented some definition of a "framework" that no one else is using. Or why not go deeper and argue against libraries and APIs because they limit your design decisions.

No OP is correctly using the term "framework" as it's widely understood among those who develop them.

Libraries are code that you call to perform specific tasks. You control the program's structure and execution flow. You're in charge and you call the library when needed.

Frameworks invert the relationship and call into your code and hence dictate the overall structure and execution flow of your application. It's in charge and it calls various customization points that you provide to it at predefined points.

These definitions largely date back to the late 1980s with the introduction of object oriented frameworks (see Designing Reusable Classes from 1988). Further references include:

https://en.wikipedia.org/wiki/Software_framework#Comparison_...

https://martinfowler.com/bliki/InversionOfControl.html

It's obviously a grey zone, but React is generally considered a library more than a framework, and it definitely seems to be among OP's vexations.

React "is a library" in the sense that it has primitives you can procedurally use like normal javascript, but in practice it definitely is used as framework with all the usual dogmas.

No, Next is a framework, React is a library. You could write React components in a web framework on a completely different stack if you wanted to, same with most JavaScript rendering libraries, which was my original issue with OPs comment, the bulk of JavaScript libraries noted in the article don't limit you at all.

No, react is a framework composed by countless react-* packages.

Everyone always ends up fighting the framework. Work on a project long enough and it happens every time. It's understandable because the framework wasn't designed with your project in mind.

Yes, this closely aligns to the Law of Leaky Abstractions.

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

And after you do it 2 or 3 times you extract the repetitive work into a framework. Not sure if you have never got to that phase but it is quite weird to see a programmer that does not like (or understand) abstractions.

I use functions for what you describe. I don't need a framework to accomplish reuse.

Also, the framework worship is always a bit bizarre to me because the front end of even the largest of single page applications is relatively tiny compared to the supporting back end. If a developer is writing the entire application then why invest so much effort into over engineering such a small slice of the total code? It isn't productive unless it is the maximal extent of a given developer's capabilities.

> I use functions for what you describe. I don't need a framework to accomplish reuse.

A framework is composed of many reusable functions. You are really confused, arguing for this nonstop on HN for years. Not sure what you get from this but as someone mentioned, just show us the code and what you call a complex system developed your way. Code talks.

He won't. At this point I'm not sure if the user in question is mentally unwell or maybe even a robot. I've made the same observations as well.

You are not the only one. It is funny because initially I found his opinion slightly interesting as I dislike React and all frontend frameworks but my solution was to create my own. When you do more than 2 projects using the same base you have a framework. He can't realize that.

I am not going to show you my code. You wouldn't understand it and then you would bitch and cry that its not your favorite framework. Agreed in advance, its not your favorite framework. It works differently.

If you operate purely from convention then what does it matter if I did show you my code? What do you hope to gain from looking at something you have already dismissed in advance?

I have to say that I too am curious to see your code given the confidence and assertiveness you express yourself with. The excuse about knowing the critique in advance comes across as quite a reach, not to mention "you wouldn't understand it"..!

I have had similar conversations with framework cultists in the past. Not showing the code is something I have had to learn from past experiences with repeated results. If people were authentically interested in seeing JavaScript applications not written with React there are plenty of examples out there.

>Not showing the code is something I have had to learn from past experiences with repeated results.

lol sure!

Here is the code if anybody is curious:

https://github.com/prettydiff/share-file-systems

Just a poorly specified framework built on endless amounts of appendChild, createElement, etc.

I think you entirely proved my point. You did not understand the code and were just looking for something to bitch about. Strangely, you also ignored that this application is only a tiny fraction of front end code and a years old dead project.

Maybe your next magic trick will be learning to read.

We had this discussion in the past and at the time you were not ashamed to show this code of yours. I told you it is bad. It is really impressive that you talk so high of your programming skills on every JS thread tho. And it is not AI psychosis although it is very similar.

Let's make it simple. Is there any other code that is open source that it is as good as yours that you can point us to it?

Austin is most likely not a developer, none of his comments make any sense. All of his comments boil down to purist opinions and contradictions.

> All of his comments boil down to purist opinions

not even that, it is just an obsession and disconnection from reality. There are multiple benefits from not using frontend frameworks, React is really, really bad. He doesn't understand that the correct way tho he is right by pure coincidence.

He may be right in this instance (I personally disagree, I supported my family for years using React and built applications that generated millions of $), but frontend development is relatively young. We're seeing a consolidation effort though. What I hate about React isn't React, it's the ecosystem about it (mainly Next) and the effort to get it on the server.

As a developer, React, Vue, Svelte, and the like absolutely do empower me to not have to deal with all the pain-in-the-ass bullshit of the jQuery and Gulp days.

The impact of framework/tech-stack mostly reveals itself, once the project is big. For small/medium projects you might not notice.

> a culture that strongly believes internally written software sucks. This is Invented Here syndrome

It's the inverted invented here syndrome ;)

But it is oh, so true. Entirely, unsurprisingly -- an internal software stack has captive audience, and never compete with anyone else.

They can good, but exception to the rule.

> It's the inverted invented here syndrome ;)

No, I think they had it right. Your "inverted invented here syndrome" would be the original NIH syndrome, in which people prefer building their own version of everything.

I think you put way too faith in a human capacity to plan in such a "long-term".

That's where most complo theories fail...

Their biggest plus, which some HN commenters baffingly either don't get or ignore, is that another company and volunteers pay for maintenance. If you roll your own - and you will, if you're not using one for a larger app! - you're now paying for library code and your money making application, thereby making less in total per hour spent.

> If you roll your own - and you will,

This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.

No, it is the painful experience of a decade of frontend software engineering and consulting, thank you very much. I‘m not talking about someones blog here, I‘m talking about commercial, complex applications.

If you plan to sell a digital product or SaaS on the internet and your use case is more complex than a blog or a portfolio site, your „vanilla js purity“ will outgrow the project, fast, and it will become a mess. I‘ve never not seen it end this way.

I have been writing my own large applications in JavaScript/TypeScript for 18 years and watching other JavaScript developers not figure out and blame everything else for their inability to program. I have never needed a framework or tried to recreate one.

I do tire of the failure to perform and the endless empty excuses.

Uh huh. So you don't have any repeated code between those large applications? Nothing was copy and pasted? You've never re-used a single thing?

If that's true, that's just pointlessly wasteful of your time and effort.

Sometimes you just write enough code for the problems at hand and not go for a generic solution. And then the result is a few hundreds lines of code, instead of 10gb node-modules folder.

Yeah! That's definitely the case sometimes-- just not when writing "large applications" like the GP.

Even when writing large applications. It’s not like you’re using every method in a library or even the most important part. This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk). Then they start to believe that one can’t write large software with simple code.

Again, I definitely agree with all of that! I'm just trying to say that there's no reason to be such an absolutist. I try my best to use as few dependencies as possible in every project, but I would never pretend like frameworks are categorically useless.

Like most things in life, the best answer for each situation is layered in nuance. There's a reason that it's such a meme for senior engineers to answer most questions with, "it depends."

If you're using React, you're using 80% of what the library exports. It's actually pretty tiny.

> This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk)

Here's some news: If you build your pretty native binary for your target operating system or the browser, you're using tens of millions of line of code.

HN has decided React is why some ad-infested SPA they hate to use downloads 15 MB over the wire and can't accept that it's like 150 KB.

"Large applications" like hundreds of lines of code? Uh huh.

For reference, my last job at an industry giant had a frontend-facing monorepo of a million lines or two.

React is like 150 KB, I feel like people ranting about "React" monstrosities don't actually understand the distinction between React the framework and other unrelated junk React doesn't require or depend on at all.

The cool thing about owning your own decisions and not being utterly terrified of architecture is that refactoring is low risk and low effort when you have enough test automation in place.

The more I read of you the more I'm sure you're just putting on a facade. The effort needed for refactoring has nothing to do with "owning your decisions" or "being terrified", and your clients are certainly not paying you for it either.

Your numerous comments unintentionally reinforce my top comment. One of the primary use cases for these frameworks is to avoid training and investing in developers.

How does me disagreeing with you affirm that statement? It does not. „Investing“ means you‘re expecting more in return: What would that be?

It's sad that you were never given a chance to clean up your technical debt, as it seems to have marred your perspective.

It's not your fault, since most companies don't want to invest resources on properly maintaining their code.

Those are some weird, incorrect assumptions that you have!

It's not your fault, since assuming the best about people on the internet is not actively rewarded by social media these days.

Thanks.

"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?

So you spend time fitting the cartwheel you had handy to their 18-wheel truck?

We have different wheels for different use cases. You can't use the same wheel for all of them.

No. I choose the tool that is best for the project. I don‘t reinvent tools because I don‘t get paid. Miraculously, I‘m fully booked out.

But you are claiming the opposite in your replies to me. You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?

> You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?

You wrote yourself that you roll your own and you insulted every developer who doesn't. The best tool for the job is the one that doesn't unecessarily strain your customers wallet for no extra gain.

How many colleagues have worked with your codebase?

In my oldest project, which I have not worked on since 2019, I received a bunch of pull requests from other developers.

It helps when you write software other people want to use and provide good enough documentation.

So you admit your workflow does not reflect in any way or form the needs and processes of even a small to medium org, let alone half a dozen teams or more? That's not a great point of few for someone with opinions that strong on purity.

So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.

Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.

> So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.

Then it is not complex enough to support the needs of large projects.

You admitted it yourself. You work with a small group of people in small projects, but you got huge opinions.

Building a bespoke framework, for nothing of value except because you want to, isn‘t investing in developers, it‘s creating a huge cost factor for no gain.

How can you say that if you don’t know what my approach is? My current project is moderately large at nearly 100 files of TS code of which some are thousands of lines. It does not employ any framework and does not create its own framework.

Well personally I would not gloat about my genius non-framework code if it had files with "thousands of lines".

Its not a brag. Its just not small and its not a framework. How else would you make that point?

100 files of TS code is not moderately large.

How large were these applications?

I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.

How are you convincing your clients that they should pay a senior to re-engineer solves problems?

That’s easy. When you can deliver a smaller product in less time you are saving the client money. Sometimes reinventing the wheel is as simple as copy/paste.

So, you do copy and paste.

So, you just made a bespoke framework with the most inefficient version control system possible.

Then… what is a framework?

The code you reuse every time you build a website. Are you done playing coy? Or, do you really not understand what I'm saying?

I don‘t think he does. I had the same problem. Either he‘s willingly obtuse or the matter is beyond him.

A single dev can churn out a basic React app in like a single workday pre-AI, the important parts are not at all hard to understand and you get reactivity out of the box which is a lifesaver later on as your app grows in complexity.

I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.

A day is a very long time when the architecture is supposedly already well known.

Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.

You‘re not understand it because austin is trolling.

He's either trolling or he is genuinely dense. I'm leaning towards the latter at this point.

He may also be unwell. He‘s in every single thread that mentions frameworks.

So for my question about large projects you shift into small projects. Got it. Nice goalpost moving.

I take a more nuanced view.

I've seen the situation where underqualified, overambitious programmers build an internal platform that becomes a monster. There isn't the time to mature it, there isn't a standard or docs to point to, it becomes a drain on the company, at worst someone's vanity project.

I've also seen the situation where a team absolutely refuses to build anything themselves out of anxiety, spending enormous amounts of money on an external solution that acts as a rent extractor.

The problem with buy-not-build, is if you do it for too long, you forget how to do the latter. This is great right up until you find a problem you can't buy your way out of.

Sometimes building something half good, is fast enough and educational enough to get you to the next step.

Exactly. When I realized my homegrown JS DOM management had grown into a version of Vue.js that I was the sole maintainer of, I switched to Vue.

There’s still value in building something from the ground up; you understand the framework that much better. But so long as your needs largely overlap with the community, the benefits of working with the community are real.

I've worked at a dozen clients where, like in every software project, tech debt accumulated. Suddenly, when the DOM manipulation code or reactivity had bugs, I had to think about both sides of the coin - was the bespoke homegrown framework causing a weird interaction, or was is the component I worked on? One can hate React/Vue/Svelte or their models, but you can place trust in their maturity if you choose correctly

I mean this is quite literally what happened at my current firm. We forged our own path for good reasons, it all sucks, and the firm pays millions of dollars a year in dev salaries to maintain it.

My coworkers are very smart -- smarter than me -- so I'm low confidence anyone else could have done significantly better or avoided the pitfalls we fell into.

I've seen this exact scenario bankrupt firms and cost people smarter (but more arrogant!) than me their jobs. No handyman will ever shit on other people for buying and using tools instead of forging their own hammer. But somehow there's this facade of people on HN with this weird attitude.

Its a matter of practice and measure. If you can build your own hammer in less time than it takes to drive to the store and back then building your own hammer makes complete sense. People irrationally fear not using frameworks for things not measured. If other people want to continue that irrationality, for whatever reason, then so be it.

> Its a matter of practice and measure.

It really isn't.

> If you can build your own hammer in less time than it takes to drive to the store and back

You can't and your analogy doesn't hold. I've been writing JS frameworks work a decade, as have millions of other developers. They don't "drive to the store", they install their tool of choice in one second. You either build and maintain yours for hours or you copy paste code (which equates to the same).

> people irrationally fear not using frameworks for things not measured.

It is very easy to measure the hours spent.

> You can't

How would you know? You are choosing conventions over measures. If you measure nothing you have no idea what is faster or not. I have been doing this work for nearly 20 years and many JavaScript developers claim measuring things is easy, but they never do it. When pressed on it they never have and don't know how. Instead they guess at performance to reinforce their own preferences. I have an autistic kiddo that does this and everybody sees right through it.

> How would you know? You are choosing conventions over measures.

Because I worked in the industry when we all used jquery and I see the difference in real billable hours to nowadays. The entire industry has measured and shifted. Do you think million- and billion dollar companys shifted towards public shared framework for funsies and parties?

No. I don't have to hire an engineer and teach him our company bespoke framework. I can hire a react developer and he's productive from week one.

This is exactly what I posted in my top comment.

> another company and volunteers pay for maintenance

That is and has been a very good argument. One thing I do notice though is that, with the emergence of agentic automatic maintenance workflows, that same maintenance surface seems to start shrinking right now.

An illusion, I suspect. All software needs maintenance, and someone driving it, even if they are prompting an agent.

Maybe in some cases. In my experience maintenance often comes with exploratory work, the kind of where one needs to invest time, not to think about how your own side should work but in dissecting how a dependency or a target platform works in order to identify specific quirks that come and go with the passage of versions. I have seen significant acceleration in these kinds of workloads. This doesn't mean it makes maintenance free like some claim. It just makes it about 70% less of a burden

How is this an illusion? Thousands of people work on React, Svelte, Vue, Chrome, Linux, etc. Most aren't paid

I was referring to the (potential) illusion of home grown agentic solutions being lower cost/effort over the long term.

You're committing the very sin that the original article fingers as the problem with the webdev culture.

The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.

The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).

* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)

> The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"

Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.

> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method

You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.

A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.

> The framework cost is always lower than rolling your own, and this isn't even the argument people are having

First, not using a framework doesn’t mean you have to roll your own (otherwise you’re still using a framework?). Second, this is the claim the parent wants you to substantiate, that not using a framework is always more expensive than using one.

> You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper.

No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)

Claiming that one approach is cheaper than another is never a fallacy. It is a statement of fact that can be wrong if disqualified with evidence or proven correct.

> If you roll your own - and you will

That's the best case. Usually it was just thousands of lines of jquery spaghetti.

Who made this jquery spaghetti? If you couldn't properly organize stateless functions, you were doing something wrong.

Where's "stateless" coming from? The underlying purpose of frameworks like React is to manage mutations to the fundamentally stateful DOM.

A car purpose is to take you from a to b, so lets put the gasoline in the cup holders.

This comment makes no sense

When these conversations come up they always degrade to two worthless arguments:

1. I tried to write vanilla JavaScript once and failed miserably so therefore humanity is completely incapable of accomplishing such

2. I cannot organize instructions to save my life so therefore the result for all developers must always be spaghetti

The unspoken third option is that the people making these claims can’t write software and need to blame something else, however irrationally, because they lack the maturity to find a way forward.

Nah, the argument is worthless because apparently HN hasn't built anything more complicated than a contact form, therefore telling claude to use HTMX is always the answer.

I'm just reflecting what I've seen in the field. Webapps evolve over time and sometimes that has meant just ladling on more kludgy javascript event handling. If there is a homegrown state manager, that's usually better than the alternative. (although the frameworks are mostly just fine)

The guy above makes this point across the thread and I'm pretty certain he has never worked in a team on a complex app.

Why would you say that? What evidence leads to this conclusion?

I suspect your point is that Angular or React must exist as the primary work product for a team to operate, but why? Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do? To me this sounds like you have absolutely no idea how to program or that you have no faith that anybody can program original solutions... except for the people who invent large frameworks.

> Why would you say that? What evidence leads to this conclusion?

Your own comments.

> Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do?

No. Not at all. I'm suggesting they're unwise if they do it voluntarily (as in: not constrained by compliance etc.).

> to me this sounds like you have absolutely no idea how to program

I'm not surprised. Surely you roll your own STD as well? Boy, I really hope you never import a function from any library. Otherwise you would be just like us, the stupid idiots who can't write original code. While we're at it, hopefully you don't build upon an operating system as well, since any reasonable dev would be rolling their own. In all seriousness: You and me both build solutions on millions of lines of other people's code. I'm really wondering why you're acting so high and mighty because you're using a couple hundred lines less.

> no faith that anybody can program original solutions

Original solutions can be created just fine with library code.

When these retorts come up they always degrade to two worthless arguments:

1. Ad hominem attacks on the original commenter

2. The arrogance and limited viewpoint that ignores the very fact that this can be observed by non-original writers of code, and that this scenario is so common that it coined an original term and spawned an entire industry of clean-uppers.

There is no ad hominem, and yes, obviously anybody who does not accept your operating restrictions is clearly arrogant.

Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.

> Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.

They clearly feel personally attacked by your statement. Almost as if there is some truth to it.

People don't respond well to "everybody doing X is an idiot without skills". Who knew?

You called people idiots and accused them of having no ability to write software. That is a personal attack.

There is a difference between something being usually a way in your experience and something always being X categorically. You are mixing most and all in an argument.

Tedious and replying to the wrong post?

IMO, the largest benefit of most JS frameworks is a great story for statee synchronization.

Imagine an e-commerce website that has a cart with some products. The site has a cart button showing the current total, a pop-up cart interface, as well as an assortment of 10 or 20 different components which let you add or remove products (E.G. the Christmas promotion page may be using a different, christmas-themed "Add to cart" button).

You need to keep all of these in sync. If you open the cart pop-up and remove the product you've just added on the Christmas promotion page, the button on that page must change color (and ARIA state / label) back to show that the product is not in the cart any more.

With traditional, imperative JS, you have ~20 places where this state is kept: The card array is the source of truth, the CSS classes, labels and aria properties of all these buttons must stay in sync with that array, but there's nothing that forces them to do so.

Sure, there are some software engineering patterns (I'm looking at event-driven design here in particular) which make this kind of bugs less likely, but they're still not really a guarantee of the code being correct by construction.

React and its ilk make it much, much harder to introduce that kind of bug, requiring you to basically go out of your way to do so.

Because AI agents love slop and "just one more edge case just to fix that one bug" thinking instead of addressing the underlying root cause of the bug class, this kind of thing is more important now than it ever was before. Agents are great only if you set them up for success, and the way to do that is to make bugs impossible to write.

When I write my large vanilla applications I keep state in only one place. It reduces complexity and increases execution speed.

So for all your pompous purist opinions, you‘re committing the evil sin of global state?

Which of my opinions are purist? I have really only said I prefer to not use giant frameworks. Why should I use a factory when a hammer is more than sufficient?

No, you‘re implying that anyone who will use one is useless as a developer

So its not about purity, but about you being sad? Why are you so invested in my personal opinion about developer capabilities?

> Why are you so invested in my personal opinion about developer capabilities?

Because I don't like people spewing vitrol on hn?

People seem to have these conspiracy theories when in reality, frameworks do exist to make developers' (in aggregate at a company and in general) lives better. I'm not gonna write DOM manipulation code from scratch when React (or Solid, or Vue, or...) handles everything for me.

In my experience the large frameworks tend to make things easier for developers by bundling things into partially isolated components. They also tend to make the code much larger and more complex. For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).

this comment is a non-programmers idea of a programmer's comment.

> For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).

I loved this tech-coded business speak gibberish. "For me, managing business operations is just a matter of aligning strategic variables with organizational synergies and making use of scalable frameworks (processes)."

It's ok to say you can't do it. I wouldn't think less of you for your honesty.

Can you write your own standard library, browser and operating system?

Let me put it this way: Chrome, the Linux Kernel and Ubuntu combined are about 600-700 million lines of code. React core has 70k (150kb). You‘re using 0.0017% less library and framework code than the rest of us.

There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application. There are also all the plugins, build tools, and all their dependencies as well.

My personal preference is to ship less code because it means less to maintain over time, less tech debt.

> There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application

Not really.

Meanwhile, LLMs have massively buffed internally developed software.

Reply on news.ycombinator.com