Hacker News new | past | comments | ask | show | jobs | submit login

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.



Web 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" .


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


About Youtube or my example with a big image grid, do you think you can fit all those JS frameworks and tracking in memory but you can't fit the title and thumbnail url of 200 videos ? you have an array with this 200 objects if titlke,video url, thumbnail url , the network request you will do lazily for the thumbnails and you can load the next row of thumbnail in the background while I am scrolling down. I am not talking about loading all at once, you load only what you need and a bit more so when you scroll down the stuff is already p reloaded , let me know if this is not clear and I can explain (I profiled my app and it was spending 2 seconds in the native browser layouting code)

About the scrollbars, I am not taling about a document side scrollbar, think at an example of a dropdown with all the font families, those have a scrollbar, I don't want to reimplement the scroll. I want to use the native widgets but the designers decided we will use a dark professional looking theme and the native scroller can't be styled with css, I know the discussions we ahd here on HN about the main page scrollbar and I agree we should use the native widget but we should be able to color it to match the webpage colors , what you will notice in application not webpages is that everyone is using custom component, nobody uses the native dropdowns,scrollbars,calendar, numeric inputs, the reason most of the time is that you are forced into using custom widgets because teh native ones are limited, are not customizable enough.

I 100% agree with you about pixel perfect and styling but I am just a developer, I implemented this weak the numeric input using the native input, I presented it to my boss and they asked me to respect the design, so tomorrow I will have to hunt for a JS library that implements this, look trough it's bug tracking for it's issues etc. I hate I have to do this but6 is not my decision and my initial point is that this is a reason why Web apps are bad as performance or UX , this custom components can run code on your mouse move events, on your clicks, on your scroll events , a native component would be faster and have less bugs and more features.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: