4 ms·
I feel that Electron is bad not because you're running the same UI everywhere but rather because you're running an entire web browser.
by bpye 7y ago
I feel that Electron is bad not because you're running the same UI everywhere but rather because you're running an entire web browser.
- simion314 7y agoWeb technology is designed for documents and making non toy apps is a pain, if I may give you a few examples of issues I hit this week: - I wanted to create a grid of img like elements(something a bit more complex where you have some small buttons on each image), I hit the issue that the browser would take like 2 seconds to load 1000 elements, in a decent GUI toolit this is not a problem, as an example in Flex4 I can have a list with 1000 elements, if only 10 elements are visible then the toolkit creates say 16 GUI elements, as you scroll the elements that get out of view are recycled , in Web you either create all 1000 GUI elements(that each element is maybe formed with a giant div soup) or you use a infinte scrolling like pattern, check Youtube as an example, go to a specific channel video list, you see only 2- 3 rows of videos, then you scroll and wait for next few rows, scroll and wait again, scroll and wait again ...tldr web GUI performance is really bad - native components are limited, you can't css properly and consistently a numeric input(you can't css the colors of arrows to fit your styles) , you can't have a dropdown that contains icons or some more complex thing like a "Font Families dropdown" , you can't customize the dropdown scrollbar colors so you are forced (is not my fault that desingers want shit to match in theme and not have white crap on a dark theme) to find or create custom components, so you get to import JS libraries and most of the time this components are broken, Ex check the youtube search dropdown, it happened a few time for me to get the dropdown in the search to get stuck open, only way to fix it is to reload the page, Google devs can't properly implement a correct dropdown widget. In PayPal their custom input widget to enter money does not support the "Del" key . In a decent widget toolkit you extend the existing widget, you get all the existing functionality and you add your custom features on top in Web you start with DIVs and CSS do a mediocre job and then fix the issues that get reported if you have the time. All this issues are solved in Qt, Flex or WPF, the components are performant, you can customize without losing basic features, you don't have to research shit like "what library should I use Monday to implement the numeric spinner input" .
- danShumway 7y ago> Web technology is designed for documents CSS/HTML have some pretty significant problems, but this hasn't been true for years. And in any case, 90% of the native apps I use are basically interactive documents anyway. Unless your definition of "non-toy" apps is primarily referring to apps like Blender or Photoshop, most of the native apps on my computer could be trivially represented in HTML. You should think of HTML as a render target, not as a document layout framework. HTML isn't where you lay out your application; HTML is where you present your application's data to the user. > in Web you either create all 1000 GUI elements[...] or you use a infinte scrolling like pattern, check Youtube as an example, go to a specific channel video list, you see only 2- 3 rows of videos, then you scroll and wait for next few rows, scroll and wait again, scroll and wait again The reason you wait on Youtube is because it's making network requests, not because the HTML is slow to insert. The way you would solve this problem if you weren't worried about network performance would be to use a virtual DOM, because the DOM is a rendering target, not a layout framework. "Native" controls on the browser do restrict you quite a bit, but that's at least partially on purpose, because the whole point is to use "native" browser conventions with those components. How many times on HN do we see people complaining about scrolljacking on a website? And you want people to be able to style scrollbar colors on top of that? There was significant debate on HN about a month ago about whether it was even a good idea for browsers to respect `autocomplete="off"` in input fields. A significant chunk of your users do not want you to do this kind of stuff. What the web does do is that it provides you mechanisms to avoid the native components if you have a really, really pressing need to do so -- while encouraging you that most of the time, using built-in browser behaviors will be better for both you and the user. If Twitter was using native components and not hijacking browser behavior, text input wouldn't insert extra spaces whenever you copy-pasted. If PayPal was using a regular numeric input instead of some custom-built monstrosity, it would respect the delete key and render more consistently with your browser theme. If Youtube wasn't forcing itself to be a single-page app, you wouldn't get bugs where videos failed to load on navigation. Seeking pixel-level control over every element is the opposite of how you get applications that look and feel native. Looking and feeling native means respecting platform settings and conventions.
- simion314 7y ago