5 ms·

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

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/webdriver-ts-results/table.html http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...

madeofpalk 9y ago
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'.
localvoid 9y ago
>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?
- daliwali 9y ago
  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.
  - harel 9y ago
    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.
notsrg 9y ago
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.
- daliwali 9y ago
  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.
harel 9y ago
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.
- daliwali 9y ago
  >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.
  - harel 9y ago
    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.
deleted 9y ago
[deleted]

madeofpalk 9y ago

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

localvoid 9y ago

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

daliwali 9y ago
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.
- harel 9y ago
  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.

notsrg 9y ago

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.

daliwali 9y ago
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.

harel 9y ago

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.

daliwali 9y ago
>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.
- harel 9y ago
  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.

deleted 9y ago

[deleted]