3 ms·

No, because "plain JS" isn't a UI framework. We're moving closer to having real GUIs in the browser (e.g., Java Swing) but that's not a function of the languag

No, because "plain JS" isn't a UI framework. We're moving closer to having real GUIs in the browser (e.g., Java Swing) but that's not a function of the language, but the plumbing around the language. Swing isn't Java, Swing is written in Java.

chatmasta 10y ago
If you use createElement, appendChild, and innerHTML, you can replicate a lot of the functionality of react. In fact react probably uses a lot of that under the hood. Of course for more complex applications, react is cleaner. But for relatively simple components, manually manipulating the DOM like this might be worth skipping the overhead of react.
- davelnewton 10y ago
  Yep, agree entirely, although I wouldn't advocate mixing the two in a single application--mixing mechanisms is added cognitive overhead. But again, JS is just a language, that happens to have an interface into a DOM (in some environments). It's not a framework that guides you in how to organize and architect an app. It's possible to write maintainable, high-performance, complex apps using plain JS. Adding a few simple layers makes it a lot easier, though, and I'd argue that the current crop of client-side frameworks make it easier still. Simple apps == simple code. Complex apps == complex code, regardless of the tools used to create it. Underneath everything, after all, is still just plain JS.
  - chatmasta 10y ago
    Well then to return to your original point that redux/webpage/flux/blahblah are overkill and you shouldn't use them until you need them, you can make the same argument. They are more layers that guide you in "how to organize and architect an app." The tradeoff is that you get simpler code in exchange for more architectural overhead and a more complex build process.
    - davelnewton 10y ago
      I never said they were overkill (and I'd argue Redux or similar pattern is useful even for fairly simple apps). For an app of any reasonable complexity you'll have "architectural overhead" whether or not you're using your architecture or someone else's. That's just a given. (And if you don't, you have more overhead trying to figure out what you were doing.) More complex build process? Yep, if you're not writing all the code yourself, and you want to distribute a single file, and ES2015 (or other) transpilation, and minification, sure. But you can use all the libraries in question without much of a build process at all, just load 'em all up and use ES5. Complex build processes are a result of wanting to distribute and write code in a certain way. They're not a requirement.

chatmasta 10y ago

If you use createElement, appendChild, and innerHTML, you can replicate a lot of the functionality of react. In fact react probably uses a lot of that under the hood. Of course for more complex applications, react is cleaner. But for relatively simple components, manually manipulating the DOM like this might be worth skipping the overhead of react.

davelnewton 10y ago
Yep, agree entirely, although I wouldn't advocate mixing the two in a single application--mixing mechanisms is added cognitive overhead. But again, JS is just a language, that happens to have an interface into a DOM (in some environments). It's not a framework that guides you in how to organize and architect an app. It's possible to write maintainable, high-performance, complex apps using plain JS. Adding a few simple layers makes it a lot easier, though, and I'd argue that the current crop of client-side frameworks make it easier still. Simple apps == simple code. Complex apps == complex code, regardless of the tools used to create it. Underneath everything, after all, is still just plain JS.
- chatmasta 10y ago
  Well then to return to your original point that redux/webpage/flux/blahblah are overkill and you shouldn't use them until you need them, you can make the same argument. They are more layers that guide you in "how to organize and architect an app." The tradeoff is that you get simpler code in exchange for more architectural overhead and a more complex build process.
  - davelnewton 10y ago
    I never said they were overkill (and I'd argue Redux or similar pattern is useful even for fairly simple apps). For an app of any reasonable complexity you'll have "architectural overhead" whether or not you're using your architecture or someone else's. That's just a given. (And if you don't, you have more overhead trying to figure out what you were doing.) More complex build process? Yep, if you're not writing all the code yourself, and you want to distribute a single file, and ES2015 (or other) transpilation, and minification, sure. But you can use all the libraries in question without much of a build process at all, just load 'em all up and use ES5. Complex build processes are a result of wanting to distribute and write code in a certain way. They're not a requirement.