Hacker News Reader

Comment by daliwali | Hacker News Reader

You literally said, "complexity is not my problem". You are the problem.

This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist.

Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks.

[0] http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...

View on HN

I disagree with you here. The complexity of my app is my problem. The complexity of how to render some stuff into the screen is not. I don't have the time to deal with both. As far as bloated node_modules - I agree and I will always opt for my own version instead of some trivial npm that has one function in it. But some things I don't have time to deal with. I've done work with All-In Javascript frameworks where you have to submit to the framework, and work within it fully. React essentially eliminated this for me. I don't need a framework beyond React as a view library and perhaps redux to manage state. I can then pick and choose what to bring in as 3rd party because it saves me time and what to implement myself. I've also done a good deal of Vanilla JS which has its place for smaller projects. And more often than not, those smaller projects grow beyond "Vanilla".

Doing my own thing is of course possible and in many cases is fast to get something up. But doing it correct and proper takes a lot of time and attention. When I'm trying to get a project going - time is not on my side, but I still want it done correct and proper. If someone comes in and does a complex part of my app correctly, I'd use it. Its NOT a problem.

Edit: By the way, taking a snippet of a line from what I said and quoting it without its context does not make for good discussion.

>The complexity of how to render some stuff into the screen is not [my problem].

But it is. You are depending on some complex third party code to do your job, how you want to punt responsibility to someone else is irrelevant. Web developers aren't owning up to the sorry state of front-end web development, because everyone says "it's not my problem", ask Facebook/Google/whatever.

Correct and proper have little meaning if at all in web development, they're usually dictated by the biggest companies and most popular bloggers. Moreover, these definitions are constantly in flux (no pun intended). Nobody cares if your web app correctly follows the proper conventions of your framework. Front-end web developers seem to focus more on navel-gazing about the "developer experience" than results.

But you're missing a context here. My context. I run two companies and contract on top. I also have a life. If any Big Company (tm) wants to give me a good solid presentation layer blackbox I'll take it and say thank you. I could develop my own presentation layer/frameword du jour/library/toolkit/whatever. But WHY would I do that when its already done. And those who did it do it full time as their day job, paid by said Big Company (tm). So i'll ride that train and use their blackbox and focus my energies where they are needed - in domain specific business logic that actually generates revenue.

I'm having fun doing it but i'm not doing it for fun.

> You are depending on some complex third party code to do your job

Yes. It's called a web browser.

The additional complexity of react is a drop in the bucket compared to the complexity of the undertlying platform.

Haha so true. I keep forgetting that... I take browsers for granted sometimes.

Minimalist, modern web browsers exist. A good example of this is surf [0], which is based on WebKit and is <50kb of C. That's less than half the size of React source. It obviously doesn't have all the features that Firefox or Chrome might have, but demonstrates that browsers don't have to be bloated.

[0] http://surf.suckless.org/

I would rather the complexity live in a third party library with an extremely simple public interface than have it live in multiple 1000 LOC of vanilla JavaScript that's laid out however whoever wrote it felt that day. You couldn't pay me to do frontend without React - the developer experience is absolutely terrible.

It is a dogma that React has an "extremely simple" public interface. It's got two different flavors of "components", "lifecycle hooks", "synthetic events", "prop types", and more that I'm missing.

Why do you assume that vanilla JS code is terrible? Is it because the average developer can not be trusted to write competent code without the conventions of a framework? If one cannot write competent code without being completely dependent on frameworks, I wouldn't trust them to write code at all.

>They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks.

I won't be able to write efficient vanilla code for something even slightly more complicated than this benchmark, and I wrote one of the fastest virtual dom implementations out there, so what you expect from an average web developer?

I'm not saying, "don't use an abstraction on top of vanilla DOM code".

Better performance just isn't a valid reason to use a DOM abstraction, it's a non-argument.

Performance was never the only reason. In fact its the last reason on the list. Development speed and efficiency and the modularity of it all is what sold me on React.

That post doesn't benchmark how a team of developer worth together, or how you manage all your code.

The speed of a for-loop is only a part of what makes a codebase 'fast'.

Reply on news.ycombinator.com