Show HN: Electron/browser-free reactjs slack app (40M usage) | Hacker News Reader

Show HN: Electron/browser-free reactjs slack app (40M usage)

github.com

9 pointscztomsik11 comments

While I love the idea behind it, this is based on Servo's WebRender, which is not at all ready to handle anything more than toy web pages. So applications built using this are going to have to have very simple UI.

I really do wish Mozilla would put more resources into making Webrender on par with Gecko/Webkit/Blink. There is a huge market for light weight, embeddable, rendering engines.

Hear hear! I don’t understand why Mozilla doesn’t prioritize this. Surely they have the devs to do it.

webrender is already enabled in firefox nightly so I wouldn't say it's just for toy pages

also, it's more like skia, a low-level "drawing" thing, on which gecko/servo (engines) depend on - and webkit/blink could too (in theory)

and finally, this project has nothing to do with webpages, it's about being able to quickly develop GUI applications using familiar technologies.

1. it's node.js library so you can use anything from npm and you can use any nodejs tools, debuggers, profilers, etc. 2. you can use react & react libraries/devtools (vue in future) 3. there's flexbox 4. subset of css (no cascading & there will be some minor differences) 5. hot-reload

so I would put this somewhere between electron & flutter

I'm sorry, I assumed web-render was the complete rendering engine behind Servo and was a Gecko equivalent. But my point still stands. A major convenience with Electron is that, if it runs on Chrome, it runs on Electron and pretty much everything runs on Chrome, so I don't have to spend a lot of time figuring out work arounds for things not supported by the rendering engine. And the 'subset' of CSS alone would be reason enough to not pick web render.

I do apologize if this appears as bashing your project, it really is not, and I'm sure going to spend a few weekends pushing it's limits, but I'm just super frustrated with the state of embeddable web rendering engines on the desktop, and my comments are mostly directed towards Servo and Web-render.

the point of this project is not to "turn this webapp into a cross-platform gui app" (electron is really good at this and I think this is where we agree)

it's more like: - let me make a cross-platform gui app really quickly (hot-reload) - without having to learn a ton of new APIs (so I can reuse most of my css + javascript + react knowledge & tools) - without overhead of web platform (DOM, lots of APIs, custom elements, shadow dom, paintlets, audio, video, geo, battery, ...) - while still being able to use any package from npm

I completely understand why you are skeptic, but if people are interested in flutter, I think they should be interested in this too (if not more). No offense taken, I'm glad for your feedback.

BTW: subset of css) this is rather about cascading (css-in-js vs. real css with global classes, etc.) html) major motivation here is "what if we could do webapps without dom?" like that we are using frameworks anyway (react/vue/...) and basically all applications are now built using components so what if we could send shapes directly to GPU?

So it's not about being able to reuse everything, but it's about being as much familiar as possible, instead of reinventing everything (like flutter does)

With regards Flutter, keen to see it come to the desktop, there are some experiments. https://github.com/Norbert515/flutter_ide

time will tell but I have really hard time understanding why they couldn't just use any already established platform (tools, libs, tutorials, books, common knowledge, stackoverflow, ...)

+google is famous for killing its projects and technologies really often so I'll wait for a while before hopping on this train

The chrome guys who started the sky experiment, now flutter, used JavaScript for the first few iterations. I think they went with Dart because they were able to get the Dart GC customised for flutter. The big feature that the Flutter team got from Dart, that they didn't know they wanted, was stateful hot reload.

Seems being able to build UIs with hot reload feature is a winner.

Norbert's experiment, looking at building an editor in flutter, looks very cool. As he says it a lot of work building everything from scratch, but starting with a widget editor is a cool idea.

The concept, in flutter, of every thing being a widget, even the app itself, is very powerful.

I agree, time will tell, with people like Norbert, who are outside of google, I'm interested to see what they and Google do with flutter this year.

yeah, but stateful hot-reload is also possible with react and other frameworks so this is hardly a thing against javascript.

while i love alternate slack client, Wey is looking much more promising

https://github.com/yue/wey

wey was inspiration for this - but mind this was done in one day and the intent was more about showing what's possible with node-webrender :-)

Reply on news.ycombinator.com