Hacker News Reader

Comment by baobabKoodaa | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com