
Show HN: Electron/browser-free reactjs slack app (40M usage) - cztomsik
https://github.com/cztomsik/slack-app
======
bgdam
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.

~~~
cztomsik
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

~~~
bgdam
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.

~~~
cztomsik
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)

~~~
sebe
With regards Flutter, keen to see it come to the desktop, there are some
experiments.
[https://github.com/Norbert515/flutter_ide](https://github.com/Norbert515/flutter_ide)

~~~
cztomsik
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

~~~
sebe
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.

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

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

[https://github.com/yue/wey](https://github.com/yue/wey)

~~~
cztomsik
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 :-)

