I often have to fight with myself to pick the right tool for the job, not the tool that makes my job the most fun to do.
At least the Electrino idea is more reasonable. Using a framework already loaded into memory by the OS and sharing it would go a long way toward reducing the bloat...though not toward the horrible battery problems it introduces. Seriously, people are still brushing aside issues with something where a blinking cursor caused CPUs to crank up to the max...
So until someone can build a production ready, cross platform, JS desktop experience....Electron will live on.
It might already hide the address bar when opened in this mode. I personally expect that it's just a matter of time before this becomes an install mode for desktop apps as well.
It sounds like a promising avenue for bitcoin mining.
It’s not to wrap a website, it’s to add features that the web doesn’t offer.
For example, how could Atom exist and be able to show your files in the explorer pane as a web app? It can’t.
Electron adds the missing pieces/permissions that desktop apps have had since the beginning.
That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers.
I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.
Not sure what you would consider exciting or boring, but I thought it was decent advice.
(Higher risk on a simple project, because that's the only opportunity to learn new stuff, as in the worst case you can start over. Lower risk for a complex project, because there's already enough risk in the project itself.)
But if you reach for that new language that hasn't been battle-tested yet, you're probably screwing the bank over.
There is tremendous fear in the industry right now over being seen as outdated or dinosaur, especially with all the blockchain hype.
You can make simple technology choices like moving from a stateful SQL database over to a blockchain ledger like Sequence, and in doing so, you will attract a way higher calibre level of talent. You will also have way more people interested in working for you, and the skillsets and knowledge learned within the company for doing it will future proof you far better than going the boring old route.
The feature is absolutely hype, and a selling point, or was til the RBA required everyone else to follow suit.
But it doesn't change the fact that fundamental things that cannot be allowed to fail should not be built on twigs.
CBA worked with Wells-Fargo to build a blockchain ledger, running atop skuchain, which itself Go and JS. That's a lot of hype and new in one place.
But it wasn't in a simple systems-critical place, it was done for one contract, with one customer first, with regulatory approval for the experiment, to see if blockchain technology was feasible. It was also not proof that this can scale, that needs more experimentation.
Lots of simple things are fundamental, and you do not mess with those.
Simple/complex isn't enough to say whether you should experiment, because experiments should be as far from impacting your bottomline as possible.
R&D should stay in R&D, until it is proven stable. You can't afford to build a house of cards.
If the team and managers agree, by all means use the exciting tech, but it isn't a decision to make in isolation.
The canonical link on choosing boring technology is http://mcfunley.com/choose-boring-technology.
A relevant example is microservices which are all the rage right now. But, you have to be this tall to use them[0]. You cannot effectively just say you are going to do microservices, especially if you don't know how to do microservices.
Alternatively, consider the potential problems for your company if you had introduced React on your own in a core business element, and your company had a patent beef with Facebook, and FB hadn't switched to the MIT license.
[0]: https://martinfowler.com/bliki/MicroservicePrerequisites.htm...
Not being exceedingly serious here but... you pretty much summed up why Python is so successful in AI/ML and science ;)
The boring technology in AI/ML is C++.
Which is why TensorFlow etc. have a boring & hard C++ core, and a lovely & easy Python layer that transmits the computational graph to the core.
Electron is similar: a boring & hard Chromium C++ core, and a lovely & easy JS layer.
What pains me is that there is no reason to include libraries we don't use.
Each Electron embeds a large amount of memory-consuming libraries that do things that are way out of scope for most apps: screen recording, sound editing, GPU graphics libraries…
Cooler and more advanced (in terms of language features) languages are Julia (it has real macros, advanced type inference etc.) and even R (yeah, it's a mess, but as a language it's more advanced and "cooler" than Python). On the "web backend" scene Ruby is a way more "not boring" language, but the ML and science communities avoided it almost completely (I have a few theories as to why...).
And then there's the "truly cool" and "0% boring" languages like: Scala, Rust, Elixir, Clojure, Haskell, Elm, Crystal, Pony etc.
But don't get me wrong, I like Python for being what it is: an incredibly boring scripting language, that encourages a "stone age level" style of dumbed-down programming. With slightly awkward but stable libs (on which people agree almost unanimously of which to use). Because with Python I can focus on the product instead.
C++17 written using best practices in safety learned in the last decades, is exciting and simple.
Anyway, C++ is nothing but boring... even the bugs you encounter are nothing bu extremely surprising and "creative" :P
Of course, it will take time to move from "C compiled with C++ compiler" to something better, specially in the embedded domain where Assembly and C still rule.
The tools are there, and an incremental update into safer code is always better than throwing everything away, and rewrite everything, including the already fixed bugs.
The only thing that C++ cannot fight against is the C mentality. That is only possible in languages that lack copy-paste compatibility with C.
Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They can extend their existing skills into a new arena, without having to learn any new ones. Developers are always asked to turn products around as fast as they possibly can (and, um, also people are lazy), so this is a very powerful appeal.
This "I don't have to learn anything new" factor is literally the only thing Electron has going for it. Using any other alternative will result in applications that perform better, fit into their host environments more naturally, and generally work better than an Electron app will. But there are a lot of JavaScript developers out there, and any other alternative would require all those folks to learn a whole bunch of new stuff to get started -- new languages (C/C++, C#, Java, Python, etc.), new toolkits (UWP/Win32/Cocoa/whatever, Qt, WxWidgets, etc.), new programming paradigms, etc. etc. etc. Whereas with Electron they can pick it up and be productive in a couple of hours, which is a hugely appealing prospect.
Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.
1. Pros/cons of using tools we already know 2. Pros/cons of using tools we enjoy using
I am awful at Docker because I started using it yesterday. But upon using it, I'm suddenly so attracted to it and am thinking about what fun personal projects I can apply it to. It's a beautiful technology.
I am very strong in JavaScript but love avoiding it like the plague unless it is the appropriate technology.
Edit: okay I'm skeptical of a part of your analysis. Please show me a detailed example of building a desktop app that runs on Mac/Windows/Linux, looks reasonable, and takes the same or less time from a competent developer. I am genuinely starving for an alternative to Electron that doesn't come with a significantly heavier dev/support cost.
Done right, they're faster, for sure. But when you use Electron you're leveraging thousands of man-years of Google developer effort to build a web browser that works consistently and well across different platforms. Although the web platform gets a bad rep for cross-browser compatibility problems and general weirdness, a huge amount of that goes away when you target a single runtime. Suddenly you can use every half-baked Chromium API and prefixed CSS feature without worrying about how it's going to break in IE 11.
In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).
There are better languages that JS, that's true. But whether there are truly better cross-platform app toolkits than the web is, in my opinion, rather more unclear.
The larger the dependency, the more it should have to do to justify itself. "It's fun to write in" is not a sufficient justification for a 70mb dependency. "I need a cross platform app" is better.
As an engineer, you're responsible for the transitive dependency graph that gets delivered to customer machines. If you want to take on gigantic dependencies because they are the current lovechild of ascendant Medium bloggers, be my guest. I prefer to go off of more than fun and social proof when making engineering decisions, however.
IME, yes. Most of those toolkits also have thousands of hours invested to work well across platforms, not consistently but natively, or at least a close facsimile of native.
> In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).
So nothing that hasn't been true of desktop apps for decades then? If you want power then nothing beats being able to overide the paint method of a widget, you have complete and total control.
If you're interested in seeing how easy desktop apps are I built the canonical todo list in Gtk (https://gitlab.com/flukus/gtk-todo/blob/master/main.c), the goal is a demo that's a bit more complex than hello world. This is in a language not known for it's terseness, uses one of the nastiest parts of the framework (GtkTreeView) yet it still comes in at less than 100 lines of fairly straight forward and simple code.
And it only costs you 400MB of RAM and 20% CPU utilization!
I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim.
If the goal is to learn GTK, Rust, and C, then it's not a big deal. If the goal is to build something that you need, you end up scratching it and going back to something you know already.
(In my case? Java which has the underrated JavaFX 2.0. And I'm sure I'll look elsewhere some other time - I'd really like to learn Rust better, but I think I'll do something other than a desktop app, or at least wait for better documentation or more time.)
That said, Lazarus looks really cool as well and may be the thing I always hoped for...
Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
Thus, don't hope too eagerly...
This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms.
Cocoa is of course under heavy development, but keep in mind that there are only a handful of Lazarus developers that even have access to a Mac and they actually had to write a special dialect for the compiler (Objective Pascal) to be able to handle Cocoa objects directly without the need of an intermediate (like Qt that needs libqt4pas that exposes the Qt API as a C interface that is then linked dynamically with FPC through a C-to-Pascal binding).
> Development is not on Github.
This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
> Syntax has no common style.
What do you mean? The IDE even provides formatting tools.
> Documentation is uneven.
Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
> The whole ecosystem feels (well, is) dated.
Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
>> Development is not on Github. >This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
(Most important is, what the fpc/lazarus developers want). -- Many people likely don't want to bother/install the 'ugly and stupid' SVN nowadays and Lazarus/FPC looses all those potential contributors at once. I don't like monocultures either but GitHub (maybe Gitlab) is the pragmatic choice and imho helps to have/find contributors.
>> Syntax has no common style. >What do you mean? The IDE even provides formatting tools.
Comparing Lazarus, FPC, MSEgui and some component sets, I had the impression that there are many (small) differences, e.g. 'integer', 'Integer', 'INTEGER', where begin..ends are placed and many more 'non-conventions'...
Tool is good, but (imho) the issue is that there is no BDFL which would gently nudge towards a commonly agreed style guide. Likely not helpful is also that Pascal is not case-sensitive and that there are multiple modes (OBJFPC, DELPHI, FPC..)?
>> Documentation is uneven. >Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
I don't want to complain. Core FPC docu is high-quality, written in Tex. But I found it difficult to get an overview: which are the relevant pdf's/links, where is the source for it, how would I contribute or report an error? For a quick shallow fix, it seems too complicated: Tex, xml; inline help, huge separate svn docu project; FPDoc generator. Contrast this to many environments where you can quickly fix a typo or phrase in the browser and the project gets a PR.
>> The whole ecosystem feels (well, is) dated. >Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
Difficult to be specific. If you e.g. look at go (golang.org/), rust (www.rust-lang.org), julia (julialang.org) and/or haskell (haskell.org) and some of their tool-choices, it feels for me very different than FPC/Lazarus. This is not mudling, it's just a realistic look at the situation. Dated also doesn't mean that it wouldn't work any more.
It is imho a problem if e.g. there is newpascal.com site with a more modern feel instead of the old trusted projects moving to a more modern approach. Don't know details but this choice raises the complexity for a user as it is not clear, what to choose.
>> But to really shine and be a valid alternative, it would need a large infusion of money and manpower. >Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
Do you have examples for such companies / situations? As the code is mostly GPL-2 (components LGPL2 with link-exception or MPL), it seems to be difficult for a company to take over. And personally I wish that there were steerings towards a more uniform and easier-to-enter 'FPC/Lazarus-world'.
>The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
Yes I hope things improve with new blood. For the 'Pascal universe' as a whole, lack of developers means 'not attractive enough'. As I really like the language I would blame the choice/proliferation of 'dated stuff' to be a contributing factor.
Last but not least, Lazarus worked well last November when I tried it out again. I was positively surprised. Nevertheless one has to have realistic hopes...
Not necessarily. D has dlangui and dwt, tcl (and also python?) has tk. Vala is also available for gtk. I think VB also lets you write GUIs although not sure I never used it. Objective-c has cocoa (gnustep outside of macosx).
Not completely, don't underestimate how hard it is to write a cross platform UI that runs on Windows, OSX and Linux.
Starting from a web framework not only gives you portability but also a common UI language(that may diverge a bit from native app conventions but that's a tradeoff you need to weigh).
I say this as a die-hard C++/native dev. I've done wxWidgets, QT and a bunch of others and it's never a trivial thing to do.
(also a C++/Qt dev, jealously eyeing love preview, hot-reloading, and other niceties).
... except when you actually need to actually, you know, port it, to a platform it wasn't already ported to out of the box.
Yes.
In "Code Complete", Steve McConnell argues that although a programmer can learn a language syntax in a couple weeks, mastering the language, tools and libraries that make up a platform can take a couple of years.
In other words, asking developers to build and maintain non-trivial products in a language that they don't already know is an even bigger burden than you might think, to the point that it's probably an unreasonable request.
Familiarity, knowledge transfer is a big drive for technology adoption. The bad bit is when the decision maker leaves the team and the rest are unfamiliar with the tech. I think this applies to Electron pretty well as web developers can now contribute.
The "it would look good on my CV". I'm thinking about Kubernetes where it doesn't make sense to use most of the time but everybody wants to be doing it because it's hot.
However this is a part of being professional, using the required tools for the job.
Programming really at some level is as much about translating human ideas into physical computations as anything. In this regard, it is a fundamentally psychological process, as much about the programmer as the computer. There's a sort of psychological-cognitive -> math -> physics process, and I often feel as if the emphasis is on the second two steps, and not so much on the first two.
There's good reasons for this, but it's resulted in a sort of blind spot that often comes out as people just preferring languages like python or javascript or whatever, and not wanting to acknowledge that those fuzzy, poorly understood preference processes are driving development as much as the choice of algorithm or hardware constraints.
I think it's poor ergonomics, really, and effects things as much as memory management models, etc.
We're at a stage, though, where languages like Nim, etc. offer some promise of ergonomics and performance, and I hope people will pay attention to it carefully, so we don't end up in the same situation as the one Atom exemplifies. I like Atom, and don't have any particular attachment to Nim, but do think there's something we shouldn't be ignoring anymore. Often when a language is difficult to intuit, the reaction is to shame the programmer, to characterize them as not smart enough to understand the language. Sometimes there's some truth to that, but sometimes I think it reflects deficits in the language, whose sole purpose, really, is to translate human thoughts into computational events.
One language that openly acknowledges it is designed first and foremost with psychological factors and ergonomics in mind is Ruby:
"For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy."
https://github.com/alexch/ruby_notes/blob/master/ruby-intro....