211–220 of 295 posts
Earlier quoted context omitted.
I just declared Chrome bankruptcy and switched to Firefox a few weeks ago. CPU rarely goes over 10% on my 2017 MBP. With Chrome it was almost always above 50%.
I swapped when the new FF came out. Was sick of chrome using 3–4gb of memory and bringing my computer to a grinding vault. 3 times the number of tabs in Firefox and I have 0 issues. I recommend FF now.
Earlier quoted context omitted.
React Native seems to be geared for mobile. Proton Native uses bindings with NodeJS (via libui-node, which uses libui), which seems to be (IMO) a much better run-time for the JS part than JavaScriptCore because Node already can handle a huge amount of the OS interop. Also, JIT isn't restricted on desktop the way it is on iOS, so JSCore doesn't have a good reason to be used.
JSC is very fast, and the RN runtime is intended to be a fairly limited API, so I wouldn't necessarily say the access to the Node core packages is hugely beneficial. But it's a fair point. I'm not sure why JIT is relevant. Neither JSC nor Node do any JITting.
http://thibaultlaurens.github.io/javascript/2013/04/29/how-t...
Earlier quoted context omitted.
I’ll put in a plug for my former employer’s OpenLaszlo, introduced in 2002 (preview) and 2003 (version 1.0). OpenLaszlo was most immediately inspired by HTML and (for data binding) XSLT. I looked at Mozart for ideas on constraints, but we ended up rolling our own design — mostly because constraints were never supposed to be a feature, so they were designed and developed incrementally, in discretely releasable baby st…
Adam Wolff, former Chief Software Architect of Open Lazlo, is now the Director of Product Infrastructure at Facebook, and oversees React and React Native.
This was the bottom of a slippery slope, where the designers and developers using the platform were exploring the kinds of applications it was possible to write (single-page web applications were relatively new in the early oughts — except for some pioneering Explorer-only DHTML work by Microsoft, which we should have looked at but didn’t — and we were all making up interaction patterns and software design idioms as we went along), and we were adding the platform features to enable some capabilities and golf others.
For a while Adam ran Laszlo’s Professional Services. He succeeded me as CSA when I left Laszlo.
It wasn’t Flex/MXML or XAML that killed Laszlo/OpenLaszlo, it was IMO first-gen dynamic frameworks such as Prototype and Scriptaculous, that could be gradually integrated into a page without placing a big rewrite-your-app bet. Also that we were about a year late in adding HTML as a second back end. (HTML wasn’t sufficiently standardized or practical to use for cross-browser single-page applications in 2001 when we started work on the Laszlo platform implementation, but it was by 2005-6.) Or, closer to the root cause: sales and strategy issues that made it difficult to keep investing much in the platform once it was starting to get traction; the product feature omissions are how those resource constraints played out.
[1] https://patents.google.com/patent/US20050039165A1/
> 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…
I remember using GUI codegen tools in the 1990-ish era that would blow away your code changes with every GUI tweak. Interface Builder and delegates were a great solution to that problem. I just didn’t get to use them for a really long time.
This runs on libui-node, which is a binding to the libui library. https://github.com/parro-it/libui-node https://github.com/andlabs/libui
Nice to see this project is still alive, it shows a lot of promise but appeared abandoned for a while. Have they got the data grid API's working yet?
Earlier quoted context omitted.
I just declared Chrome bankruptcy and switched to Firefox a few weeks ago. CPU rarely goes over 10% on my 2017 MBP. With Chrome it was almost always above 50%.
I swapped when the new FF came out. Was sick of chrome using 3–4gb of memory and bringing my computer to a grinding vault. 3 times the number of tabs in Firefox and I have 0 issues. I recommend FF now.
Earlier quoted context omitted.
> You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc 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 n…
...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS. All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I…
I'm aware of that–that's why I said it is possible that you can do it from JavaScript. What I'm saying is that the JavaScript layer generally causes issues like this, because UINavigationController only works in specific cases. For example, scrolling only works if you're a singular top-level scroll view. Getting the titles to animate only works if you don't try to modify it after the fact. Putting a button in the navigation bar's title view just makes it mess up when it runs its first layout pass. A lot of frameworks end up doing this, or making it very easy for this to occur, so you end up with "broken" navigation of the likes seen in that GIF. Of course, it's not unusable, so those who aren't as familiar with how it should work don't notice the difference.
> Blind allegiance to a particular tech stack isn't healthy for your career
I'm surprised you haven't drawn the cynical conclusion from this: that I'm desperately trying to keep my skills relevant in a world where they're being increasingly obsoleted (if you were wondering, no, this isn't true. I do have other skills as well, not including the uncanny ability to get into arguments on the internet ;) ) Thanks for the advice though, and I do mean that sincerely.
> throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything.
Wait, are you really telling me to stop "putting down" non-native projects? Am I that persuasive that I'm giving fodder to other people? I'm really not trying to be argumentative here or pushing any sort of agenda; I'm just really, really sick of people pushing out terrible web apps that they call "native". As a developer, I agree that these projects have better tooling (Xcode isn't a particularly high bar to clear, though), but as an end user, I really hate these projects because they're clearly oriented towards developers rather than me. As someone who largely writes software for themselves, the idea that you'd make tradeoffs that harm your users is just morally appalling to me. It's not the environments that need to step up their game: it's developers who need to realize that the user is important. Sure, use JavaScript or Qt or whatever you need, but not because it makes your life easier: do it because it improves your user experience. If Cocoa just decides to mine bitcoin on your computer tomorrow I'll switch in a heartbeat, since it benefits my end users.
> This is almost willful ignorance on the level of Twitter's Cocoa community.
Sorry, I'm not on Twitter, so I'm not aware of what you're talking about here. Could you provide more context?
Earlier quoted context omitted.
I recently experienced Visual Studio 6 in a Win2k VM, and it was sickening how fast it was compared to modern tools. Same with Office2k apps, and all using an order of magnitude less memory. There has to be a better way than the path we are on, software-wise.
It's ridiculous. I can launch a VM running Linux + X11 desktop environment from scratch faster than one of the most popular Electron apps launches & connects. Probably would run few apps in the VM well too with the same amount of memory. Anything that could fix the current situation even a little bit like this project is much appreciated imho.
This craziness just made me buy Sublime Text.
> 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…
NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.
How could we? There is hardly any design tooling that matches the capabilities of native ones.
So we just give up and pretend we don't need them.