Facebook devs devise Hermes to push cross-platform JavaScript to godlike speeds Facebook on Thursday released a JavaScript engine called Hermes under an open source MIT license to improve the performance of React Native apps. The ad biz made the announcement at the Chain React 2019 conference, which focuses on React Native development. React Native is an open source mobile application framework created by …
That's not fair!
Twice they've very carefully blocked the catflap at my house.
And on more than one occasion they declared my back garden a "designated safe place". They're so respectful of safe spaces they didn't even open the gate, preferring to lob the package over the fence into the long grass that pretends to be my lawn.
"Hermes is intended as an alternative to Google's (Chromium's) V8, Apple's JavaScriptCore, Mozilla's SpiderMonkey and ChakraCor [..]"
I had no idea that there were that many projects intending to improve Javascript performance. If there is that much trouble with JS performance, maybe it's a sign that it should be scrapped altogether ?
Yeah, I'm dreaming, I know. Blessed be NoScript.
address the performance trade-off, which is particularly acute for Facebook because it has complicated JavaScript-dependent mobile apps
Dunno about mobile apps, but on the rare occasions I need to use Facebook I always use Firefox, and it is the most painfully slow website to load on the planet! Main culprit seems to be chat, but does a page really need to make 150 requests?
Without at all saying anything complimentary about FB, the social network, or FB, the tax-avoiding corporation, I have to say that FB, the technology company does produce some rather interesting open source stuff.
- whatever their open server hardware specs initiative is called.
- React, which is the main winner of the JS GUI frameworks, Angular having kinda lost the thread with their release-to-release incompatibilities. I much prefer Vue.js myself and find JSX, i.e. sprinkling HTML into JS, an abominable concept, but you can't argue that React isn't capturing a lot of mindshare.
- GraphQL, which at least at the Query language/API/schema definition level is quite brilliant. Less convinced about how you would need to put together a backend if you can't use a prebuilt one like Apollo - all the examples I have seen so far have been pretty "Hello World" in terms of complexity. But the query language itself is still incredibly expressive and readable compared to everything else but SQL. And, unlike SQL or REST, it allows consolidation of multiple sources by the backend, rather than forcing the client to fetch multiple things.
Which leads me to think that they are not eating their own GraphQL dogfood all that well yet if:
>does a page really need to make 150 requests?
I'm fairly sure that Apache Thrift came out of Facebook too - that was a really tidy cross platform RPC protocol that I used quite extensively a few years ago.
I'm no fab of Facebook the data slurping, tax dodging corporation either but an inclined to agree about their open source contributions..
OTOH JavaScript is just plain evil and I can never get my head around why so much effort is put into making something so horrible run faster rather than inventing something better.
It has its uses - sure, making an Ajax call or client-side validating some input, but whole games? Node JS running it on the server side? No thank you!
It's not nice to read, it's inconsistent and unpredictable and it's a total bitch to debug. Why oh why do people keep building really complex stuff with it?
I don't mind JS that much. Sure, it has numerous flaws, but it's fairly expressive and well-written JS is actually elegant as long as you don't care too much about classes and OOP. What I deeply, deeply, object to is its tendency to paper over errors till later:
import fooo from 'bar';
I literally wasted hours on an error until I realized that I had mistyped `foo` so that it was null. Why couldn't it just blow up? It blows up just fine if you typo `baar` instead. I understand they keep errors from bubbling up until the very last moment both for backwards compatibility and because of their intent to keep the poor user from ever, ever, seeing an error. But it is still horrible for debugging.
IF you assume the need for a full-fledged client-side language, then you get all sorts of security risks. To some extent JS-in-browser does fairly well at taking what is really untrusted code from the hostile internet and, mostly, not nuking your security every single time. Attempts by Java, ActiveX and Adobe have fared much worse, so it's not that easy a problem domain to solve. The JS engines are what power WebAssembly so you'll get different languages in the future, not just JS.
But, yes, JS is tricky and unpleasant enough to debug that writing anything in node, besides my webpack configurations, wouldn't at all be a choice I would support from an architectural point of view. At the same time, besides the oft-bitched blinking ads Stackoverflow copypaste coders, there are some obviously very skilled JS programmers, much more impressive than the stereotypical AbstractDependencyFactoryInterface enterprisey Java crowd, that are able to write really solid JS and node code. Like I said, Vue.js and GraphQL's core implementation, but also things like d3.js or graphviz.js: these things shine in really separating out content from representation and accepting almost any conceivable input parameters. And the language's underlying dynamic (and confusing) nature is what makes that possible. Look at Swing's attempts in the UI space and laugh. I wouldn't write server code in JS and it would be a tough sell for me to base any part of my stack on node, if it was code I would ever expect to have to look at, but hey, if people know how to do it and do it well, all the good for them.
> I literally wasted hours on an error until I realized that I had mistyped `foo` so that it was null.
There's your problem right there. You don't understand the language. Your foo is not null, it's undefined.
To be fair, hardly anyone really understands JavaScript, and the superficially Java-like syntax is deeply unhelpful. There are very few decent texts on the subject, so people end up learning frameworks instead of the language and they end up with difficult to debug inpenetrable bloat that runs at a crawl. When you need to introduce a build phase to deploying code written in a dynamic interpreted language then something has gone very badly wrong.
For pure JavaScript, I find the debuggers built in to modern browers to be a joy to use. And JSHint plugged in to my IDE catches the typos long before deployment.
-A.
+1. Good catch, bad wording on my end, except it that subtlety matters not one whit in practice: the item in question was then essentially handled as a falsey by the d3.js templating engine and the first hint of that was when I noticed a column of SVG circles was _always_ unbolded, instead of 99% unbolded. If it had blown up, then I’d have caught it right away. But, much further down the line, something apparently totally unrelated, and quite a bit more complicated, was going wrong in funky d3.js functional-language type API calls that was hard to step through - I was trying to reason why my hard-to-compute expected 1% hit was 0 always.
JSHint... hmmm, never been keen on the signal-to-noise ratio of Python linters, so I never use them. Do use ‘black’ and thinking of moving to ‘type annotations’ too, on Python. But if you say JSHint can lessen the risk of this crap on JS I’ll take a look at setting it up.
FWIW, I have taken the habit of declaring undefined = object() in Python programs in cases where variables can have a legitimate null/None value. foo = {“a” : 1, b: None}.get(“c”) assigns None to foo. ...get(“c”, undefined) will return undefined instead. if c is undefined: then lets you know c was missing, as opposed to null-valued like b. This is important in things like computed properties. (But make sure you aren’t declaring undefined multiple times because that ’is’ is a pointer-type identity check, that was some other wasted time for me)
And, please, please, do not sully the good name of JS by comparing its syntax to Java ;-)
The icon? Not for you, what I felt like at the time
JavaScript's undefined needs a bit of respect because an identifier that has been declared but not initialised has a value of undefined, but an identifier that has never been declared and so can't really be said to exist at all also resolves to undefined. It helps to remember that variables are actually properties of an object -- either the global object or a function' local context. Also comparing a value to undefined is not necessarily reliable because undefined is, outside of strict mode, not a keyword, and may be assigned a completely different value! Use the void operator to be sure.
JSHint is genuinely useful, unlike the ridiculously prescriptive JSLint upon which it was based. It would have alerted you pronto about the undeclared identifier.
The d3 library is undoubtedly clever, but I agree that it goes out of its way to demonstrate JavaScript's functional bona fides, sometimes at the expense of clarity.
-A.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
