151–160 of 422 posts
No thanks I'll stick with plain html and jquery for the frontend of my small projects. Plain javascript works perfectly fine as long as you namespace your functions and separate them into different files. All these frameworks end up creating much more problems than they solve.
Sounds neat, but it also seems like an explosion in complexity -- perhaps there will be a bunch of weird scheduler bugs the operating system folks more or less figured out a long time ago?
See, Google should learn from Facebook: total API compatibility with the previous version. They saw what happened with Angular and Angular 2—which Google named the same despite it being a totally different framework—and made a smart move.
Earlier quoted context omitted.
JSX is not JavaScript, it's a non-standard bastardization that will never be supported natively in browsers. Its reliance on JavaScript for flow control is so problematic[1] that people have started working around its many glaring inadequacies by adding new language primitives to JavaScript itself via Babel plugins[2]. I do my templating in template literals because using standards-based JavaScript means that I don't…
It was never intended to be supported natively by browsers -- it's syntactic sugar for the React.createElement API. That's what I mean when I say JSX is Javascript. That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX. The community has since unambiguously decided to avoid inserting more control flow in JSX. Also, I'm not entirely sure what the do/while plu…
And yet the underlying issues still remain unaddressed. There aren't better ways to handle the cases raised in that issue, which is why people resort to adding additional non-standard syntax to work around the warts.
> Also, I'm not entirely sure what the do/while plugin has to do with JSX.
The "do" keyword is not do/while, it's a non-standard language feature that you can use to turn statements into expressions by wrapping them. It's like using an IIFE with a return value so that you can use a conventional "if" or "for" statement in place in JSX.
> I would argue if you can write your code as easily with template literals as React/JSX your application isn't complex enough to warrant using a framework.
I don't think you really understand how template literals work. Tagged templates can be used for more than just basic string interpolation. You can read more on the subject here: https://appendto.com/2017/02/advanced-javascript-es2015-temp... Or have a look at t7, which uses tagged template literals for virtual DOM templating: https://github.com/trueadm/t7
Earlier quoted context omitted.
I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. Its amazing to me that the autoconf/automake/libtool system for making write-once-run-everywhere *nix applications is downright simple by today's standards. Every year the hot libraries change, the build too…
I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to…
Except, it's already a monoculture of one language (JS) and one display algorithm (DOM) and everything is just compensating for that.
The "runtime" is not general enough.
any news on bundle size? and maybe Closure Compiler compatibility for dead code elimination?
No final numbers yet, but we recently switched to Rollup for our own builds which will be part of 16.0, and we'll do some more work on file size in the next few months. For DCE, we've started splitting some features like createClass out of the main package ( https://facebook.github.io/react/blog/2017/04/07/react-v15.5... ) which will reduce the bundle size for anyone not using them, regardless of how they compile the…
Many mobile users are on throttled connections, due to low data caps, and research has shown users stop loading a site usually after 1 second of loading time.
That means with a throttled connection, less than 8KiB overall CSS, JS and HTML can be transmitted, and with a 1Mbps connection, 128KiB can be transmitted.
How many minutes will users have to wait with React Fiber? And can it be improved in any way to get below a few seconds? Or will I have to continue to write vanilla JS to get responsive apps?
how this will affect react native?
https://facebook.github.io/react/contributing/codebase-overv...
Earlier quoted context omitted.
I think it runs the test suite live... It's not meant to be fast, but to demonstrate compatibility.
Are you sure? Because that's a waste of resources. I'd imagine they would cache the results, which would make the GP's concerns about speed valid. Edit: Found the github repo - https://github.com/tomocchino/isfiberreadyyet Looks like it fetches from the umbrella issue[1] https://github.com/facebook/react/issues/7925
Earlier quoted context omitted.
> which is the standards-based approach that ES6 actually provides for embedded DSLs and templating. Template literals could not possibly be a replacement for JSX. JSX is Javascript, template literals are strings. JSX isn't a templating language by design, it's one of the primary advantages.
JSX is not JavaScript, it's a non-standard bastardization that will never be supported natively in browsers. Its reliance on JavaScript for flow control is so problematic[1] that people have started working around its many glaring inadequacies by adding new language primitives to JavaScript itself via Babel plugins[2]. I do my templating in template literals because using standards-based JavaScript means that I don't…