Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
JerryScript: lightweight JS engine for IoT (github.com/jerryscript-project)
87 points by galfarragem on Jan 25, 2021 | hide | past | favorite | 35 comments


If you are interested in lightweight JS engines, you might also want to take a look at these benchmarks:

https://bellard.org/quickjs/bench.html


Man, V8 is amazing technology.


Absolute domination. Even the jitless run is ahead in all but 2 benchmarks.


It even dominates in executable size! ;-)


A pity SpiderMonkey wasn't included.


No JSC either.


JSC isn't even in the same ballpark for memory usage.

https://medium.com/walmartglobaltech/react-native-memory-pro...

Apparently Apple has invested more in raw JS performance while Google has invested more in their garbage collector.


SmallTalk is great, right?


Are you claiming JS or V8 is heavily influenced by SmallTalk?


Only V8, which collected a lot of the people formerly working on the StrongTalk VM. JS is mostly influenced by Scheme, Java and infernal visions.


That's interesting because I had someone that read some V8 source tell me that the JS function calls were managed via messages. I wonder if that's true, and how it fits with the Jit...


Fun fact, this is running on my watch right now. Fitbit (by way of their Pebble acquisition) uses it to power their watch faces and apps. It let's developers use a high-level language like JavaScript to build for their platform, which increases developer accessibility. I've built apps on C for Pebble before which is not that fun by comparison.


If you only have 64kB what's the point of using JS? I get that I'm free not to use it, but I genuinely don't understand why these projects are popular - you nearly always end up using C in the end anyway, especially because embedded nearly always means writing to registers and specific memory addresses.


Same as the point of high level languages generally, you can express more complex application logic with much less programming effort plus you can focus on your app instead of worrying about manual memory management crashes and security vulnerabilities.

Register/memory write primitives can be easily exposed to the HLL.

(Yes there are other high level languages besides JS you might use too, eg MicroPython...)


High level language should have worry-free memory management or memory safety built-in. Javascript does not have this characteristic. If we ever have to removeEventListener anywhere, it's worrisome in general.


Some people only know JS, or just don't want to learn both embedded and C at the same time. If projects like this can help people get over that initial hurdle, then all the better.

Plus, writing constrained environment language implementations is quite fun.


I guess so.

Directed at anyone asking the question your first paragraph raises: C isn't that bad, give it a try, even if you don't use it your skills and perspective as an engineer will thank you.


Pointers are quite a hard concept for a lot of people to wrap their heads around. JavaScript’s lack of them is easier to understand for them.


In my experience the harder thing is the stack/heap memory model.

It’s easy enough to get someone to understand that the variable “points” to another variable like a house address or whatever. But, trying to explain that once a return happens the thing that was pointed to will potentially be gone entirely and you probably wont know immediately, or at least until you call another function, unless you allocated it with malloc, but in that case you need to be sure to call free at some point later, but watch out don’t call free twice, and hey there’s some analysis tools you can use with gdb to help find these types of issues, oh yeah gdb is this debugger it has its own special syntax you’ll want to learn than too, etc etc etc.

It’s so much easier to say: oh, you want to make a tree? Just make some leafy nodes and make some branchy ones point to them and you’ll literally never see segfault in your life. The pointers are still there, but the trouble is gone.


C's point syntax doesn't help either. It's fine if you just have one pointer. But a few of them nested with some functions in the mix. Oh my.

Oh, and basic primitives like arrays and strings in C are far more complex (and easier to get wrong) than pretty much every other language. And it doesn't have a built in map type at all!


If you can understand how 'this' works in javascript you can almost certainly understand pointers in C.


I'm not so sure. I learned pointers via C++ years before I tackled JS. Though I suspect you mean that the comprehension is similarly difficult, the paradigms are quite different. Visualizing and mentally tracking `this` by scope is aided by the structure of JS (even though it can get hairy with `bind`). Pointers requires a different model of thinking, and it's not one that's native to many languages. I originally came up in the mid-90s with VB3 and it was quite a jump to C++.


It gives people access to embedded without them needing to learn C. This is useful for hobbyists. I'm not against learning new languages, but sometimes you want to use what you are familiar with so that you can think about your project, not learning to write the code.

Also re: your last point, most of these languages have library support for common features, and you definitely don't have to think about registers and memory addresses. Look at the kind of projects people make with Arduino, flashing LEDs and servos work just fine in a high level language.


> Arduino, flashing LEDs and servos work just fine in a high level language.

Arduino is C++, no? I would class C and C++ as being basically in the same tier here


Well, it's c++ but most users interact with high level libraries, so you don't really need to know much c++.

But still, there's no reason you can't tell the board to switch a pin on in JavaScript or Lua. You don't necessarily need that level of control for most hobby projects.


mostly I think it appeals to non traditional embedded programmers. It has some appeal in that it is easy to send code to devices as "data" ( much the same as the advantages of embedding lua or other scripting languages ). Certainly not something I would choose though (I do IoT systems from the embedded devices -> backend -> web frontend ).


You can easily virtualize your device for secure computing this way. I did a seminar on secure IoT computing and that was one of the main selling points of it. Since the vendor only exposes the APIs they want and has full control of them they can open up the platform more.


It seems that it actually cannot be used for such small systems. README states that this compiles to 160kB. But i agree with your point, unless theres some OS on board, using JS is probably too restricting.


Yeah the problem is that you basically write C in Javascript in the end. You'll constantly have to second guess which features aren't supported.


Nice comparison of js engines can be found in the issues here https://github.com/jerryscript-project/jerryscript/issues/43...


What can you run it on though? The engine weighs 160kb


Apparently fitbits.


Whow, much faster than Bellards quickjs, and most others. Small is better.


Benchmarks on Bellard's site [0] show that it's several times slower than QuickJS. Are there new developments on this front?

[0] https://bellard.org/quickjs/bench.html





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: