I'd consider supporting IE8 an anti-feature. The browser is insecure, unsupported, and non-standards compliant.
I've spent way too many hours of my life learning quirks of the horrible piece of garbage that is IE8. I don't think I hate any other piece of software as much.
If I had to support IE8 I'd instead try to make the site work without any JS. Anything even moderately complex would run horribly anyway.
I think the reason for the IE8 support is that there are still lots of old windows machines used in china.
And if you think IE8 is bad, have you ever had to support IE6? ;-)
IE 5.5 with no box models would be a contender [1]
At Social Amp (2012), I was making cross domain single-page applications for sites like 1-800-Flowers, where we had to support back to IE6, but, since a tag was missing from the main website, we had to do some hacks to "shore up" IE6 so the padding would be there.
It's feasible to have some pretty sweet JS (backbone.js, easyxdm) on IE6. The limitation came from the engine's performance, stylesheet and js caps, and really strict rules on, dangling commas (memory is a bit fuzzy in which instances, but it'd crash our whole script). In some cases, there'd be no errors, and it'd just freeze it.
People who say this rarely have tried using a SPA on IE8. As the OP said, you'll provide a better experience giving them a pain ole server rendered app.
Making a site written in React work without JS is quite an endeavor. If you’re not just using it for some progressive enhancement (and frankly, that seems a dying art), then it’s either a whole new backend or trying to be “isomorphic”.
The latter is somewhat difficult in an environment where IE8 is a factor (node as enterprise backend software is often a no-go).
I structured my site so that, in the worst case, the user has a plain old site of HTML + CSS and lots of hyperlinks that work just fine. My drop down headers default to pages that show the drop down content.
The embarrassing part was I had a simple bug affecting a sizable chunk of my user-base. In a certain browser, no code would run. But I never received a single complaint, because no one noticed. Sure, some fancy extras didn't work, but they are used to that with that particular browser. The information and required functionality was there. And I didn't have to write it in both PHP AND Javascript.
I still remember the horror when I learned the Sharepoint 2010 site i was pulled off React/Typescript for only supported IE8. And then learning the client was actually (slowly going down) our biggest source of revenue, and has so much stuff on SP2010 migrating away or upgrading SharePoint is out of the question.
I would'nt like to keep IE8 alive, sooner enterprises can't throw any more money at the problem, sooner we all get big paydays from the migration projects.
I'm a bit weary of this project since neither the website nor the readme mention any tradeoffs. Surely, if I choose Nerv over React I miss out on something—what is that something? Why would I _not_ use Nerv?
Thinking about this more, the React team recently (for the v16 rewrite) rewrote almost their entire test suite to use their public API. I wonder what'd happen if you ran that test suite with Nerv—if it passes all those tests that'd be a great confidence booster!
makes me much more positive towards react - feels like there's some people taking the stuff quite seriously. Still not sure about the whole js idea, portable code that's unsigned etc - but things like this feels a little less... Cowboys and cool-aid than I'm used to from the js side of things.
Yeah, the React team takes backwards compatibility very seriously. They did finally drop some deprecated methods from the main package in React 16, but made them available as separate packages, and even wrote codemods to automatically replace usages.
I can recommend several resources for understanding the changes in React 16:
> hoping one of the authors chimes in and clarifies
That is an example of exactly why not - the support behind React is huge. Even if we take their word that Nerv is great from a technical perspective, it doesn't have the same level of community support.
Not that I am suggesting we ignore anything new just because it has a smaller community... just pointing out a downside that should be considered before using it on production projects.
It would be great if the author could explain where the performance gains come from and what the internal mechanics of the project are. Does it piggy back onto the existing react repo? Is it just a forked react repo with performance improvements? Giving some insight on that may give your potential users a good reason to jump onto the bandwagon.
This smells like digital snake oil. It claims to be identical to React 16 + IE8 support, improved performance, and reduced size, with little mention of details about how any of that works and zero mention of tradeoffs. I don't see how two developers came out of nowhere and one-upped one of the biggest tech companies on the planet (with one of the biggest open-source communities on the planet).
To add a bit of context to the second link (a comment I made): the core patching algorithm in nerv is based on the patching algorithm from ivi, a library that was created by Boris Kaul (creator of several benchmarking tools used by virtual dom authors) as an exercise in making the fastest virtual dom possible.
It popularized the prefix/suffix algorithm used in most vdom libs today, and in addition, it's one of the only ones that use a LIS algorithm to further decrease the number of DOM changes in complex DOM reordering scenarios. Ivi also does a ton of other micro-optimizations.
Seeing that ivi was part of their research material tells me that this library's perf claims have a least some foundation to back them up.
I'm actually just happy that this is even on Github at all (and with english docs, to boot). If it's a jingdong project and the perf claims are true, it could've been a competitive edge for them and they had no obligation to make it open source.
I took a quick look at some of the earlier commits... and if there's any underlying React code there, then it's either been hand-written or hand-copied.
Size is nice but I see nothing to support claims of performance improvements and React performance is rarely a problem in most apps anyhow (data manipulation and JSON serialization are usually an order of magnitude more impactful).
Also understanding why it’s better vs Preact/etc would be useful. The readme is quite lacking on why it should be used other than it’s React compatible.
Naw, that error is the easiest way to spot Chrome only developers. Webkit provides the global event symbol within an event handler (old IE behavior). With Firefox, you must explicitly pass an event variable. The difference between:
onClick () { event.doSomething() }
vs
onClick (e) { e.doSomething() }
The error isn't firing from the Nerv library, it's from their usage of it on the marketing site.
I'd still say it's a red flag. The developers of a browser library didn't test their site in Firefox. Makes me wonder if they tested the library in Firefox. Nerv is a library that wants to take an absolutely critical role in my app, I need to feel extremely confident choosing it.
Sure, it's a flag, but Nerv does have a test suite (with 96% coverage) that proves it runs across all browsers. I'm sure the marketing site does not have a test suite like that. You can't hold it to the same bar.
That's fair. I'm just giving honest feedback. I understand Nerv is open source and not being built by a large entity like Facebook. It's also likely a nice library. So sure, I should cut them some slack. But at the same time, there's a lot of React clones to choose from, and seeing a simple error like this right out of the gate is off putting.
Whenever I see some kind of project like this I expect to see an explanation of why the project exists or why I would want to use it, especially if there is another project it's trying to compete with. The only info I got was from the title: IE8. I see the word performance being thrown around. Who cares if you're not having performance issues?
Do you have any performance numbers or benchmarks by which to measure the claims of superior performance? I’m not doubting you do see better perf - but I’m curious how this compares to other React alternatives.
If you want to support old IEs, IE8 seems somewhat pointless as many applications that really require compatibility with unsupported IE versions have to support whatever is in Windows CE images on installed base of various thin clients, which means IE5 or 6.
I'm (very unfortunately) an expert in this area. By the numbers IE8 is a must if you want to support your site globally. I've only recently managed to deprecated IE7, but IE5 and IE6 are negligible.
I'm not talking about public facing websites, but internal applications. For public facing websites graceful degradation is at least for me acceptable and it is not that hard to build site that gracefully degrades and is still usable in browser that does not support JS and CSS at all.
If it were me, I would quit if our IT department still supported IE8. This package was developed for JD.com which is a site where supporting IE8 makes a lot of sense.
Don't know if you're the author but under the Performance section, there is a typo: "Le{r}an More". Also, your none of your performance graphs have a label/unit of measure for the Y.
I use Polymer at work quite a bit, and its really nice, but it's a completely different approach based on trusting that the DOM is sane and running as close to web standards as possible.
React and its 1 billion clones run off of the assumption that the DOM API is not to be trusted, and that lets you target more browsers, even non browsers. I mean have you ever tried to get Polymer stuff to work in Firefox? It's not Pretty.
Polymer is one of the worst offenders when it comes to treating backwards compat seriously, worse than Angular even. We're testing frameworks on projects internally to get an idea, Polymer is going through the third full rewrite.
That also speaks volumes about its approach, it just doesn't know what it wants. It's again based on weak, string-typed templates and is designed imperatively. After React, there's no time for this stuff anymore.
I feel like this is quite overstated as a problem, since nothing really compels you to update. Polymer is a small enough library that it's easy to contribute to and the components are so featherweight you hardly need someone to make 30 new versions.
If you're only Polymer1, the only motivation to go to Polymer2 is performance. I suspect the same thing will be the case for Polymer3.
const A = () => <div>hi</div>
const B = () => <A />
Polymer is everything but light, it is a huge abstraction. It ships a template engine parsing arbitrary syntax, emulates an arbitrary javascript accent, relies on dependency injection (in the above example it couldn't even refer to component A for instance).
Being stuck with an old version that becomes unable to participate in its own eco system is no joke. It isn't just about performance. Imagine the implications for the community that builds parts, components and tools. Even if you deal with self-contained web-components, you'll still fetch two full versions of Polymer just to have them side by side. How insane is that?
And if they finally find a good balance, perhaps version 4 or 5, it has to compete against React eventually. And i doubt it'll look any less poor than it does right now.
Using js to write a component framework is quite more heavyweight compared to using a browser supported system.
In terms of weight, Polymer is less so because it uses less js code (the most expensive bytes for all parties), has fewer dependencies, and doesn't try and render server side.
As for ok'd versions: why is it impossible for a company or individual that needs it to maintain it themselves? Anyone using React or Angular also needs to do this.
React seems, to me, to be too big to fail. And the existence of Redux should show: it is far from perfect.
There have been drop in replacements for react+react-dom before, like inferno and preact. They all have claimed perf benefits, though benchmarks usually don't mean much. The size differences have been meaningful in the past though. If this gets React down to 9kb, it would be pretty amazing.
React-native doesn't care on the other hand if the payload is 20kb smaller. Never seen a drop in replacement for it.
It's suspect it's not in the title, because it's assumed and not interesting or unique. Browser compatibility is listed on linked page.
While it may share a common history and core with ReactJS, React Native is really a separate beast. I realize it may be confusing due to the overlap in names. When people say React they are generally referring to https://reactjs.org and not the intersection it has with http://www.reactnative.com/ or the union of the two projects.
React and React Native are very much related. Both use the same core 'react' library, and differ between 'react-dom' and 'react-native' (and the native code).
I know, which is why I said they have a common history and core. react and react-dom are both part of the same github project at https://github.com/facebook/react. Frequently when people are talking about React, they only mean the HTML version, not including React Native. For example, the Nerv project mentioned in this post.
The title is probably because those platforms are more of a given. IE8 is somewhat old, so maintaining compatibility with it is a differentiator over other virtual DOM view-layer frameworks.
Its nice that the ideas of React are simple enough so that a single dev can rewrite it as a side project but we probably have enough of these at this point. Also React's performance is almost always the culprit for performance issues in my experience.
I've spent way too many hours of my life learning quirks of the horrible piece of garbage that is IE8. I don't think I hate any other piece of software as much.
If I had to support IE8 I'd instead try to make the site work without any JS. Anything even moderately complex would run horribly anyway.