161–170 of 295 posts
Earlier quoted context omitted.
Anything that reduces the number of running chrome instances on my poor little laptop would be nice.
I tried out the example "Notepad" app in the git repo and it ran at 70MB. Is that good? I don't have any metrics about how much memory a hello world Electron app uses.
Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!
Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!
Isn't it running on Node?
> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…
It turns out it's really hard to get a UI Builder right with HTML/CSS. In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. For example, text getting longer pushes down content beneath it, while at the same time, the text might be 50% of it's parent node's width. The first constraint is bottom-up: the text node influences it's parent and sibling DOM node's geometry, while t…
Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!
How do you use JavaScriptCore with proton? It runs on node which uses v8. Resource measurements: The sample "Notepad" app (just a text box in a window, no copy/paste, etc.) uses 79 MB. For comparison the same app built using Xcode uses 27 MB, and TextEdit uses 40 MB.
Not that I'd be concerned about a few tens of MB nowadays but on the whole we're consuming computing resources at the same rate faster hardware is put out (Gates' law).
I have a Pentium 3 running NT4 sitting on the same desk and it is faster at many tasks than my i5 workstation. Visual Studio 6 especially is super snappy. How then can Slack, on a machine with an order of magnitude more processing power and 64 times (!) as much RAM lag when switching channels?
Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!
How do you use JavaScriptCore with proton? It runs on node which uses v8. Resource measurements: The sample "Notepad" app (just a text box in a window, no copy/paste, etc.) uses 79 MB. For comparison the same app built using Xcode uses 27 MB, and TextEdit uses 40 MB.
I'm curious how the documentation for this site was created. It resembles Vue.js and I really like it; would love to use a similar template for my projects.
Earlier quoted context omitted.
How do you use JavaScriptCore with proton? It runs on node which uses v8. Resource measurements: The sample "Notepad" app (just a text box in a window, no copy/paste, etc.) uses 79 MB. For comparison the same app built using Xcode uses 27 MB, and TextEdit uses 40 MB.
On Windows 10, Notepad uses 2 MB and Wordpad 12 MB. I'm quite surprised that the latter can fit a full, Ribbon equiped word processor in so little memory. Not that I'd be concerned about a few tens of MB nowadays but on the whole we're consuming computing resources at the same rate faster hardware is put out (Gates' law). I have a Pentium 3 running NT4 sitting on the same desk and it is faster at many tasks than my i…
Sort of tangential, but does anyone know of a good React Native app? Everything I've tried would clearly have been a better product if they'd just done native development. Like, you're sacrificing product quality for development ease.
You might recognize a few on this list: http://facebook.github.io/react-native/showcase.html
Earlier quoted context omitted.
I looked at the GIF that the first one had on their GitHub page and it doesn't do iOS navigation right at all. I'm not impressed.
You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. It's iOS-style navigation and transitions through and through.
You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work.
> The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. > It's iOS-style navigation and transitions through and through.
UINavigationController is a complex beast that is often difficult to work with even in native code, because it tries to do a lot of things for you that are difficult or outright impossible to replicate if you try yourself (which isn't necessarily a good thing, but that's what we have so that's what we need to work with). Plus, a lot of this behavior "comes for free", but the downside to this is is you customize certain things you give up a lot of this behavior. So UINavigationController is not just showing a title and a back button in a box: it does things like managing transitions, animating the title when pushing onto the navigation stack, handling popping gestures, handling content insets and vibrancy, and providing certain niceties such as "tap the top of the screen to scroll up". It's a lot of things to keep track of, even for native developers, so while I'm not saying that this can't be done in JavaScript often a lot of this just ends up being reimplemented in scratch and you end up missing things. For example, the provided link, from a cursory glance that navigation controller completely butchered title handling and animations. If you want to take look at how these should work, take a look at Settings or Mail and see how the behavior differs.