281–290 of 422 posts
Neither the comments nor the article mention this, so I figure I'd ask here -- the React team has been promising performance improvements for stateless functional components (I think because they require less/no overhead + lifecycle management) for some time now, but I don't think it's moved beyond that. Does Fiber introduce any of those optimizations, or nah?
Earlier quoted context omitted.
Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon). The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be…
A web limited to textual content is a pretty quaint and uninspiring vision, IMO. The web started that way because static documents are relatively easy to represent, but the future (and present, for that matter) is rich experiences that can be distributed in the same way. But there are many steps left to get there, so either buckle up and help build that future, or get used to an ever-shrinking ecosystem of the purely…
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.
That's a luxury you only get when your API is good. With Angular, the problem was the API.
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.
That's a luxury you only get when your API is good. With Angular, the problem was the API.
By the time Angular 2 was released, Ember, Vue and React have devoured the market
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.
Of course it feels easier to stick with what you know, but managing the DOM with data is so much easier than using jQuery + Handlebars.
Seriously, spend some time learning Vue. You won't regret it.
It has to be said that you don't need any building process (Webpack, gulp, etc) to use Vue. You can simply write your templates in your index.html and import using .
Earlier quoted context omitted.
You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist. Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtim…
Runtime checks don't stop you from doing heavy data processing or having microsecond-level response times. It seems like your objections fall into two categories. One is caused by it running in ring 3, which can be solved by correcting "anything" to "any user program". The other is moderate performance limitations that don't stop it from running full video game engines. Those may not be ideal but they won't stop you…
Also, unless you definition of "can run a game" includes "can run a game at 3fps" I'm pretty skeptical that the entire repitoire of games for those engines can make the jump to WebAssembly today.
Earlier quoted context omitted.
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…
Completely agree here. I think many people realize this and have built awesome tooling to be able to manage different ecosystems and environments. One that I've been particularly keen on over the last year is GraphQL. If you're interested in simplifying frontend development while giving it more power and control to dictate the data that it needs for each component / view, you should check out GraphQL. I know what you…
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…
So much negativity here. Constantly pushing the boundaries of existing technology is how we got here in the first place. If we were content with the status quo, we'd still be looking at a four-month journey from New York to San Francisco on horseback.
> The company hasn’t previously talked about React Fiber Except, you know, the entire presentation on it at React Conf back in March.
It's TechCrunch... I won't say anymore because I'm also a member of the press... but it took me 3 seconds to find this on Google: https://gist.github.com/duivvv/2ba00d413b8ff7bc1fa5a2e51c61b... Somebody forgot to fact-check his article. That's for sure.
Earlier quoted context omitted.
Huh? Who is talking about monoculture? OP certainly isn't, and I don't think anyone else is seriously suggesting such a thing. It's not unreasonable to expect that the ecosystem doesn't operate under an ever-expanding set of wrappers, frameworks, layers, and models, and it's certainly not unreasonable to expect that our tools don't suck. The open standards you talk about ARE already a part of the ecosystem, and well-…
First, let's be clear here: React was first open sourced in 2014, being used at Facebook extensively before that. Sure, it's no Win32 API, but it's not exactly the new kid on the block. But the point of the web already having these standards is exactly the point - these frameworks are built on top of and contribute to the underlying universal standards, so what's the problem?
It's basically the same instinct as complaining about code written from a previous dev that you didn't write--because you didn't write it, you weren't there to think about the very real tradeoffs that always have to be made when actually implementing something, rather than just complaining about the previous person's implementation.
I never know which abstraction people are complaining about. Is it http? html? the dom? javascript? wrapping libs like jquery? view frameworks like react? routing frameworks? complete frameworks like angular? what's the solution? get rid of all of those things? use different UI abstractions? get rid of javascript ?(oh wait, you can already). The truth is, it's just easier to complain than it is to implement, so that's what people do.