Hacker News Reader

Comment by d--b | Hacker News Reader

Electron is just another proof that ease of programming matters.

Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Similarly, it is way harder to write a desktop app than a browser app. DOM / CSS manipulation, however bad they are, are years ahead compared to what you can easily do with WPF and friends.

And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.

The success of electron only shows that there is a market for a UI library that can be written just like what you do in the browser but for native desktop apps... Please someone, write that !

View on HN

> And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance.

Almost everything done in Python for data analysis is just a thin wrapper on top of a fast C/C++ library: Numpy, scikit, Pandas, Tensorflow, etc

That's a good point. You can get away with quite a bit of non-performant user code if the majority of the actual code execution is in the "inner bits" and not the user code. The user code ends up being the "driver" and the heavy lifting is all done by code that is able to provide the required performance. It's also a good reason why PHP has been able to become so pervasive.

> Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Pretty sure you could do that as easily in PHP, Ruby, Python, Perl before Node.

> And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.

When code performance matters most, you're probably still using Hadoop, C/C++, Fortran. Python is mostly in competition with R, Matlab, SPSS and Excel. Julia is the new kid on the block, and it was designed to be more performant than Python and R.

> Pretty sure you could do that as easily in PHP

PHP is awful but still the best option for making something simple very fast, as it is supported virtually in every kind of provider, even free ones.

Your Python example doesn't really support your argument. Python succeeded for data analysis and scientific computing in part because it provided easy access to existing numerical libraries written in C and Fortran. So you got the best of both worlds: ease of use and near-native speed. It would not have succeeded if everything was done in interpreted Python.

> ease of use and near-native speed

And still when we want actual speed we port it to C++ or at least need to use Cython.

> DOM / CSS manipulation, however bad they are, are years ahead compared to what you can easily do with WPF and friends.

This doesn't make any sense. It's much easier to create UI with XAML (WPF) because it's designed for that purpose alone. HTML / CSS really isn't.

Yep, WPF is probably the best platform at present for creating rich GUI apps. It's failure to really take off is overwhelmingly caused by its complete lack of cross-platform capability. If you're creating a new Windows app from scratch it's really hard to justify using a GUI framework that eliminates the option of going cross-platform in the future without needing to do a near-total rewrite.

>And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.

That is likely not the only reason. A lot of the libraries like NumPy, SciPy etc., that are one of the reasons (but not the only one) why Python is used so much for STEM / data analysis / data science etc., are written in highly optimized C or C++ or FORTRAN, with maybe thin Python wrappers over them. So ease of programming alone is not the reason. If it was easy but too slow to run (remember, many such apps process huge amounts of data), then people would not use it.

Edited to change "C" to "C or C++".

Having learned Ruby on Rails before Node, I view Node as "screwing around for hours before being able to respond to a simple http request."

> Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Or, people who like closures. Or other aspects of JS. Or of the Node platform (like event-loop programming).

What bothers me is that in theory there should not be any trade-off here.

I mean, programming languages and developer tools could be easy AND with high performance.

"Please someone, write that !"...

We actually have written something similar for our product Elevate Web Builder (commercial, closed-source, written in Delphi), and have considered moving it to Free Pascal in order to allow developers to use it in portable, native desktop applications. The IDE for Elevate Web Builder has to provide a browser-like design-time environment for the WYSIWYG designers, so we created one. It effectively uses a DOM element tree structure like the browser, but doesn't use HTML or CSS. Instead, it surfaces all declarative styling as element properties (with real types, not everything as a string), provides its own layout management that is more application-oriented instead of document-oriented, and has a great batch update functionality that allows you to suspend updates/repaints until you're done making all necessary changes to the element properties of one or more elements.

The reason why it's such a compelling idea for us is because Free Pascal is a blank slate with all of the support code for multi-platform development, and we already have all of the code written for Windows. The reason why we're hesitant is because it's all in Object Pascal, so I'm not really sure if it's a compelling draw for JS developers that want to create desktop applications.

If we ever do something with it, though, we will certainly post it here as a "Show HN".

Interesting, so you've create or are trying to create (or make cross-platform) something like a web dev environment in and for Object Pascal?

We have a product for web development in Object Pascal, Elevate Web Builder (http://www.elevatesoft.com/products?category=ewb&type=web) that includes an IDE with a WYSIWYG design environment (the IDE is written in Delphi for Windows). In order to supply the design environment, we had to write an emulation layer that mimics the DOM tree and can perform the necessary drawing operations to satisfy all DOM CSS style properties. This layer is ~80% of what you would need to implement a UI toolkit in native Object Pascal using Free Pascal. The last ~20% would be dealing with surfacing the native OS input controls (single-line edit, multi-line edit, etc.), which are just stubbed out right now because the design environment doesn't require them. We've considered finishing this last bit and making the whole thing available for Free Pascal.

Got it now, thanks. Interesting stuff.

There is Libui-Node (https://github.com/parro-it/libui-node) for creating native UI in node.js.

It's worth noting that Node.js - similarly to Python for data analysis - drops down to lower level code for a large chunk of its code base and makes it pretty easy to bind to other languages where performance matters.

Developers are often willing and able to produce high-performance code when the barrier to doing so is low enough.

Yes to me the solution to the heavy ram/diskspace usage isn't to abandon Electron but to optimize it.

That would seem like the best possible outcome for everyone, really, but you're not going to get much karma on HN unless you're either showering JS with praise or vilifying it as cancer.

Reply on news.ycombinator.com