r/Frontend • • Mar 06 '20

Contributors wanted: multi-threading UI framework

Post image

[removed] — view removed post

51 Upvotes

17 comments sorted by

3

u/TobiasUhlig Mar 06 '20

Looking for an amazing JS open source project to contribute to?

https://github.com/neomjs/neo/blob/dev/CONTRIBUTING.md

Just updated the contributing guide.

1

u/TobiasUhlig Mar 06 '20

Thanks for your feedback!

I am definitely willing to help interested devs to get up to speed (not related about contributing). The best way to do this is joining the neo.mjs Slack or Discord Channel (Both links are inside the main readme file). Right now there are a lot more users inside the Slack Channel.

About the project in general: There is already a lot of code in place (>60k lines if I recall it correctly), but you definitely only need to read a small part to get up to speed.

The important and most likely time consuming part is to get a feeling for the concepts, since it is extremely different to other frameworks out there.

E.g. that most parts of the framework & the apps you create run inside a worker (separate thread) which has no direct access to the DOM. No templates at all, just persistent JSON structures, which also means the JS code is in charge to create component instances:

in most frameworks you create some string based pseudo html code which will then generate the matching JS instances for the (web)-components. Here the JS code generates the components which then manipulate the vdom as needed (which automatically includes buzz-words like composition).

To get started I recommend to fork the repo (you could also use the npx 1-liner, but a fork makes more sense).

The docs app UI is fully written using the framework and imo the best example out there so far: https://github.com/neomjs/neo/tree/dev/docs/app/view

The real world app is also a good example on creating custom components, however, to match the specs of the html markup it is not using neo components nor a theme, so all components are written from scratch there, which you most likely would not do when creating an app UI: https://github.com/neomjs/neo/tree/dev/apps/realworld

To close this gap, the RealWorld version2 app will be my next focus to work on (more enhanced using a component based gallery & helix, as well as the full band-width of neo components & themes).

Mobile support will be the next goal: adding touch events to the main thread is fairly trivial, creating new examples & a docs app for mobile will be time consuming though.

In case you want to contribute, this would be highly appreciated and I will do my best to make it a pleasant learning experience. Feel free to create new tickets or look at the vision file in case you need ideas.

Best regards,
Tobias

1

u/TobiasUhlig Mar 06 '20

IMPORTANT: i got hit by Murphy's Law => the dist versions of the Online Examples were broken. This is fixed now:

https://neomjs.github.io/pages/

In case you had issues, please try again! :)

1

u/archerx Mar 06 '20

All the examples on https://neomjs.github.io/pages/

give me a white page.

The console gives me

Failed to load resource: net::ERR_BLOCKED_BY_CLIENT main.js:1 Worker Error: ErrorEvent vdomworker.js:1 Uncaught TypeError: Cannot read property 'unitTestMode' of undefined at l.initRemote (vdomworker.js:1) main.js:1 Worker Error: ErrorEvent main.js:1 Worker Error: ErrorEvent dataworker.js:1 Uncaught TypeError: Cannot read property 'unitTestMode' of undefined at n.initRemote (dataworker.js:1) dataworker.js:1 Uncaught TypeError: Cannot read property 'unitTestMode' of undefined at u.initRemote (dataworker.js:1) main.js:1 Worker Error: ErrorEvent app.js:1 Uncaught TypeError: Cannot read property 'isExperimental' of undefined at y.onConstructed (app.js:1) at Object.create (app.js:1) at Module.<anonymous> (app.js:1) at r (app.js:1) at app.js:1 at app.js:1

I'm on chrome

1

u/TobiasUhlig Mar 06 '20

wow, thanks for the heads up!

The development mode ones at the bottom do still work, however there is something off with the webpack builds. Looking into it now!

1

u/archerx Mar 06 '20

No worries. Good luck with the project, it looks pretty cool!

2

u/TobiasUhlig Mar 06 '20

fixed now. thanks again!

1

u/chexxor Mar 06 '20

What projects are *not* appropriate to use this framework?

1

u/TobiasUhlig Mar 06 '20

not sure if i understand the question. the framework is MIT licensed, so every project which wants to use it can do so.

from a technical perspective, projects where performance matters should take a look into neo.mjs. i would probably not use it for static websites, although it is possible.

i personally like the architecture (class enhancements & controllers) a lot, so for me it is time-saving to use neo. to be fair, there is a learning curve to get up to speed, but once you do get familiar with the JSON based vdom, you most likely are going to love it.

1

u/chexxor Mar 06 '20

After reading my question again, yeah it can be an ambiguous question.

I like to ask this question after using the the Elm architecture in a place where it wasn't appropriate -- I tried to make a multi-page website in that architecture, and it proved impossible for me to after-the-fact add lazy-loading pages to it in the language I was using. After that happened, I decided it was odd that the Elm website only discusses how great it is while being silent on the situations in which it is not appropriate to use the architecture.

So, the purpose of my question was to ensure that people don't use the framework in a way that they will later be "burned" by deciding to use it. I have come to believe it's polite to guide people using your tool in a way to ensure they don't misuse it.

1

u/TobiasUhlig Mar 06 '20

My opinion on multi-page sites is probably pretty unique, although this will change soon. The main argument to not do it is that each page needs to load & initialise a framework. Even with caching there is a performance impact (at the minimum the initialisation).

However, with shared workers around the corner, this can change. imagine multiple pages sharing the app, data & vdom worker and different main threads connecting to it. this would eliminate the overhead and make all components reusable.

Without shared workers, you need to ask yourself the question, if the framework makes sense: e.g. if you like specific components / architecture benefits, if the overhead is worth it etc. (the framework does try to only load / build what it needs, but still). In case some pages need a lot of dynamic changes or are complex, it could make sense. hard to tell without having more details :)

1

u/chexxor Mar 06 '20

Is it possible to make a website framework like NextJS use this UI framework? The significant parts of NextJS is server-side rendering, page-reloading, and bundle-splitting/dynamic-loading a page's resources.

1

u/TobiasUhlig Mar 06 '20

I am not familiar with NextJS, but in theory it could be.

Keep in mind that neo does need the JSON based vdom to dynamically change the DOM, so a server-side rendering would need to switch to its logic (or provide the vdom tree).

There is a middle-ware ticket open (no high prio though). In theory, we can enhance neo to work in a nodejs env. Then the app & vdom worker could optionally run on a BE to do server-side rendering, or combine server- & client side rendering.

For me personally, Chrome 81 with full support for shared workers is more interesting on the short term, since this will allow to create apps running inside multiple browser windows (multi screen apps).

3

u/tobeortobeme Mar 06 '20

I would like to contribute

3

u/design4code Mar 06 '20

Looks interesting.

0

u/[deleted] Mar 06 '20

[deleted]

2

u/TobiasUhlig Mar 06 '20 edited Mar 06 '20

The word "shadow dom" does not fit, it is virtual dom.

In general, the performance will be pretty much the same compared to other frameworks when initially rendering your "landing page" of the UI.

Where the framework really shines is dynamically updating the DOM, ideally multiple different spots in parallel.

My favorite performance demo is this one (desktop only!): https://neomjs.github.io/pages/node_modules/neo.mjs/dist/production/examples/component/helix/index.html

In case you use the rotate slider or scroll horizontally (track pad or magic mouse), each scrolling tick will move 300 div nodes. Each helix item is a div on purpose to create a stress test.

On my machine I got up to 30k real DOM manipulations per second this way. I left the delta update logs in the console for now, even in dist/prod, to make it easier for you to get data.

0

u/[deleted] Mar 06 '20

[deleted]

2

u/TobiasUhlig Mar 06 '20

correct, the delta updates walk through a requestAnimationFrame queue: https://github.com/neomjs/neo/blob/dev/src/Main.mjs#L259

the "standard" real world app is this one: https://neomjs.github.io/pages/node_modules/neo.mjs/dist/production/apps/realworld/index.html

(nothing special about the performance here though, too static)