101–110 of 209 posts
Earlier quoted context omitted.
Yeah I still use `React.createClass({})` because... autobinding. Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.
See my comment downthread regarding intended use of React.Component: https://news.ycombinator.com/item?id=14065106 .
I'd like to see React support shadow-dom and web components. Not holding my breath however, since Facebook considers web components to be a "competing technology". Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
Earlier quoted context omitted.
This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…
I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web developmen…
If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop it Fast, so after a while they start taking a few short-cuts, and round we go again.
I have faith that it'll settle down eventually, but until then...
Earlier quoted context omitted.
It's really time to start distributing ES6 via npm. All current browsers support ES6. It's now generally faster than equivalent ES5, it minifies better, tooling is better, etc. It's the app that should compile all the code to run in the target environment if needed. This is what we've done in the new Polymer CLI / polymer-build: we compile all dependencies but only if necessary.
All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for…
Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade.
Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.
Earlier quoted context omitted.
It's worth noting that the React team promotes composition over inheritance, and discourages any levels of inheritance past `class MyComponent extends React.Component`. Long term, the React team plans to investigate concepts like "stateful functional components", but until then, classes are the most straightforward way of having lifecycles. The existence of ES6 classes is based on the wide range of third-party "class…
> but until then, classes are the most straightforward way of having lifecycles. Huh? Why? React.createClass({}) is/was pretty straightforward. What is more straightforward about classes? All I see is more code.
There are three major differences between `createClass` and React.Component:
- Autobinding
- Mixins
- Custom class system vs one that's built into the language
Autobinding is the most useful aspect, but there's a variety of ways to deal with it: use the Class Properties syntax and write methods as arrow functions, use one of the many autobind utilities in a constructor, write your own base class that extends React.Component and do autobinding in its constructor, etc.
Mixins are now a discouraged approach for writing React code. If you still want to use mixins in React components, there's some "compat component" classes on NPM, or you could use a non-React-specific method of applying mixins.
And finally, deprecating a custom class implementation means that it's one less thing the React team has to maintain, and the lib size is that much smaller.
Earlier quoted context omitted.
This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…
I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web developmen…
Then, I don't understand the rest of the argument. Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.
Example: Operating Systems, which is the rare beast where an actual closed-source competitor still exists. Yet the Windows marketshare on the server is around 10%, and I doubt that it's the price that encourages all those Unicorns to chose Linux. Databases are a similar story.
> Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely
It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook. Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition, easily beating the laser-focused team at Mozilla.
> Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people
The influence is spread out far wider today than it was at the time where Microsoft and Flash were able write APIs without asking anybody.
But, more importantly, I'm unsure what you want? A version of React that supports IE 6 and lynx? They have that, it's called XHTML 1.0 Transitional.
Earlier quoted context omitted.
I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web developmen…
Agree. This is Maker's Triangle stuff (Good, Cheap or Fast, pick two). Everyone is picking Cheap and Fast, and not only Cheap, but Free, so the amount of Good left in this stuff is non-existent. If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop…
But how does that apply to Chrome, or React? Is there any indication that Chrome carries more technical debt than, say IE7? Similarly, in what way does Facebook need people to adopt React, and would that matter enough to accept such compromises? Is there any indication that their code quality is inferior to ?
And if this is the complaint about churn, that, at this time would be older than our js stack if it were true: React came out in 2013, it's four years old. Before that, most people probably used JQuery, which came out in 2006, i. e. 11 years ago. Is learning a new library every five years too much, considering this is one of the most dynamically evolving ecosystems of technology?
Anyone have experience with this sort of thing?
I hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCycleMethod = function() {...}; component.render = function() {...}; function privateMethod() {...} return component; }
Care to add more to this? I've been doing javascript in some form or another for 10 years. We've always been able to do something "class like", but having actual real classes in ES6 is great. What is there not to like?