Show HN: Nerv – A fast React alternative, compatible with IE8 and React 16 | Hacker News Reader

Show HN: Nerv – A fast React alternative, compatible with IE8 and React 16

github.com

133 pointsyuche73 comments

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.

[1] https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu...

Border-box is arguably more useful than content-box, so the IE5.5 is not a huge deal. You can make other browsers act like IE5.5.

Back in the day it was quite a PITA though.

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.

> IE6

Jesus... And I thought IE11 was bad (enterprise SaaS such as Salesforce is dropping its support already).

I’ve tried to run IE11 debugger on Virtualbox and it was slow as molasses.

It looks like these guys are from China, where ie8 support still makes sense. It's still used a lot there unfortunately.

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).

You can use Java/nashorn for server side rendering of react.

... you can also use react for server-side rendering of react

You say isomorphic almost like you dismiss it.

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 think you underestimate how much money is made selling software to firms who still use IE8.

> I've spent way too many hours of my life learning quirks of the horrible piece of garbage that is IE8

Son, let me tell you about Netscape 4...

But Chrome and Firefox are IE8 contemporaries. IE8 was just abysmal considering its competition.

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?

Opened an issue, hoping one of the authors chimes in and clarifies: https://github.com/NervJS/nerv/issues/10

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!

Anybody up for trying?

Wasn't aware of the major v16 rewrite (I'm not working on a react front-end at the moment). But seeing overviews like: https://dzone.com/articles/react-16-release-whats-new

(also: https://reactjs.org/blog/2017/12/15/improving-the-repository...)

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.

Some discussion here that I missed: https://news.ycombinator.com/item?id=15339983

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:

- Lin Clark's fantastic ReactConf presentation on "A Cartoon Intro to Fiber": https://youtu.be/ZCuYPiUIONs

- The official announcements for React 16: https://reactjs.org/blog/2017/09/26/react-v16.0.html and https://code.facebook.com/posts/1716776591680069/react-16-a-...

- A good summary of the major changes: https://www.infoq.com/news/2017/05/react-fiber-closer-look

- Two articles looking at the user-facing features and changes: http://www.benmvp.com/slides/2017/reactboston/fiber.html#/ and https://www.robinwieruch.de/what-is-new-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).

It's not even based on a fork of React, either.

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.

I'm guessing they are working for a company that was using this and allowed / encouraged the authors to make it open source.

Apparently this isn't just two guys: https://twitter.com/rauchg/status/951185263698391040

Another interesting bit: https://www.reddit.com/r/javascript/comments/7phc5q/a_fast_r...

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.

Good to know. Still, they could have done a much better job communicating that.

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.

Supposedly it is by jd.com - one of the big Chinese tech players.

Given that there is a reasonable number of Chinese PCs still on Windows XP, IE8 support makes sense.

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.

Seems clever though.

The "why" is IE8 compat. If IE8 is a large part of your traffic that's a compelling reason.

And it looks to have been made mainly for use in mainland china, where I would think a lot still users IE8.

If that's the only reason thats a reasonably small niche - WinXP only most likely.

I mean China & India have more of those machines but... it's still a niche.

It looks like the README[0] was recently translated from Chinese to English.

The Chinese README is still present in the current version published to NPM[1] which is v1.2.2

[0]: https://github.com/NervJS/nerv/commit/18b1d8720b69d250603d58...

[1]: https://www.npmjs.com/package/nervjs

Information about performance is on the webpage, scroll down to Benchmarks section: https://nerv.aotu.io/

Shame that the y axis on the first 3 charts isn't labeled. I assume it's milliseconds, kilobites, milliseconds.

The benchmark tabs don't appear to work in Firefox (they work fine in Chrome). Assuming the website is built with Nerv, that's a big red flag.

Firefox console says "Reference error, event is not defined" when clicking on a tab.

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() }

    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.

On the other hand it looks like it is being at least sponsered by JD.com [0] which is a big chinese company [1]

[0] https://jd.com/

[1] https://en.wikipedia.org/wiki/JD.com

I tried this on my ReasonReact app and it doesn't work. Seems like this has many assumption about React internal instead of focusing on the public API

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.

The Y-axis on the benchmarks is labelled starting at 1. In short, this is barely 20% quicker than React.

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.

I am curious why is that the case? Organizations afraid to upgrade? People in developing countries using outdated OSes? Some other reason?

Is it 100% pass the React 16 tests?

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.

As far as i can tell, this has zero dependencies. Wow - impressive stuff!

I wish I understood why web developers hate polymer so much.

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.

It worked fine for me in August 2017?

Because WebComponents is still not a thing and browser vendors can't seem to agree?

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.

Why do you need to update?

This is a featherweight component:

    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.

I'm confused by the title. Why no mention of e.g. Chrome, Safari or Firefox?

And if it's meant to be a React alternative, then I suppose it should support native as well.

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.

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).

The official docs for React Native are at http://facebook.github.io/react-native/ by the way.

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.

While React Native makes use of the react core package, it is a separate github project http://facebook.github.io/react-native/

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.

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.

Is this a fork of inferno js?

Not a fork, fresh new, you can see the commit history.

Another one??

cool project, will try out soon

Reply on news.ycombinator.com