5 ms·

I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML base

by a85 10y ago

I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the case with Electron. - They can perform equally well. The web platform itself is an example of this. Browsers have improved quite rapidly over the past few years. - Optimizations can be made in JS code as well. Other comments here have some examples. The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) The JS ecosystem has grown much faster and will continue to do so. The building blocks that are available will also improve in quality and I believe that more and more developers chosing Electron will speed up this process.

Veratyr 10y ago
> Users don't use things because they are developed in a particular language. If the users in question were the standard near tech-illiterate masses, you might have a case but we're talking about a developer tool in this specific instance. I'd also suggest that you go take a look at the reviews on the Android app store for most banking apps, which are typically webviews. They're nearly always terrible and often due to the webview itself. Users don't distinguish between native and webview wrappers because they don't understand the common factor in the terrible experiences they're subjected to. > HTML based components can be made to fit into OS styling quite readily Yes, this is technically possible but I'm yet to see someone actually do it. > and by keymapping shortcuts you can get the exact functionality as native OS controls. To do this properly requires the developer to implement keymapping properly, which again, is possible but I very very rarely see it done. > They can perform equally well. No, they cannot. HTML components are always burdened by the overhead of a browser. At absolute best, you can come somewhat close. Futher, performance includes not just UI latency but the CPU and memory impact on the machine, which again, can never match true native apps due to the overhead of the browser, which is insane. > Optimizations can be made in JS code as well. Unless something extreme has happened in JS runtimes recently, you can't optimize your code to use SIMD instructions and parallelize, you have to leave that to the compiler. In native code this is not the case. > The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.
- a85 10y ago
  "tech-illiterate massess...." I am very well aware that our audience is a developer tool and well again, people do not use tools because of the languages they are written in but because of the experience they deliver. You are bringing up extreme examples to support your viewpoint. Bad developers will write terrible experiences in any language. Writing native apps requires a level of expertise that is not with the average developer either. Look at other comments in the thread talking about a "native" app going from good to bad. > "HTML based components..." Well, one of the reasons why one has not come up is that most users don't care about OS styling as such. Again, UX benefits over pedantic comparisons. > "They can perform equally well..." Why is the browser a bad environment assuming the level of performance required is known? I don't see any technical limitation here. CPU/memory impact on the machine can be handled equally well in Electron by offloading components onto native languages if required. I guess then one should always write in assembly languages? As far as I recall, games were written in C and specific parts were optimized in an assembly language. Those lower level constructs are still available in other ways. I am not sure you understand that technological choices are made with specific constraints towards a goal rather than purity of abstractions. > "Qt developers..." And I am sure so can any competent developer through any of the choices available in the market. A copy of a product is easy to create. A product is harder to iterate and maintain.
- hornetblack 10y ago
  >> The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) > I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead. One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.
- lowboy 10y ago
  IME, most devs use tools because of the features they provide and not for the tech used to build them. Also IME, Electron apps are generally an of magnitude better than mobile webview apps.

by a85 10y ago

Veratyr 10y ago

> Users don't use things because they are developed in a particular language. If the users in question were the standard near tech-illiterate masses, you might have a case but we're talking about a developer tool in this specific instance. I'd also suggest that you go take a look at the reviews on the Android app store for most banking apps, which are typically webviews. They're nearly always terrible and often due to the webview itself. Users don't distinguish between native and webview wrappers because they don't understand the common factor in the terrible experiences they're subjected to. > HTML based components can be made to fit into OS styling quite readily Yes, this is technically possible but I'm yet to see someone actually do it. > and by keymapping shortcuts you can get the exact functionality as native OS controls. To do this properly requires the developer to implement keymapping properly, which again, is possible but I very very rarely see it done. > They can perform equally well. No, they cannot. HTML components are always burdened by the overhead of a browser. At absolute best, you can come somewhat close. Futher, performance includes not just UI latency but the CPU and memory impact on the machine, which again, can never match true native apps due to the overhead of the browser, which is insane. > Optimizations can be made in JS code as well. Unless something extreme has happened in JS runtimes recently, you can't optimize your code to use SIMD instructions and parallelize, you have to leave that to the compiler. In native code this is not the case. > The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.

a85 10y ago
"tech-illiterate massess...." I am very well aware that our audience is a developer tool and well again, people do not use tools because of the languages they are written in but because of the experience they deliver. You are bringing up extreme examples to support your viewpoint. Bad developers will write terrible experiences in any language. Writing native apps requires a level of expertise that is not with the average developer either. Look at other comments in the thread talking about a "native" app going from good to bad. > "HTML based components..." Well, one of the reasons why one has not come up is that most users don't care about OS styling as such. Again, UX benefits over pedantic comparisons. > "They can perform equally well..." Why is the browser a bad environment assuming the level of performance required is known? I don't see any technical limitation here. CPU/memory impact on the machine can be handled equally well in Electron by offloading components onto native languages if required. I guess then one should always write in assembly languages? As far as I recall, games were written in C and specific parts were optimized in an assembly language. Those lower level constructs are still available in other ways. I am not sure you understand that technological choices are made with specific constraints towards a goal rather than purity of abstractions. > "Qt developers..." And I am sure so can any competent developer through any of the choices available in the market. A copy of a product is easy to create. A product is harder to iterate and maintain.
hornetblack 10y ago
>> The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) > I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead. One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.
lowboy 10y ago
IME, most devs use tools because of the features they provide and not for the tech used to build them. Also IME, Electron apps are generally an of magnitude better than mobile webview apps.