5 ms·

I wonder if something like this could be used to build an electron alternative (or modify the existing electron backend to use this engine), since memory usage

I wonder if something like this could be used to build an electron alternative (or modify the existing electron backend to use this engine), since memory usage is a major complaint for these applications

draw_down 7y ago
Amazing, very first comment is about getting rid of Electron. I love you guys.
- non-entity 7y ago
  You misread my comment. I also suggested replacing the internal engine it uses with this lighter version to make it performant. modifying to be more performant != getting rid of
- deleted 7y ago
  [deleted]
liveoneggs 7y ago
> However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.
est31 7y ago
This is mentioned in the lead paragraph: > Lite mode of V8 specifically aimed at [...] embedder use-cases that care more about reduced memory usage than throughput execution speed.
- non-entity 7y ago
  Ah, I mistook that as embedded (i.e. usage on microcontrollers / etc.)
  - leggomylibro 7y ago
    JerryScript and Espruino aren't that good yet, but embedded JS is an option. You'd probably just be better off with embedded Python or Lua in most cases (MicroPython / eLua). Sadly, eLua doesn't look very active since 2016-ish
giancarlostoro 7y ago
Well... Electron is powered by Chromium, but uses NodeJS which is based off of V8, V8 is also the default JS engine for Chromium. So in theory, it would benefit Electron directly, not sure why anybody would waste the engineering efforts to recreate Electron if these changes will find their way on Electron. Edit: Didn't mean to make it sound personal on my second paragraph, but the rest of what I wrote still applies with the context of the article and the comment made.
- non-entity 7y ago
  Dear lord people are getting pointlessly defensive and aggressive. Obviously this article is not referencing the full V8 engine, but a light version that may or may not make it into Chromium You might want to re-read the HN guidelines > When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
  - hwillis 7y ago
    The article is about how many of the lite mode optimizations were added to the last 7 v8 releases, resulting in an 18% reduction vs lite mode's 22%. The people responding to you are making the case that the 18% reduction is basically as good as.
  - Scarbutt 7y ago
    You missed these guideline: Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." So, the article mentions that.
  - apendleton 7y ago
    > Obviously this article is not referencing the full V8 engine, but a light version that may or may not make it into Chromium Obviously? Right from the second sentence, the article says: > Initially this project was envisioned as a separate Lite mode of V8 specifically aimed at low-memory mobile devices or embedder use-cases that care more about reduced memory usage than throughput execution speed. However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.
realusername 7y ago
The memory issue with Electron is the DOM, not the Javascript. Reducing V8's memory isn't going to help much.
- derefr 7y ago
  What is it about the JS DOM that makes a DOM of N elements modelling a given app’s view, have a higher memory footprint than the “DOM” (view state) of a native graphics toolkit modelling an equivalent app’s view?
  - smolder 7y ago
    Part of it is just how feature complete browser compositing is. The other part is bloat due to how it was all implemented. HTML and CSS were never optimal representation for complex documents, and a ton of features have been added on top.
    - arc33 7y ago
      Can't we compile those things out of the engine when using it for the desktop?
  - coldtea 7y ago
    >What is it about the JS DOM that makes a DOM of N elements modelling a given app’s view, have a higher memory footprint than the “DOM” (view state) of a native graphics toolkit modelling an equivalent app’s view? For starters, because the DOM is a very inefficient design of an app's view, primarily designed for text and simple forms, and with all kinds of extra crap bolted on. Until CSS Grid, there wasn't even a proper layout engine available, and people used styling primitives meant to float text for UI design... A native UI engine can implement drawing a window with a button (the raw widgets, design wise) with a few lines of code to draw, two rectangles, some edge shading, and some text. The DOM has thousands of lines for all kinds of contingencies for the same thing...

draw_down 7y ago

Amazing, very first comment is about getting rid of Electron. I love you guys.

non-entity 7y ago
You misread my comment. I also suggested replacing the internal engine it uses with this lighter version to make it performant. modifying to be more performant != getting rid of
deleted 7y ago
[deleted]

liveoneggs 7y ago

> However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.

est31 7y ago

This is mentioned in the lead paragraph: > Lite mode of V8 specifically aimed at [...] embedder use-cases that care more about reduced memory usage than throughput execution speed.

non-entity 7y ago
Ah, I mistook that as embedded (i.e. usage on microcontrollers / etc.)
- leggomylibro 7y ago
  JerryScript and Espruino aren't that good yet, but embedded JS is an option. You'd probably just be better off with embedded Python or Lua in most cases (MicroPython / eLua). Sadly, eLua doesn't look very active since 2016-ish

giancarlostoro 7y ago

Well... Electron is powered by Chromium, but uses NodeJS which is based off of V8, V8 is also the default JS engine for Chromium. So in theory, it would benefit Electron directly, not sure why anybody would waste the engineering efforts to recreate Electron if these changes will find their way on Electron. Edit: Didn't mean to make it sound personal on my second paragraph, but the rest of what I wrote still applies with the context of the article and the comment made.

non-entity 7y ago
Dear lord people are getting pointlessly defensive and aggressive. Obviously this article is not referencing the full V8 engine, but a light version that may or may not make it into Chromium You might want to re-read the HN guidelines > When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
- hwillis 7y ago
  The article is about how many of the lite mode optimizations were added to the last 7 v8 releases, resulting in an 18% reduction vs lite mode's 22%. The people responding to you are making the case that the 18% reduction is basically as good as.
- Scarbutt 7y ago
  You missed these guideline: Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." So, the article mentions that.
- apendleton 7y ago
  > Obviously this article is not referencing the full V8 engine, but a light version that may or may not make it into Chromium Obviously? Right from the second sentence, the article says: > Initially this project was envisioned as a separate Lite mode of V8 specifically aimed at low-memory mobile devices or embedder use-cases that care more about reduced memory usage than throughput execution speed. However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.

realusername 7y ago

The memory issue with Electron is the DOM, not the Javascript. Reducing V8's memory isn't going to help much.

derefr 7y ago
What is it about the JS DOM that makes a DOM of N elements modelling a given app’s view, have a higher memory footprint than the “DOM” (view state) of a native graphics toolkit modelling an equivalent app’s view?
- smolder 7y ago
  Part of it is just how feature complete browser compositing is. The other part is bloat due to how it was all implemented. HTML and CSS were never optimal representation for complex documents, and a ton of features have been added on top.
  - arc33 7y ago
    Can't we compile those things out of the engine when using it for the desktop?
- coldtea 7y ago
  >What is it about the JS DOM that makes a DOM of N elements modelling a given app’s view, have a higher memory footprint than the “DOM” (view state) of a native graphics toolkit modelling an equivalent app’s view? For starters, because the DOM is a very inefficient design of an app's view, primarily designed for text and simple forms, and with all kinds of extra crap bolted on. Until CSS Grid, there wasn't even a proper layout engine available, and people used styling primitives meant to float text for UI design... A native UI engine can implement drawing a window with a button (the raw widgets, design wise) with a few lines of code to draw, two rectangles, some edge shading, and some text. The DOM has thousands of lines for all kinds of contingencies for the same thing...