Hacker News Reader

Comment by quantadev | Hacker News Reader

The people who don't think React (or Vue) is important are the same ones who have never worked on a large project with lots of screen updates and state changes that absolutely cannot be avoided. React is still #1 in popularity, and the most crucial tool for almost any web developer (aside from using TypeScript, instead of plain JS which is also critical for large projects)

React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.

View on HN

> React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.

The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.

> I've built plenty of interactive apps with JavaScript without using frameworks

And once you reach sufficient project complexity, you will end up with just another homegrown framework, with all the lessons learned by mature frameworks, left to be fixed over the next 5 years.

Oh yeah? And when will that happen? Because people have been throwing this argument at me since at least 2014. I still haven't slipped on a banana peel and accidentally fallen on a homegrown framework. You don't just create a framework by accident.

I don't have any context, but I do have trouble imagining that any of your projects have scale/complexity above brochure-ware if you haven't run into this.

If you have trouble imagining, here's one such project: https://github.com/baobabKoodaa/ouija

Even if you know of massive projects in JS, the problem isn't that they cannot exist, it's that maintaining them takes 100x the manpower it would in TypeScript.

Jesus Christ, a 1300 line single file codebase.

Not a single file codebase

> Not a single file codebase.

Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.

And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.

> App.js is all the code there is

No, it's not. Chatbot.js is 3400 LOC.

There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?

Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.

> tiny toy project

Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.

the expletive is unnecesary.

Point taken. Edited.

Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety, but EVEN the small projects DO benefit from catching errors at build time. It's just a self-foot-shoot to find bugs at runtime instead of build time.

The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As if unnecessary complexity was some kind of inherent good.

I never saw anyone on this thread deny that JS CAN be used without frameworks. As a developer since before the internet even existed I've written probably at least two to four million lines of JS in my life, so I'm well aware.

What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a framework. I have a couple of those currently myself, because I don't need a framework for them. They're just HTML+CSS+JS.

> I never saw anyone on this thread deny that JS CAN be used without frameworks [...]

https://news.ycombinator.com/item?id=42282054

"brochure-ware"

B-R-O-C-H-U-R-E-W-A-R-E

He's right. You have a project with two source files in it. That's basically not at any kind of scale he was talking about, and is easily classified as brochure-ware, from an architectural standpoint, simply because there's no architecture to it at all. Just a monolithic file.

> Just a monolithic file.

I was willing to assume good intentions from you earlier, but at this point it's clear you're just lying. You've seen the number of files in the repository, we already had a back and forth and you already conceded there was more than one file. And yet here you are, reiterating the same lie. Weird stuff.

Those two 17 LOC files don't count. That leaves precisely two source files, just like I said. It's well under the threshold where I'd consider a framework mandatory.

> And your app is tiny. It's got like two source files.

If the same app had been written by a typical team of React devs, it would be >1000 source files and 50K LoC. That's not an argument against my approach, it's an argument in favor of it.

The SPA version would unmanageable without the latest 4th generation JS build tools. Spend an afternoon reading the manual for the configs. Watch the output of 'pnpm list' break your terminal environment when you try piping it through 'less'.

You can use React with or without SPAs. Not saying you didn't know that. Just pointing out they're separable.

You have it exactly backwards. Since React does all the DOM updates automatically, my massive project, with 100s of thousands of TypeScript LOC, has zero DOM calls in it. lol.

Sorry:

a codebase with a 1300 line file.

I have a lot of "framework free" single-developer projects as well (such as https://bongo.to ), but that isn't really what I think we are talking about here. Single developer projects can do whatever they want, it isn't a problem. The problem comes when you have to work with distributed teams, juniors, etc. One way or another a large team still has to come to agreements about how to do things, and without an external reference it will have to be made up in an ad-hoc manner instead. This often leads to issues, many of us have noticed.

I absoluetly agree with your sentiment, and furthermore in projects as large and mature as mine, with 500K LOC (about maybe 30% in TypeScript) lots of times I simply cannot remember enough about my code to effectively refactor it from memory without type safety (to check me) and IDE refactoring to DO the refactoring.

I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.

The goalposts just keep moving...

The claim upthread was that you couldn't make a web app at all without a framework ("or it would just be a document"). I said yes you can and the goalposts shifted to: sure, but only "brochure-ware" (referring to simple unambitious projects). I show an ambitious interactive project made without a framework and now the goalposts are moving to: sure, but large distributed teams couldn't work like this? You know, this solo project is more ambitious than 99% of the projects I work on at my actual work. You know, projects that have 10, 40, or 100 devs working on it.

For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.

Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if they have a high IQ and decades of experience.

I don't share your opinion but I'm too tired to go into another JS vs TS debate

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.

"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"

I literally said the exact opposite. I don't care what language you use as long as it's type-safe.

Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.

First it was "10+ years experience", which would qualify me, but now you shifted the goalposts again to "decades" experience. Lol. I guess you can keep pretending that everybody who matters agrees with you when you just count everybody who disagrees as someone who doesn't matter

I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter.

But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.

I'm a seasoned developer. Your opinion is just your opinion, not a fact.

Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.

Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.

If Python was just fine without type-safety that's how everyone would have kept it.

> Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.

This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, because Python is not a type-safe language even for those developers who are using "every type-safety feature available to them". You claimed earlier that "Any language that lacks type-safety is completely inappropriate for large-scale projects" even though you seem to be aware of the fact that "seasoned developers" are using Python for "large-scale projects". So, again, you're just lying.

Every highly experienced developer knows the importance of type-safety. The existence of large numbers of experienced Python developers in the world doesn't disprove that, because it's a statement about their knowledge, not their actions.

Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being made.

This is what you said earlier:

> For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.

Clearly, more than 1% of experienced developers choose Python, despite it not being a type-safe language.

Yep, great developers know they "need" type-safety, but we don't always have it. Even my own app has a Python Microservice in the docker stack where 100% of my LLM/AI code is contained, simply because I wanted all the latest and greatest AI tooling (especially LangChain). I opted for Python over Java for that microservice, but used various tools to achieve build-time type-safety.

> And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.

You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?

Oh, and it just so happens that Python was the most popular language in the 2024 StackOverflow survey: https://survey.stackoverflow.co/2024/technology#2-programmin...

I guess literally none of those people were "seasoned developers" either, and none of them had ever worked in a "scaled" and "large" project, like you mr big man.

Sorry, I'm just not buying any of that.

Also, we're talking about the web here. How many type-safe supersets of JavaScript are there? When you say "I don't care what language you use as long as it's type-safe", you're pretending as if there's more viable options than just TypeScript.

There is a choice on the server side too, to go with type-safe languages or non-type-safe ones. When I'm stating something as true and general as the importance of type-safety I speak as broadly as possible, because I'm indeed NOT talking about just TS when I say "type safety", I mean it everywhere computer code exists. All untyped languages are garbage.

Awfully funny considering our major security issues in code these days are from a type safe language.

Yeah because any systems or OS programming is done in type-safe languages. lol. And BTW correlation is not causation.

That was kind of my point. You speak to type safety and all the issues not having is that would be prevented but memory safety is yet another one and is a huge issue with common platforms TODAY. So, obviously your pet issue isn’t the only one out there and there are trade offs made.

Here's how your "point" landed, according to everyone but you:

Me: "Seat belts are important."

You: "Awfully funny considering our major car accidents these days are mostly all ones with seat belts."

You're implying a nonsensical causation that's purely a correlation.

My point was how our most serious issues are with memory management that exists in popular type-strict languages and so type safety is not up there in importance compared to the biggest causes.

That's exactly backwards. Without the type-safety in those memory-unsafe languages (like C++) there would be 100x more buffer overruns and other memory issues and security holes. Having the type-safety in place is literally the main thing that makes memory-unsafe languages viable.

Generalizing much? React is as popular as it is because of inertia.

React holds an important space but its hardly the only tool that can succeed in a "large project with lots of screen updates and state changes". That's ridiculous.

The reason I said "(or Vue)" was specifically to say that there are other leading frameworks. I didn't say "or Angluar" because in my opinion it's a race between React and Vue at this point. But if you think there's a third contender, let me know. I'm always looking to learn.

My main point was to compare "frameworks" v.s. "no frameworks", rather than to say that React is best, but if you want my opinion then yes I do say React is indeed the best, and I admit it's an opinion not a fact. lol.

Angluar -> I'm using this from now on

In case I was unclear, I consider Angular dead and obsolete.

Same, anGLuar sounds, for a french speaker, like https://en.wiktionary.org/wiki/engluer

1. to birdlime

2. (reflexive) to get bogged down

In case I was unclear, I consider French dead and obsolete.

> In case I was unclear, I consider Angular dead and obsolete.

maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).

Maybe Angular is still used a lot, in legacy projects. I just mean for starting a new project, imo most people will choose React or Vue in 2024, right? I never used Angular myself, but have used both React and Vue a lot.

I don't have strong insights about current agnular popularity. I think at least teams/companies which built strong expertise in angular will continue using it for new projects unless there is some big reason not to.

SO trends show that angular is more popular, while vue is loosing share (not necessary absolute number): https://trends.stackoverflow.co/?tags=angular,vue.js,reactjs

Thanks for sharing that graph. It does show React as the leader, the the others in distant 2nd/3rd place.

However I think the "drop off" in the chart for React is misleading/incorrect, and likely indicates just a slowing down of the economy and/or people moving to LLMs for their searches and abandoning StackOverflow completely, as I have.

For the past year I haven't yet found a question that an LLM couldn't answer better than S.O. could, although ironically most of the LLM learning did come from S.O.

Anyway, yeah shops will stick to their legacy code forever unless something forces change, because retooling is super expensive in money and time, not to mention replacing all your developers with different ones!

If you’ve never used it don’t declare it dead. Angular is updated regularly every 6 months. While react is busy thinking how to create more SSR apis, the angular team keeps improving developer experience.

IMO right now it’s easier to start an angular project with much less foot guns than react.

I call plenty of things dead without ever having used them. FORTRAN for example.

What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.

BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.

I’ve never used a drill press; does that make them dead?

Fortran certainly has its issues with portability and feature development, but it is by no means dead.

As I already pointed out, my use of "dead" doesn't mean "no longer in use". It means no longer being selected by choice for a new project.

And your drill press example is agreeing with me, which is that, as I also already said myself, no one needs to have ever used something to be able to declare it dead, nor did I declare something dead because I don't personally use it. That's absurd.

Have you ever worked on a project that used Rails, Laravel, Django or Spring? Without being a SPA? For many (most) websites, I find that these are far superior to client side heavy SPAs with json apis (react, vue etc).

Most of the apps I've worked on were very business oriented, and about people getting work done, rather than "website" type stuff that's mostly static. So for example, being able to refresh a part of the screen with new information from the server, is critical. Doing page reloads would destroy the experience. I have 35yrs exp so yes I've used most of what you mentioned.

You’re just proving the point. This stuff was easy when it was called Ajax. You don’t need React for that simple thing lmao.

I just use the 'fetch' command to get data from the server. That's basically like Ajax. Where React comes into play of course is taking care of all the page updates, which would be a nightmare for any large app, unless you have a framework being used.

WordPress relies on server-generated HTML and its admin interface is a fairly complex "app", especially once you factor in the plugin ecosystem. According to [1], it's used on 43.7% of all public websites.

[1] https://w3techs.com/technologies/details/cm-wordpress

If every user input causes a page refresh, that's not an "app" that's a "website". If you don't have any executable code (i.e. Javascript), but just form submits, yeah I agree that's what most of the web is, and as you pointed out most of the web is websites not web apps.

Have you explored cross-document view transitions? Would you classify something that uses those as an app or a site?

https://developer.chrome.com/docs/web-platform/view-transiti...

That's actually rather new so we shall see how frontend practice reacts. I've only seen a few instances of it out in the wild so far.

I'm not saying my own definition of "app" is the only correct definition, but in my opinion only if I do a click and something on the SAME page changes, then it's an app. Transitioning to different pages isn't an app, imo.

With this browser feature a navigation to a new page can look like only part of the page changes - without needing any JavaScript.

> can look like

Yeah, but it ain't. lol.

It's easy for developers to forget who the "app" is actually for.

Users don't care how it was implemented or how nice the code looks, they just want it to work.

Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.

The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.

By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?

I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.

SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.

Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.

> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed

In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.

It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.

I know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.

I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.

Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.

It’s been a while since I worked with WordPress, but isn’t their Gutenberg editor (which is the heart of their CMS) built on React? So while React may not be used on the user facing side, it is still powering the content side of WordPress and in a way, powering all of those sites.

Ha and jquery was pretty high too. How is that an argument?

I'll happily ditch React once something better emerges. I've been doing web development since 1998, so I'm used to change.

You can't be more wrong. You're saying that only logic performed on the client side can be considered an application? State can be stored in the server. Screen changes can be done by loading html, it doesn't need a framework. React is far from crucial for web development, but people haven't learned anything else the last decade. Most front end developers these days don't even know what a template engine is, and some don't even know how to create a website without a backend rest api that spews json data.

I wasn't comparing SSR to non-SSR (Server Side Rendering). As long as you can refresh portions of a webpage (or states of GUI elements), after a user action (button click or whatever), that's fine.

However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.

Popularity is not an argument for merit. Diabetes and heart disease are popular. Taylor Swift is popular. It doesn't follow that I should desire these things.

If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.

https://en.wikipedia.org/wiki/Argumentum_ad_populum

Popular is not a synonym for "common", like you're implying it is. They're different things. Popular means desired.

The more popular a piece of software is, the more likely it is to have had the bugs worked out of it, the more people there are reporting issues, the more answers there are on StackOverflow, the more likely AI/LLMs are to be able to answer questions, the more secure it's likely to be, the more stuff interoperates with it, etc. Popularity alone isn't a good reason to select something, but it's a good data point, with which so judge viability.

Reply on news.ycombinator.com