Why do React and other js libraries emit warnings as console.error when browsers support console.warn?
React v15.5.0
51–60 of 209 posts
Re: React v15.5.0
#52For those who are interested in some of the details of the work that's going on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is excellent [0]. There's a number of other existing writeups and resources on how Fiber works [1] as well. The roadmap for 15.5 and 16.0 migration is at [2], and the follow-up issue discussing the plan for the "addons" packages is at [3]. I'll also toss out my usual…
I was in awe the entire time Lin was speaking. Not a single "um" or other verbal tic; she's an incredible speaker and was admirably lucid throughout that entire talk. That's so difficult to do. And style aside, she made understanding Fiber incredibly simple. Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.
I dunno if verbal tics are necessarily the metric to use for great presentations. I know some folks who stumble constantly but present ideas that are pretty incredible. Some people just have amazing recall and can fluidly spew out facts and conclusions. Some people can present compelling ideas they have thought of that no one else but struggle on the vocalization.
Re: React v15.5.0
#53This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…
you know...if it can be transpiled by babel that means you could write it in es5 compatible syntax...yourself...so if you don't want to use the babel tool chain...what's stopping you? Don't know es5? IMO it's not too fun compared to es6...but...
Sorry hn downvote police, but it is a true statement, even if you don't approve of the tone.
Re: React v15.5.0
#54I 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?
Re: React v15.5.0
#55This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…
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 everyone to have updated their browser within the last five minutes so all the new toys are available universally, but that has never been the nature of web development. Deliberately breaking major infrastructure is just going to make JS development even more screwed up than it already is.
Re: React v15.5.0
#56I 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?
I think this is just a trope that JS devs and newbies have launched on to, and that it's without merit.
Classes are good. Classes express concrete taxonomies of concrete things in ways that most developers can understand.
I think we should be happy that JS is flexible enough that adding "class" to the language is almost purely syntactical: it clarifies and makes semantic a bunch of otherwise boilerplate "Foo.prototype.blah" code that you see in so many non-trivial JS apps.
Classes simplify things IMO.
Re: React v15.5.0
#57For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react
Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.
It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.
Re: React v15.5.0
#58I 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; }
This is the RevealingModulePattern that Crockford used to advocate back in the day, except assigning to an object that React creates instead of one you create.. http://javascript.crockford.com/private.html https://addyosmani.com/resources/essentialjsdesignpatterns/b... Be aware that memory usage can quickly balloon with this pattern, because the GC needs to keep alive anything referenced from inside the closure, incl…
Sorry, I was getting down voted a lot. I restored the code.
I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-obje...
It does eat up more memory, but as Crockford says, memory is cheap. It's not likely that it'll cause a problem.
Re: React v15.5.0
#59Earlier 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…
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 with older browsers actually deploying real sites that have normal representative user audiences? Or is this an insular group of developers mostly making things for each other?
Re: React v15.5.0
#60Happy to see propTypes getting shelved. Too many people stubbornly use propTypes even in Typescript projects. Hopefully this change will usher in the final stamping out of that.