I am so confused; I have such trouble relating with people sometimes. I've re-read what I said a dozen times, and I can't see the problem. Though if I weren't posting anonymously the self-doubt and resulting guilt would be sufficient to shut me up for at least six months. That's why I have this account: destructive anxiety. (Though, also, yes, that's how I talk to people in real life. And yet most people, including my coworkers, like me; I can only assume because a different and authentic tone is heard than has been apparently read here.)
Sure, I could pretend that I was born just this moment and so I approach all of this with neutral, fresh-faced, joyful innocence. But that's bullshit. Instead I have a dozen years of history of seeing libraries and frameworks come and go. And four years of hearing things like what Dan said repeated uncritically by the React core team and people who appear to take their word on it like they have some biases being confirmed by it all.
Nothing I've ever said about it has made even the slightest dent in that, no matter how I said it. That's why it's ironic to have my input invited on how to fix that dialogue. I only "patronized" by assuming Dan has a subjective point of view. Which is true for literally everyone. Let's look at a contrast. Dan leveled an accusation of FUD (which means deliberate evoking of fear, uncertainty, and doubt for the purposes of propaganda) and no one chided him. I leveled an accusation of naval-gazing--and how dare I! Nothing I say has any value whatsoever!
Huh? Naval-gazing is like bike shedding; it's just a common trap for people in our industry. Is all of this because I started the comment with, "Dan, of course"? That means I agree so completely with the following statement that I don't think it's even a question! Not that I think he's stupid.
I really, really don't want to be a jerk, but at the same time... If that's all it takes, I cannot understand your perspective, since hardly a week passes when someone doesn't tell me I'm categorically unfit to be in the industry and should leave it to the real engineers. When's the last time someone told you that they hope you lose your livelihood because you don't want web client implementations to exclude a wider audience by requiring a lot of specialized programming knowledge and time spared to keeping up with the pace of the JS ecosystem? I'm not saying that excuses treating anyone else like crap, but...I can't see that I am...?
Now to what I think merits objection.
"Web components are imperative." Not to users. Not to product managers, not to designers, not to blog authors, and not to application developers consuming them. React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?
Well, because React is very focused on developer experience. Is the developer experience great? Unsurprisingly, that's subjective, but I think it's accurate to say, "React's developer experience has a great deal to recommend it to a significant audience." But it's an issue if the only votes that are counted to justify that assessment come from a privileged subset of people who work on web client development.
In response to my brief comment about that, Dan pointed at auxiliary tools that double down on framework lock-in. To me, that misses the point. We already have a standardized declarative language to create elements and set properties in the DOM. It's called HTML. Putting up a website with a specification doesn't make something a standard the way I mean a standard, by the way. The majority of web client standards represent an an agreement made between multiple competing interests and vetted by performance and accessibility specialists. "I did a thing with my own interests in mind without giving any competitors an opportunity to make significant changes or veto," isn't even remotely close.
Why do non-engineers need a separate tool that's in its infancy? In part, because you excluded them from the ground up. The only way to fix it is to create something else with them in mind. It'd still be worthwhile to build FramerX, because we really haven't seen great holistic web design and web client development tools thus far. So there are numerous things I think are great about FramerX, but bolt-on inclusion is not one of them.
There is more, but after getting this far... I fear to put any energy into writing it if I'm so blinded by my own small world that I might be doing nothing except giving readers a bad impression of people who care about the same things I do.
Hey, I'm sorry if my reply frustrated you. I'll try to clarify a few things. I don't mean to create any FUD. I think my position is very concrete. (And it's definitely not something about "real engineers" — I'd like React to be welcome to everybody.)
React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?
Of course under the hood it's all imperative. The question is only about how you write the majority of your application code and how components are expressed. I already linked to this talk in my first comment but I'd be happy to link again: reactjs.org/blog/2018/03/01/sneak-...
In this talk I show a few things that I believe are very valuable from both developer and end user perspective. Features like these are not possible if your "glue code" between components is imperative. If you watch the talk I think you'll realize what I'm talking about. I'm sorry that I don't have a shorter and more condensed version of my argument than a conference talk. But I hope that if you find the time to watch it, you'll see that I'm talking about specific things and not vague FUD about imperative/declarative.
If React is not solving your problems that's cool too. No need to assume ill intent.
React meets some of my needs, but not others. So I use it for some use cases, and not for others.
Again, don't get half of this response. The frustrating part is getting replies that seem to be aimed at something entirely different from what I posted.
Like, is this some form of communal trolling, or am I just that bad at expressing myself?
Your first post would have definitely been an odd opener in person. It's like talking shit before shaking hands. Not going to go over well.
A non negligible percentage of standards become standards after a company builds something and demonstrates it's worth, at which point standards bodies go through the process you described. See SPDY / QUIC. Its much easier to define and iterate on something after someone else has demonstrated success.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, there's nothing helpful or serious in "Junk" remarks.
I am so confused; I have such trouble relating with people sometimes. I've re-read what I said a dozen times, and I can't see the problem. Though if I weren't posting anonymously the self-doubt and resulting guilt would be sufficient to shut me up for at least six months. That's why I have this account: destructive anxiety. (Though, also, yes, that's how I talk to people in real life. And yet most people, including my coworkers, like me; I can only assume because a different and authentic tone is heard than has been apparently read here.)
Sure, I could pretend that I was born just this moment and so I approach all of this with neutral, fresh-faced, joyful innocence. But that's bullshit. Instead I have a dozen years of history of seeing libraries and frameworks come and go. And four years of hearing things like what Dan said repeated uncritically by the React core team and people who appear to take their word on it like they have some biases being confirmed by it all.
Nothing I've ever said about it has made even the slightest dent in that, no matter how I said it. That's why it's ironic to have my input invited on how to fix that dialogue. I only "patronized" by assuming Dan has a subjective point of view. Which is true for literally everyone. Let's look at a contrast. Dan leveled an accusation of FUD (which means deliberate evoking of fear, uncertainty, and doubt for the purposes of propaganda) and no one chided him. I leveled an accusation of naval-gazing--and how dare I! Nothing I say has any value whatsoever!
Huh? Naval-gazing is like bike shedding; it's just a common trap for people in our industry. Is all of this because I started the comment with, "Dan, of course"? That means I agree so completely with the following statement that I don't think it's even a question! Not that I think he's stupid.
I really, really don't want to be a jerk, but at the same time... If that's all it takes, I cannot understand your perspective, since hardly a week passes when someone doesn't tell me I'm categorically unfit to be in the industry and should leave it to the real engineers. When's the last time someone told you that they hope you lose your livelihood because you don't want web client implementations to exclude a wider audience by requiring a lot of specialized programming knowledge and time spared to keeping up with the pace of the JS ecosystem? I'm not saying that excuses treating anyone else like crap, but...I can't see that I am...?
Now to what I think merits objection.
"Web components are imperative." Not to users. Not to product managers, not to designers, not to blog authors, and not to application developers consuming them. React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?
Well, because React is very focused on developer experience. Is the developer experience great? Unsurprisingly, that's subjective, but I think it's accurate to say, "React's developer experience has a great deal to recommend it to a significant audience." But it's an issue if the only votes that are counted to justify that assessment come from a privileged subset of people who work on web client development.
In response to my brief comment about that, Dan pointed at auxiliary tools that double down on framework lock-in. To me, that misses the point. We already have a standardized declarative language to create elements and set properties in the DOM. It's called HTML. Putting up a website with a specification doesn't make something a standard the way I mean a standard, by the way. The majority of web client standards represent an an agreement made between multiple competing interests and vetted by performance and accessibility specialists. "I did a thing with my own interests in mind without giving any competitors an opportunity to make significant changes or veto," isn't even remotely close.
Why do non-engineers need a separate tool that's in its infancy? In part, because you excluded them from the ground up. The only way to fix it is to create something else with them in mind. It'd still be worthwhile to build FramerX, because we really haven't seen great holistic web design and web client development tools thus far. So there are numerous things I think are great about FramerX, but bolt-on inclusion is not one of them.
There is more, but after getting this far... I fear to put any energy into writing it if I'm so blinded by my own small world that I might be doing nothing except giving readers a bad impression of people who care about the same things I do.
Hey, I'm sorry if my reply frustrated you. I'll try to clarify a few things. I don't mean to create any FUD. I think my position is very concrete. (And it's definitely not something about "real engineers" — I'd like React to be welcome to everybody.)
Of course under the hood it's all imperative. The question is only about how you write the majority of your application code and how components are expressed. I already linked to this talk in my first comment but I'd be happy to link again: reactjs.org/blog/2018/03/01/sneak-...
In this talk I show a few things that I believe are very valuable from both developer and end user perspective. Features like these are not possible if your "glue code" between components is imperative. If you watch the talk I think you'll realize what I'm talking about. I'm sorry that I don't have a shorter and more condensed version of my argument than a conference talk. But I hope that if you find the time to watch it, you'll see that I'm talking about specific things and not vague FUD about imperative/declarative.
If React is not solving your problems that's cool too. No need to assume ill intent.
I admire your patience.
Who is assuming ill intent and about what?
React meets some of my needs, but not others. So I use it for some use cases, and not for others.
Again, don't get half of this response. The frustrating part is getting replies that seem to be aimed at something entirely different from what I posted.
Like, is this some form of communal trolling, or am I just that bad at expressing myself?
Your first post would have definitely been an odd opener in person. It's like talking shit before shaking hands. Not going to go over well.
A non negligible percentage of standards become standards after a company builds something and demonstrates it's worth, at which point standards bodies go through the process you described. See SPDY / QUIC. Its much easier to define and iterate on something after someone else has demonstrated success.