141–150 of 209 posts
I cannot keep up. I just started learning react/apollo/graphql and I'm already out of date.
Two APIs moved from one package to another. That's all. I understand it can be frustrating but there is no big change to learn here.
Your code will still work in 15, and we print warnings telling exactly what to do to prepare for 16. And we provide tools to automate this change for your existing code.
Fiber is what I'm really waiting for. Not much official chatter about it, but looks like a 16 release? They just removed some addons in master that many third party packages rely on, including material-ui. Hopefully these other popular packages can be ready to go with the changes when the fiber release hits.
npm install react@next react-dom@next --save
Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }
"extends" is often a bad idea. https://en.wikipedia.org/wiki/Composition_over_inheritance It's sad to see how new generation can't learn lessons of the past.
https://facebook.github.io/react/docs/composition-vs-inherit...
>So What About Inheritance?
>At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies.
We dislike inheritance as much as you do, but we also dislike ad hoc class systems that have worse performance.
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.
https://facebook.github.io/react/docs/web-components.html
There's also more opinionated integrations like https://www.npmjs.com/package/skatejs-react-integration.
And of course you can do it the other way around too.
Why people are always end up with J2EE-like bloatware? There must be some pattern, something social. It, perhaps, has something to do with the elitism of a being a framework ninja, a local guru who have memorized all the meaningless nuances and could recite the mantras, so one could call oneself an expert. The next step would be certification, of course. Certified expert in this particular mess of hundred of dependen…
Earlier quoted context omitted.
Come on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.
https://gitlab.com/Rich-Harris/buble/blob/master/src/program... vs. https://github.com/babel/babel/blob/7.0/packages/babel-plugi... Maybe you could explain how this is the same thing?
That said, the two are very different tools. Buble appears to be essentially string manipulation (which Babel does to occasionally with babel-template) built on top of Acorn. It's much simpler but there are a lot of useful transformations you simply can't do with that approach.
Edit: After some further looking into the project, I have to say that it seems like it would nice & easy to use for simple transformations, like the aforementioned React.createClass -> class Foo extends React.Component. However, you have to keep in mind that code that is not spec-compliant will break in mysterious ways perhaps months or years into the future. It may not be worth it, despite the ease.
`yarn install babel-cli babel-preset-es2015; ./node_modules/.bin/babel --presets es2015 -d ` is not particularly difficult.
Earlier quoted context omitted.
Stats for older IE versions are similar for most sites/apps I'm involved with, though I know in some niches they are still important. IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.
Yeah that's interesting. I might be biased since I'm in an exclusive B2B market. Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.
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.
You can use web components in React just fine if that's your cup of tea. https://facebook.github.io/react/docs/web-components.html There's also more opinionated integrations like https://www.npmjs.com/package/skatejs-react-integration . And of course you can do it the other way around too.
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…
Let's dispense with the "amateurs" first: the complete stack is build almost exclusively by people employed by Google, Facebook, Apple, Mozilla, and a handful of smaller, but at least as professional, companies. 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 t…
You might like to take a look at the history of Babel (formerly 6to5) as one prominent counter-example. For several years, much of the web development community has been relying on a great tool that was originally written by one talented young amateur.
Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.
Chrome being prominently advertised every time anyone visited a Google site using another browser probably didn't hurt. Being installed by default on the most popular mobile OS also didn't hurt. If openness were all it took, Firefox would surely still be a more prominent player.
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.
Google wants people to use the Web because it makes its money primarily from advertising on web sites. It is in Google's direct financial interest to support the part of the Web ecosystem that in turn supports advertising. That typically doesn't include, for example, corporate intranets, or embedded UIs in network-connected devices, or academic sites, which are three big areas where web technologies are widely used but stability and long-lasting content are more highly valued.
Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition
Writing as a professional web developer who often works in those other areas I mentioned, Chrome hasn't revitalised browser competition. On the contrary, it's become the new IE from the old browser wars. A lot of the new functionality only works properly in Chrome, and often it's not reliable even there because of the frequent updates that change behaviour and/or introduce regressions. There's no real concern about proper standardisation or compatibility or longevity any more.
But, more importantly, I'm unsure what you want?
I want the fundamental tools on which much of the ecosystem now relies not to break everything that predates a standard that is less than two years old and still not fully supported across many active browsers. In this case, that means being able to install packages from NPM with a reasonable expectation that they will not require a substantial extra build process to be used.
Obviously no-one contributing NPM packages has any obligation to respect that. It's not as if we're all paying for their openly licensed work. I just think the community as a whole will otherwise suffer yet more overheads getting infrastructure set up instead of actually getting useful work done.