8 ms·

I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the di

I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/ https://www.nativescript.org/

gaius 11y ago
For me new has to be new. I learnt Tcl/Tk back in the 90s because I could rapidly develop a GUI on X11 but then started to use Tcl as a general purpose scripting language. Then I look at Ruby and Lua and Node.js and I think, what can any of these do that Tcl doesn't, just as well and usually better? E.g. all the async stuff in Node is old news in the Tcl world. Then I look at people who flock to the latest thing always and I think do I want to work in a world where every project it someone's first in an immature technology, or maintenance in a dead-end technology? That doesn't sound very satisfying to me, I want to get the foundations right and build on top of them, not build on shifting sands.
mercurial 11y ago
> On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. That's some strawman right here. First, JSX is optional. Sencondly, JSX is open. You may disagree whether it's a standard or not, but you know what? If tomorrow you end up with a large codebase where you want to get rid of JSX, you just apply a JSX transpiler on your existing codebase. Problem solved. As for separation of concerns, you have a little bit more of a case. React does allow you to put business logic in your views... just like 99% percent of templating languages out there. But React does not force you to do that. You can have only the minimum amount of logic you need, and put most of your frontend business logic in your store.
- SomeCallMeTim 11y ago
  It's not just about the JSX part. That's a piece of the larger problem: The fact that the HTML & CSS are being built up in JavaScript at all. This troubles me at a deep level, and no matter the approach you use, it won't likely be portable to another framework. Templates using a "handlebars" syntax are pretty portable with minor tweaks, in general.
  - 11y ago

gaius 11y ago

For me new has to be new. I learnt Tcl/Tk back in the 90s because I could rapidly develop a GUI on X11 but then started to use Tcl as a general purpose scripting language. Then I look at Ruby and Lua and Node.js and I think, what can any of these do that Tcl doesn't, just as well and usually better? E.g. all the async stuff in Node is old news in the Tcl world. Then I look at people who flock to the latest thing always and I think do I want to work in a world where every project it someone's first in an immature technology, or maintenance in a dead-end technology? That doesn't sound very satisfying to me, I want to get the foundations right and build on top of them, not build on shifting sands.

mercurial 11y ago

> On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. That's some strawman right here. First, JSX is optional. Sencondly, JSX is open. You may disagree whether it's a standard or not, but you know what? If tomorrow you end up with a large codebase where you want to get rid of JSX, you just apply a JSX transpiler on your existing codebase. Problem solved. As for separation of concerns, you have a little bit more of a case. React does allow you to put business logic in your views... just like 99% percent of templating languages out there. But React does not force you to do that. You can have only the minimum amount of logic you need, and put most of your frontend business logic in your store.

SomeCallMeTim 11y ago
It's not just about the JSX part. That's a piece of the larger problem: The fact that the HTML & CSS are being built up in JavaScript at all. This troubles me at a deep level, and no matter the approach you use, it won't likely be portable to another framework. Templates using a "handlebars" syntax are pretty portable with minor tweaks, in general.
- 11y ago