211–220 of 281 posts
How is it "light" weight? > Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program. 20MB!
I'm always a bit surprised there was the space for Electron to exist in the first place. Since most operating systems have widget toolkits that have browsers effectively embedded into them. What I would have liked to have seen instead of Electron would have been a shim API that abstracted OSX/iOS/WinForms/QT webviews, and for those webviews to have a working API that would allow DOM manipulation, and allowed native s…
You had to use JavaScript or VBScript but all the safety rails are off, this is pre-sand boxing, what do you mean websites might be malicious why would someone make one like that... you could do crazy things, and fully leverage windows APIs directly without much effort via VBScript, I once used the winforms(?) APIs to introspect field labels and names to automate the driving of multiple desktop apps from a crazy jquery and VBScript monstrosity. Made me twice as efficient at that job though so it was awesome.
You could control child iframes and pop up windows (remember these?) and VBScript let you shoehorn quite a bit of native UI type stuff whenever it was going to be easier than building something with simple forms, JavaScript, tables and frames. If you got really fancy you would Base64 some absurd binary into your app and unpack it on the fly with VBScript then call it from a temp directory in order to drive things like interacting with network services that didn’t have any sort of thing you could work with via HTML JavaScript and XMlHTTRequest (this was the very dawn of Ajax)
I'm always a bit surprised there was the space for Electron to exist in the first place. Since most operating systems have widget toolkits that have browsers effectively embedded into them. What I would have liked to have seen instead of Electron would have been a shim API that abstracted OSX/iOS/WinForms/QT webviews, and for those webviews to have a working API that would allow DOM manipulation, and allowed native s…
http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...
In any case you were still dependent on IE10/11 at the best, and certainly nothing as modern as the old Edge, much less the Chromium-based Edge. And on older Windows versions it completely depended on whether the user had upgraded IE.
You could write HTML/CSS/JS that was portable between IE10/11 and other native browsers, just as we all did in actual websites. I did this for Mac/Windows in the past and it worked, but it was fairly compelling for web developers to have a single browser version to target instead of the various incompatible native web views.
The situation is a bit different now, where you can get an Chromium Edge view on Windows 10 and a Safari view on Mac, but what do you get on Linux? I don't know.
Earlier quoted context omitted.
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
I wrote 3D visualization apps in 1998 using FLTK and OpenGL and the (statically linked) binary was less than 20 MB. I think my desktop had all of 64MB of RAM. It was snappier than a modern TODO app on Electron and far, far easier to write. What on earth have we done to ourselves?
Earlier quoted context omitted.
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
Emacs does those things too, these days. It's still snappier than anything else I've tried recently.
Another example is the Enlightenment window manager. It was considered a little heavy, but good looking. But because there was a large hiatus in development, it got "stuck in the past" and now, it is one of the lightest there is.
Earlier quoted context omitted.
Write code in vim with no/few plugins. Don't worry about getting the variable names right. Then move to your IDE to get it to compile. It's conceptually similar to sketching out the design of your code with a pen and paper or whiteboard. First write it quickly, then make it correct.
How is writing something in vim faster? You can have the same bindings in many IDEs.
This looks nice ! However... "Low CPU and memory footprint (...) memory usage is under 20 MB for a Hello World program" : I am the only one who still thinks this is huge ? (-> https://tonsky.me/blog/disenchantment )
Earlier quoted context omitted.
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
I bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
Earlier quoted context omitted.
Write code in vim with no/few plugins. Don't worry about getting the variable names right. Then move to your IDE to get it to compile. It's conceptually similar to sketching out the design of your code with a pen and paper or whiteboard. First write it quickly, then make it correct.
How is writing something in vim faster? You can have the same bindings in many IDEs.
Anyway, if you don't care about all that, you can get a similar effect by turning off intellisense (or equivalent) in your IDE while you write, then turn it back on at the end to get what you just wrote to compile. I do this sometimes in Android Studio.