My feelings exactly, it's like people in tech intentionally complicate things in order to stay relevant and irreplaceable, or maybe using complicated solutions makes them feel superior? No one cares how your app works as long as it works, I've created large web apps using a small set of libraries and guess what - they still work fine after so many years. Keep it simple, stupid.
Einstein said that everything should be as simple as possible, but no simpler. In the case of certain enterprise apps (yup, such things exist!) frameworks like Angular are often required.
"An Angular "service" is a singleton object created by a "service factory". These service factories are functions which, in turn, are created by a "service provider". "The service providers are constructor functions". When instantiated they must contain a property called $get, which holds the service factory function."
He programs his front end in React. I'm not an expert in React in any way, but let's look at some sample code:
In this code, I see what looks like a singleton object called ReactDOM, which would be an Angular service. There's a factory function "createClass" (a service factory), which is created by an object called React - which looks suspiciously like an Angular service provider.
Call me a cynic, but this rant looks like an uninformed screed, written by someone who thinks that creation patterns are only creation patterns if they are called factories, singleton factories and factory-functions (or constructor functions).
If he can't identify patterns in use in his favourite tool that are precisely the same as the ones he criticises, then I'm not sure he's as good a coder as he thinks he is. Even if he enjoys writing in Erlang.
I think the code you posted is much simpler, both conceptually and at the level of the code itself. We know what classes are, we know what render means.
I think the requirement to express markup as a tree of function calls is inelegant (JSX is no different, just shorthand for this) and my least favorite part of React, but I'll take inelegant over WTF any day.
I'm not an Angular expert, and this isn't quite the same, but seems to show the same basic principles at play:
var helloWorldApp = angular.module('helloWorldApp', []);
HelloWorldApp.controller('HelloWorldController', function ($scope) {
$scope.displayName = "HelloMessage"
});
I believe you just add a directive to add a new element. Slightly more code, but the same concepts in play. React uses an MVC framework, only it doesn't use those exact words.
Seems pretty much the same to me!
Note that React may well be easier to understand, but its not because it doesn't use a singleton object to access an object factory created by a provider of factories (a factory that creates factories).
To me this is mostly just a rant about why Angular is terrible. And I agree, it's absolutely terrible. Frustratingly overwrought (I dare you to output a URL in a template, go on, I dare you) and built on top of some unfortunate ideas like dirty-checking and all this service factory madness.
Fortunately, it's far from being dominant in front-end dev.
I wish we would stop beating around the bush and just add templating to HTML already; not as the current ‛template‛ element proposal, which still looks like DOM manipulation, but actual "expressions inside template attributes and content + data context set in code" like every templating library is doing. And don't forget conditionals and repeaters while you're at it.
Indeed. The JS community flirted with the idea of a monolithic do-everything framework for a bit longer than I expected, but thank god the madness has passed.
21 comments
[ 5.7 ms ] story [ 53.7 ms ] thread"An Angular "service" is a singleton object created by a "service factory". These service factories are functions which, in turn, are created by a "service provider". "The service providers are constructor functions". When instantiated they must contain a property called $get, which holds the service factory function."
He programs his front end in React. I'm not an expert in React in any way, but let's look at some sample code:
In this code, I see what looks like a singleton object called ReactDOM, which would be an Angular service. There's a factory function "createClass" (a service factory), which is created by an object called React - which looks suspiciously like an Angular service provider.Call me a cynic, but this rant looks like an uninformed screed, written by someone who thinks that creation patterns are only creation patterns if they are called factories, singleton factories and factory-functions (or constructor functions).
If he can't identify patterns in use in his favourite tool that are precisely the same as the ones he criticises, then I'm not sure he's as good a coder as he thinks he is. Even if he enjoys writing in Erlang.
I think the requirement to express markup as a tree of function calls is inelegant (JSX is no different, just shorthand for this) and my least favorite part of React, but I'll take inelegant over WTF any day.
https://github.com/kay-is/react-from-zero/blob/master/0-obje...
Seems pretty much the same to me!
Note that React may well be easier to understand, but its not because it doesn't use a singleton object to access an object factory created by a provider of factories (a factory that creates factories).
Fortunately, it's far from being dominant in front-end dev.
Edit: I think you meant ractivejs.org