10 ms·

Neo.mjs – Webworker-driven UI framework

50 points by tobiu 7y ago

jitl 7y ago
No example in READE - sad!
- tobiu 7y ago
  Actually there is a link to the online examples at the top of the readme: https://neomjs.github.io/pages/ https://neomjs.github.io/pages/ This is a new paradigm: you can now include JS modules directly into workers inside the browser. This will be fully supported in Chrome 80 (already works in canary). The concept makes debugging extremely convenient, since you get the real code without source-maps and the multi-threading gives a relly nice performance. I just donated 1.5 years of my full and unpaid working time to the open source community with this :)
  - PudgePacket 7y ago
    Is there a particular feature that this requires to work? Using Firefox so wondering what version I might expect to be able to use this.
    - tobiu 7y ago
      at this point, FF & Safari are falling behind, which is sad. The dist versions work there, but for the dev mode, they need to catch up. The biggest problem is, that FF & Safari do not support modules inside the worker scope at all (although it is inside the W3C specs for a very long time). On top of this, FF does not support dynamic imports (they recently changed the dynamic import detection from a parse time to a run time error => before this point even unreachable code broke it).
  - spankalee 7y ago
    There's no sample code, even on that page. It's difficult to see what this looks like.
    - tobiu 7y ago
      there are some examples & example apps inside the repo. i think the best example app to understand the mechanics at this point is the docs app: https://github.com/neomjs/neo/tree/dev/docs/app/view https://github.com/neomjs/neo/tree/dev/docs/app/view (e.g. look into the MainContainer & the matching controller)
- tobiu 7y ago
  Important: at this point the examples are intended for desktop browsers. Mobile support is on my todo list, but will take some time.
lainga 7y ago
What drew you to mjs?
- tobiu 7y ago
  You mean the file name extension .mjs? If so: https://medium.com/passpill-project/files-with-mjs-extension-for-javascript-modules-ced195d7c84a https://medium.com/passpill-project/files-with-mjs-extension... It got popular in nodejs first to name files containing JS modules .mjs, but it starting to get a standard inside browsers as well. You can find a lot more references in case you google for it, e.g.: https://dev.to/saigowthamr/js-modules-are-now-supporting-in-browsers-13fn https://dev.to/saigowthamr/js-modules-are-now-supporting-in-... Best regards Tobias
  - spankalee 7y ago
    | but it starting to get a standard inside browsers as well Browsers don't care about the file extension, just the mime-type. Node supports modules with any extension now as well. I wouldn't use .mjs, it causes lots of problems.
    - tobiu 7y ago
      in case it does cause problems, it would be very easy to change the file names. the dist versions do use .js files, since webpack compiled modules are not real ones. feel free to open a ticket inside the issues tracker with more input about the problems and i will look into it.
  - mrspeaker 7y ago
    I thought (hoped!) that `mjs` was just a hack that node used to get around the fact they couldn't do native javascript modules with .js extensions nicely - but (with --experimental-modules for now, but default eventually) the `mjs` file extension hack should be gone forever soon (I thought!).
brianzelip 7y ago
Recent JS Party podcast episode about ES modules, https://changelog.com/jsparty/106 https://changelog.com/jsparty/106
vsskanth 7y ago
Tried this out on an underpowered mobile device. Layout doesn't adapt properly to mobile (as warned) but is insanely fast to render and responsive. Great work!
taf2 7y ago
Seems the live demos all appear as blank white pages on iOS
- tobiu 7y ago
  please see the comment below: "Important: at this point the examples are intended for desktop browsers. Mobile support is on my todo list, but will take some time."
  - deleted 7y ago
    [deleted]
mind-blight 7y ago
It's a really cool idea. Where is this currently being used, and what motivated you to develop it?
- tobiu 7y ago
  It is not used in production yet (the repo just went online on Nov. 23rd). This will change soon though. I am not officially allowed to talk about it yet, but if you look at my linked in profile, you might get an idea. The motivation part would be a long story :)
  - pmontra 7y ago
    > This will change soon though This brings us to the roadmap of Neo and to when we can be sure that our customers can use our sites written in Neo. What I see now is "For the best user experience, you need to use Google Chrome with the following browser flag: chrome://flags/#enable-experimental-web-platform-features". Maybe this means that we should only wait for Chrome 80+ to be on most desktops. Firefox: all I got there is a number of "SyntaxError: import declarations may only appear at top level of a module". Which version of Firefox do we have to wait for? Safari: I don't own any device from Apple but a number of my customers do. I wonder if Neo works there. Other browsers: I assume that all the chromium based browsers are going to be covered by the compatibility with Chrome 80. Mobile: "The online demos are not optimised for mobile yet, please use a desktop browser!" Is it only a matter of CSS or is there something about webworkers on those platforms?
    - tobiu 7y ago
      Let me shed some light into this: Chrome 80 will most likely get released in January, since Chrome Canary already no longer needs the flag. You can run the dist/development and dist/production versions of neo inside FF & Safari right now, the performance should be close. Having 1 browser which fully supports it is enough for a great debugging experience. Obviously it would be nice if other browsers do catch up. Mobile: I need to add support for touch events inside the main thread, which should be easy. On my todo list after the real world 2 app is done (want to focus on this one first, since it is meant to be a good starting point for new devs to get up to speed). The multithreading performance will be amazing on mobile.
cheez 7y ago
This is not exactly relevant to the post and is a bit selfish but... I'd like some feedback. Things like things I have invented in the past (before they were public): - React - Redux - This thing - Various other things In fact, I wrote a UI framework that runs in Web Workers which does React+Redux better than React+Redux. Redux is terrible for real-time work, whereas my framework combined beautifully for real-time work. As real-time as you can get in the browser anyway. And I could throttle FPS perfectly as a result. I know I'm not the only one who creates these things, and I know I'm onto something usually because the "old guard" generally are terrified of this new thing that I built. I am old. And I think I am probably wrong when inventing things which terrify other people but I'd like to figure out how to find a more... amenable audience, not just in my work, which is mostly independent now. How do I find people who see possibilities? Should I be talking about these things at meetups? How do things go from my own personal products/projects to being posted on HN?
- colordrops 7y ago
  I was also in a situation at work where I found that redux did not work great for real-time code. Have you made your solution public? Also related to this article, webworkers are great for offloading work from the main thread until you've got high data rates. It doesn't take a lot of data to get to the point where serialization across the worker boundary nullifies the performance gains of moving the work off of the main thread.
  - cheez 7y ago
    Nothing is public. Regarding your comment about serialization: that's why I used websockets in the workers. It went pretty well except there was a bug in Chrome where the websocket in the webworker was still subject to the main loop. Something like that. Anyway, the point of offloading everything to webworkers was to make sure that the main thread is free for rendering. So there was very little to serialize, aside from dom differences which are generally not significant.
    - colordrops 7y ago
throwGuardian 7y ago
How does this compare to worker-dom [1]? Per worker-dom, one can reuse popular frameworks (React, Vue, Preact, ...) and simply move the [framework+app] code to a worker thread. [1]: https://github.com/ampproject/worker-dom https://github.com/ampproject/worker-dom
- tobiu 7y ago
  To be honest, I have not looked at this project yet. In neo.mjs, there is an app worker which contains most parts of the framework and your apps (can be more than 1). The vdom comparison happens inside the vdom worker (which mostly makes sense in case there is a lot going on inside the app thread). The mostly idle main thread applies the deltas. The vdom itself is very different to other frameworks, since it is JSON based. neo.mjs is not using any templates at all, which boosts the performance a lot.
equalunique 7y ago
Any examples that work in Firefox?
- subscope 7y ago
  https://news.ycombinator.com/item?id=21788587 https://news.ycombinator.com/item?id=21788587
mr_sunshine02 7y ago
I had the chance to get in touch and try neo.mjs quite early so here are some points I like so far: * the config system + setter getter and update functions * framework code readability, clean code with comments with nicely formatted and readable * cutting edge feature support - it’s refreshing to work and play with ES8, multiple web workers, etc. (you know that most buisness projects are not cutting edge ;)) * support - @tobiu was/is super responsive and helpful with my questions when get started
ibrahimcesar 7y ago
Great idea! But if you have to use 'chrome://flags/#enable-experimental-web-platform-features' it is not a "Real World App" yet.
- mr_sunshine02 7y ago
  The flag is required until Chrome v80 (https://bugs.chromium.org/p/chromium/issues/detail?id=680046 https://bugs.chromium.org/p/chromium/issues/detail?id=680046) So soon you do not need the flag anymore.
  - underwater 7y ago
    There are browsers that aren't Chrome.
    - tobiu 7y ago
      scroll down on the example page please: the dist/development & dist/production versions do work in other browsers and do not need a flag.
nicoburns 7y ago
> the main thread would be mostly idle, only applying the real dom manipulations, so there are no background tasks slowing it down? The thing is, applying DOM updates is the biggest bottleneck in almost every frontend app. And this doesn't sound like it solves that.
- tobiu 7y ago
  it definitely is the bottleneck, which is the reason we should move all other possible tasks out of main. in this (neo.mjs) case main applies the deltas, forwards dom events to the app worker & serves as a message bus as long as workers can not directly communicate. nothing more.
FredricBerling 7y ago
This is just awesome. Love the simplicity with the config system and the performance is crazy fast.
czei002 7y ago
It sounds like a very good idea! However, on Linux in Firefox as well as in Chrome the UI (helix) doesn't seem to be very responsive, i.e. the slider is jittering making it feel very sluggish. Is that a bug? However, I see multiple cores being utilized. Same on mobile... I don't really buy the template argument. Think declarative layouts such as QML, React, etc. are there for a reason... Why focus that much on mjs? Wouldn't you use Typescript anyway? i.e. you still have source map (beside I never had problems with source maps)
- tobiu 7y ago
  Hi czei002, did you try using the mouse-wheel? (scrollY does zoom, srollX rotates). please let me know in case the performance doing so is not nice. so far neo.mjs is just using input type="range" for sliders, which are ok-ish on MacOS. real sliders are on my todo list, but to implement them i need to create drag and drop first. this one is an epic, since drag happens inside the main thread while the handlers live within the app worker. i will update the vision file today to shed some light into what is coming next. the template discussion is a big one :) you could argument that most APIs were XML 5+ years ago and now close to all are JSON based. imo writing string based markups is a legacy thing which should get replaced. think about it this way: to compare virtual dom and get the deltas, vdom structures have to be json based (js objects & arrays). in case you write markup strings, they need to get converted into JSON, which is expensive. you could argument now, that those replacements can be done as a build process, which is true if you want to limit your components to just a few states. imagine you would create the helix using states and how many templates you would need => there would be a massive overhead to load all those parsed templates. neo.mjs goes one step further: you can not just define your markup as JSON, but this structure(s) are persistent throughout the component lifecycle. meaning you can change them the same way before & after a component gets mounted. the whole scoping madness including functions or variables into strings just does not exist, which can save a lot of time. also, the part where you put a component based tag into a string based template which automatically creates a matching JS instance does not exist, which makes it very convenient to re-use the same components (think about a list with component based items). i would use TS in a heartbeat if browsers would support it out of the box. one major design goal of neo.mjs is to not have any JS related build processes for the dev mode. the benefit to debug the real code should be obvious (transpiling code can create bugs).
tobiu 7y ago
I still owe you the project vision. There we go: https://github.com/neomjs/neo/blob/dev/.github/VISION.md https://github.com/neomjs/neo/blob/dev/.github/VISION.md
tobiu 7y ago
A quick heads up: Working on the "neo-app" package and planning to get it done by January 2nd. Then you can create new neo.mjs apps with a 1-liner npx script.

50 points by tobiu 7y ago

jitl 7y ago

No example in READE - sad!

tobiu 7y ago
Actually there is a link to the online examples at the top of the readme: https://neomjs.github.io/pages/ https://neomjs.github.io/pages/ This is a new paradigm: you can now include JS modules directly into workers inside the browser. This will be fully supported in Chrome 80 (already works in canary). The concept makes debugging extremely convenient, since you get the real code without source-maps and the multi-threading gives a relly nice performance. I just donated 1.5 years of my full and unpaid working time to the open source community with this :)
- PudgePacket 7y ago
  Is there a particular feature that this requires to work? Using Firefox so wondering what version I might expect to be able to use this.
  - tobiu 7y ago
    at this point, FF & Safari are falling behind, which is sad. The dist versions work there, but for the dev mode, they need to catch up. The biggest problem is, that FF & Safari do not support modules inside the worker scope at all (although it is inside the W3C specs for a very long time). On top of this, FF does not support dynamic imports (they recently changed the dynamic import detection from a parse time to a run time error => before this point even unreachable code broke it).
- spankalee 7y ago
  There's no sample code, even on that page. It's difficult to see what this looks like.
  - tobiu 7y ago
    there are some examples & example apps inside the repo. i think the best example app to understand the mechanics at this point is the docs app: https://github.com/neomjs/neo/tree/dev/docs/app/view https://github.com/neomjs/neo/tree/dev/docs/app/view (e.g. look into the MainContainer & the matching controller)
tobiu 7y ago
Important: at this point the examples are intended for desktop browsers. Mobile support is on my todo list, but will take some time.

lainga 7y ago

What drew you to mjs?

tobiu 7y ago
You mean the file name extension .mjs? If so: https://medium.com/passpill-project/files-with-mjs-extension-for-javascript-modules-ced195d7c84a https://medium.com/passpill-project/files-with-mjs-extension... It got popular in nodejs first to name files containing JS modules .mjs, but it starting to get a standard inside browsers as well. You can find a lot more references in case you google for it, e.g.: https://dev.to/saigowthamr/js-modules-are-now-supporting-in-browsers-13fn https://dev.to/saigowthamr/js-modules-are-now-supporting-in-... Best regards Tobias
- spankalee 7y ago
  | but it starting to get a standard inside browsers as well Browsers don't care about the file extension, just the mime-type. Node supports modules with any extension now as well. I wouldn't use .mjs, it causes lots of problems.
  - tobiu 7y ago
    in case it does cause problems, it would be very easy to change the file names. the dist versions do use .js files, since webpack compiled modules are not real ones. feel free to open a ticket inside the issues tracker with more input about the problems and i will look into it.
- mrspeaker 7y ago
  I thought (hoped!) that `mjs` was just a hack that node used to get around the fact they couldn't do native javascript modules with .js extensions nicely - but (with --experimental-modules for now, but default eventually) the `mjs` file extension hack should be gone forever soon (I thought!).

brianzelip 7y ago

Recent JS Party podcast episode about ES modules, https://changelog.com/jsparty/106 https://changelog.com/jsparty/106

vsskanth 7y ago

Tried this out on an underpowered mobile device. Layout doesn't adapt properly to mobile (as warned) but is insanely fast to render and responsive. Great work!

taf2 7y ago

Seems the live demos all appear as blank white pages on iOS

tobiu 7y ago
please see the comment below: "Important: at this point the examples are intended for desktop browsers. Mobile support is on my todo list, but will take some time."
- deleted 7y ago
  [deleted]

mind-blight 7y ago

It's a really cool idea. Where is this currently being used, and what motivated you to develop it?

tobiu 7y ago
It is not used in production yet (the repo just went online on Nov. 23rd). This will change soon though. I am not officially allowed to talk about it yet, but if you look at my linked in profile, you might get an idea. The motivation part would be a long story :)
- pmontra 7y ago
  > This will change soon though This brings us to the roadmap of Neo and to when we can be sure that our customers can use our sites written in Neo. What I see now is "For the best user experience, you need to use Google Chrome with the following browser flag: chrome://flags/#enable-experimental-web-platform-features". Maybe this means that we should only wait for Chrome 80+ to be on most desktops. Firefox: all I got there is a number of "SyntaxError: import declarations may only appear at top level of a module". Which version of Firefox do we have to wait for? Safari: I don't own any device from Apple but a number of my customers do. I wonder if Neo works there. Other browsers: I assume that all the chromium based browsers are going to be covered by the compatibility with Chrome 80. Mobile: "The online demos are not optimised for mobile yet, please use a desktop browser!" Is it only a matter of CSS or is there something about webworkers on those platforms?
  - tobiu 7y ago
    Let me shed some light into this: Chrome 80 will most likely get released in January, since Chrome Canary already no longer needs the flag. You can run the dist/development and dist/production versions of neo inside FF & Safari right now, the performance should be close. Having 1 browser which fully supports it is enough for a great debugging experience. Obviously it would be nice if other browsers do catch up. Mobile: I need to add support for touch events inside the main thread, which should be easy. On my todo list after the real world 2 app is done (want to focus on this one first, since it is meant to be a good starting point for new devs to get up to speed). The multithreading performance will be amazing on mobile.

cheez 7y ago

This is not exactly relevant to the post and is a bit selfish but... I'd like some feedback. Things like things I have invented in the past (before they were public): - React - Redux - This thing - Various other things In fact, I wrote a UI framework that runs in Web Workers which does React+Redux better than React+Redux. Redux is terrible for real-time work, whereas my framework combined beautifully for real-time work. As real-time as you can get in the browser anyway. And I could throttle FPS perfectly as a result. I know I'm not the only one who creates these things, and I know I'm onto something usually because the "old guard" generally are terrified of this new thing that I built. I am old. And I think I am probably wrong when inventing things which terrify other people but I'd like to figure out how to find a more... amenable audience, not just in my work, which is mostly independent now. How do I find people who see possibilities? Should I be talking about these things at meetups? How do things go from my own personal products/projects to being posted on HN?

colordrops 7y ago
I was also in a situation at work where I found that redux did not work great for real-time code. Have you made your solution public? Also related to this article, webworkers are great for offloading work from the main thread until you've got high data rates. It doesn't take a lot of data to get to the point where serialization across the worker boundary nullifies the performance gains of moving the work off of the main thread.
- cheez 7y ago
  Nothing is public. Regarding your comment about serialization: that's why I used websockets in the workers. It went pretty well except there was a bug in Chrome where the websocket in the webworker was still subject to the main loop. Something like that. Anyway, the point of offloading everything to webworkers was to make sure that the main thread is free for rendering. So there was very little to serialize, aside from dom differences which are generally not significant.
  - colordrops 7y ago

throwGuardian 7y ago

How does this compare to worker-dom [1]? Per worker-dom, one can reuse popular frameworks (React, Vue, Preact, ...) and simply move the [framework+app] code to a worker thread. [1]: https://github.com/ampproject/worker-dom https://github.com/ampproject/worker-dom

tobiu 7y ago
To be honest, I have not looked at this project yet. In neo.mjs, there is an app worker which contains most parts of the framework and your apps (can be more than 1). The vdom comparison happens inside the vdom worker (which mostly makes sense in case there is a lot going on inside the app thread). The mostly idle main thread applies the deltas. The vdom itself is very different to other frameworks, since it is JSON based. neo.mjs is not using any templates at all, which boosts the performance a lot.

equalunique 7y ago

Any examples that work in Firefox?

subscope 7y ago
https://news.ycombinator.com/item?id=21788587 https://news.ycombinator.com/item?id=21788587

mr_sunshine02 7y ago

I had the chance to get in touch and try neo.mjs quite early so here are some points I like so far: * the config system + setter getter and update functions * framework code readability, clean code with comments with nicely formatted and readable * cutting edge feature support - it’s refreshing to work and play with ES8, multiple web workers, etc. (you know that most buisness projects are not cutting edge ;)) * support - @tobiu was/is super responsive and helpful with my questions when get started

ibrahimcesar 7y ago

Great idea! But if you have to use 'chrome://flags/#enable-experimental-web-platform-features' it is not a "Real World App" yet.

mr_sunshine02 7y ago
The flag is required until Chrome v80 (https://bugs.chromium.org/p/chromium/issues/detail?id=680046 https://bugs.chromium.org/p/chromium/issues/detail?id=680046) So soon you do not need the flag anymore.
- underwater 7y ago
  There are browsers that aren't Chrome.
  - tobiu 7y ago
    scroll down on the example page please: the dist/development & dist/production versions do work in other browsers and do not need a flag.

nicoburns 7y ago

> the main thread would be mostly idle, only applying the real dom manipulations, so there are no background tasks slowing it down? The thing is, applying DOM updates is the biggest bottleneck in almost every frontend app. And this doesn't sound like it solves that.

tobiu 7y ago
it definitely is the bottleneck, which is the reason we should move all other possible tasks out of main. in this (neo.mjs) case main applies the deltas, forwards dom events to the app worker & serves as a message bus as long as workers can not directly communicate. nothing more.

FredricBerling 7y ago

This is just awesome. Love the simplicity with the config system and the performance is crazy fast.

czei002 7y ago

It sounds like a very good idea! However, on Linux in Firefox as well as in Chrome the UI (helix) doesn't seem to be very responsive, i.e. the slider is jittering making it feel very sluggish. Is that a bug? However, I see multiple cores being utilized. Same on mobile... I don't really buy the template argument. Think declarative layouts such as QML, React, etc. are there for a reason... Why focus that much on mjs? Wouldn't you use Typescript anyway? i.e. you still have source map (beside I never had problems with source maps)

tobiu 7y ago
Hi czei002, did you try using the mouse-wheel? (scrollY does zoom, srollX rotates). please let me know in case the performance doing so is not nice. so far neo.mjs is just using input type="range" for sliders, which are ok-ish on MacOS. real sliders are on my todo list, but to implement them i need to create drag and drop first. this one is an epic, since drag happens inside the main thread while the handlers live within the app worker. i will update the vision file today to shed some light into what is coming next. the template discussion is a big one :) you could argument that most APIs were XML 5+ years ago and now close to all are JSON based. imo writing string based markups is a legacy thing which should get replaced. think about it this way: to compare virtual dom and get the deltas, vdom structures have to be json based (js objects & arrays). in case you write markup strings, they need to get converted into JSON, which is expensive. you could argument now, that those replacements can be done as a build process, which is true if you want to limit your components to just a few states. imagine you would create the helix using states and how many templates you would need => there would be a massive overhead to load all those parsed templates. neo.mjs goes one step further: you can not just define your markup as JSON, but this structure(s) are persistent throughout the component lifecycle. meaning you can change them the same way before & after a component gets mounted. the whole scoping madness including functions or variables into strings just does not exist, which can save a lot of time. also, the part where you put a component based tag into a string based template which automatically creates a matching JS instance does not exist, which makes it very convenient to re-use the same components (think about a list with component based items). i would use TS in a heartbeat if browsers would support it out of the box. one major design goal of neo.mjs is to not have any JS related build processes for the dev mode. the benefit to debug the real code should be obvious (transpiling code can create bugs).

tobiu 7y ago

I still owe you the project vision. There we go: https://github.com/neomjs/neo/blob/dev/.github/VISION.md https://github.com/neomjs/neo/blob/dev/.github/VISION.md

tobiu 7y ago

A quick heads up: Working on the "neo-app" package and planning to get it done by January 2nd. Then you can create new neo.mjs apps with a 1-liner npx script.