nice one!
HN user
tobiu
nice one!
The story just got published by ITNEXT.
Make sure to watch the demo video. The open source implementation is very easy to use and can improve the UX of your web based apps.
done.
you can now drag&drop in desktop and mobile envs. in case you use chrome to toggle the modes, please make sure to reload the page.
same url.
almost done with drag&drop for touch: https://youtu.be/tJxyxMyqR9E
For those of you reading this on mobile and still want to get an idea:
Also feel free to try drag&drop inside the calendar demo.
Desktop only as well (until the TouchSensor is ready) and still work in progress:
https://neomjs.github.io/pages/node_modules/neo.mjs/dist/pro...
You can only drag events inside the week view into valid states.
Once the TouchSensor is done, I will create a demo for multi screen drag&drop (dragging an in app dialog from one browser window into another).
A blog post will follow.
background info:
the demo app is located inside the App Worker.
the drag events get triggered in main, while the handlers live within the App Worker scope.
I was sceptical at first, how the performance for a custom drag&drop implementation would work out.
Best to use Chrome (some polishing left for FF & Safari).
The TouchSensor is next on my todo list.
You can find the code here:
https://github.com/neomjs/neo/blob/dev/src/main/addon/DragDr...
The project is deeply inspired by the Google Calendar as well as the native MacOS Calendar.
This is a very early preview version: I started this project a week ago, so please don't expect it to be functional yet. I think it will take 2-3 more weeks to get finished.
Based on neo.mjs, it is multithreaded out of the box.
What you can do already:
Switch the theme.
Open the Settings Container, change settings for the weekly view. Ideally with the Weekly View as the active Card to see the delta updates.
I will add infinite scrolling for all views soon (similar to the DateSelector at the top left).
Drag & Drop for Events, mobile support and creating, editing & removing Events are on the todo list.
You can take a look into the source code here:
https://github.com/neomjs/neo/tree/dev/src/calendar
The Calendar is already pretty extensible & configurable, will add more options on the way.
Feedback appreciated!
Thx & best regards, Tobias
I actually hope that some of the ideas get picked up. Might be naive.
Getting visibility / traction for a new OS project is intense these days, especially in case it is "disruptive". Might be too far ahead.
"They're out there and I suspect it would be more enjoyable to work for them". Probably, but hard to find. Most job requests are like "Would you like to help us with Angular, React or Vue?".
"Author says that he is humble but he is not humble enough"
I have been thinking about this part while writing it :)
It actually did not feel comfortable to write this much about myself. Thought it was important though to put the article into perspective.
I normally would not even apply for big company roles, because most of the time you get stuck in roles where it is close to impossible to make an impact.
Agree on the Zen part.
There are around 25 transitions in place when reducing the width < 600px or the height < 400px, to make it feel more natural.
Not fully functional yet (making it responsive is on my todo list).
The website is a neo app as well => mulithreaded => running inside a webworker.
Just got selected by Medium into Javascript & published by "The Startup".
Definitely a new way to create Apps, including complex components, view controllers, routing etc.
Feedback appreciated!
As an entirely free to use open source project, it relies on your input.
I just started to define the scope of the next minor release and your feedback is not just only welcome, but makes a big impact on the current roadmap.
So, what would you like to see next?
for the default tap event, this sounds right.
for "longtap" we probably have to stick to touchstart & end though. not sure about doubletap yet.
I should have phrased it like: "by default neo.mjs is using global listeners" => you can add local listeners as well if you want to.
regarding safari: https://caniuse.com/#search=worker
workers are supported, so the dist versions not using shared workers can run there already.
2 missing items on the webkit side:
1) adding support for shared workers (they dropped the development on those, but recently put it into "inRadar" again. So there is hope.
2) adding support for JS modules inside the worker scope. missing in FF as well. not too bad, since it is good enough in case 1 browser can do it (chrome) so that the dev mode can run there. the dist versions will run in FF, safari & chrome, since webpack is replacing all import statements, so that there are no real JS modules.
to fully support mobile, neo.mjs still needs to support touch events (similar to hammer js). on the todo list.
Published by "The Startup" and selected by Medium into Javascript, SoftwareEngineering & Programming.
200 upvotes on Reddit (Programming Sub).
Completely fell under the radar here =/
This is a friends link.
Feedback appreciated!
this release includes:
Expanding Single Page Apps into multiple Browser Windows
Friends link: https://medium.com/swlh/expanding-single-page-apps-into-mult...
To be clear on this one:
The new architecture which enables you to to optionally use SharedWorkers (to create Apps running inside multiple Browser Widnows) is in place now.
The main readme got updated including the multi window covid app.
There are still more guides & tutorials missing.
There is still work left on the Component side of things.
Your help is appreciated!
Until now, this one is the story of my life time.
Your feedback would mean a lot to me!
Loading a framework just once for multiple Browser Windows.
Moving entire Component Trees around Windows (just the vdom, no new JS instances).
DomEvents still work out of the box (no need to add new listeners or modify existing ones).
Again: super early stage, not fully functional yet.
The version inside the video is not deployed to the online examples yet (will add it once ready). You can just clone the neomjs/neo repo and try it locally if you like to.
What I did was opening: https://github.com/neomjs/neo/tree/dev/apps/sharedcovid (index.html)
inside a first browser window and then opening: https://github.com/neomjs/neo/tree/dev/apps/sharedcovid2
inside the second window.
we could spawn new popup windows as well.
working on the dom event support next, after moving components around. it might be an easy fix just adjusting the appName config of the moved cmp tree, otherwise i need to look into the postMessages routing.
gutt feeling: 2-3 more days.
An early heads up about what I am working on inside the neo.mjs context.
Please do not confuse this with multi page apps. It is like a SPA, where multiple browser windows can connect to a shared app worker.
``` onAppConnect(name) { let me = this, view;
console.log('onAppConnect', name);
switch (name) {
case 'Covid2':
view = me.getReference('controls-panel');
Neo.getComponent(view.parentId).remove(view, false);
Neo.apps[name].on('render', () => {
setTimeout(() => {
Neo.apps[name].mainViewInstance.add(view);
}, 100);
});
}
}
```You will be able to move entire component tress into different windows. Without even needing to create new JS instances. As easy as this.
Please help creating an awareness for the Webkit team that we need SharedWorkers:
Mobile: Native shell with multiple WebViews.
To be clear: they dropped working on SharedWorkers on purpose and it won't happen unless smart devs like you add some weight on it.
Every(!) browser on iOS is using Webkit.
Scaling your "backends" inside the cloud, but ignoring
SCALABLE frontend architectures running directly inside your browser using javascript modules?!
Wake up!
SharedWorkers in Chrome using Javascript Modules, live demos (online examples), background infos & thoughts about a new era of UI architectures. Fully MIT licensed.
Published v1.2.5 on npm: https://neomjs.github.io/pages/
SharedWorkers examples are online. Dev mode: Chrome v83+ Webpack Dist versions: Chrome & Firefox(!)
Enjoy!
A release announcement will follow soon.
In Chrome: open the example, then open chrome://inspect/#workers
inside another tab to see the SharedWorkers. The webpack based dist version supporting Firefox is really impressive.
In FF, open a new tab and open: about:debugging#/runtime/this-firefox
Some ideas in general:
The article is about putting a framework & your Apps into a separate thread (calling this one App worker).
Now, with SharedWorkers being fully supported, we can connect multiple main threads to a shared App worker. This way Apps live within the same realm and can directly communicate. They even share the virtual dom, leading to really great possibilities (moving dom nodes from one App to another).
E.g. if you would like to create a multi screen trading App, there is a big potential to speed up things.
On mobile this could also get interesting: imagine a native App with multiple WebViews. Those could as well share code and communicate directly.
Even in case there is just one browser window, the default worker setup (non shared workers) can make an impact.