Long ago and far away, we had these things called “shared libraries” which allowed one to build code and reuse it, so that even if the build process was very long and complex, you only had to do it once. An elegant solution from a more civilized time.
If we assume that it’s a good idea to use chromium, very little of this is actually electron’s fault. I’ve had the pleasure of working with google’s build tools at work; everything from weird assumptions to gigantic downloads to weird build tools to including its own little Debian Wheezy is all on Google. (As a bonus, they start all their python scripts with #!/usr/bin/env python, but their scripts are entirely python 3 incomparable, so I have a short script to just toggle whether /usr/bin/python is a symlink to python 3 or python 2.)
Our C programmer tried to get a VM set up with Electron on OpenBSD so we could do testing. It was a massive time suck and never did get it working. It cost us a lot and the whole situation was very unfortunate.
At the moment, Electron is the easiest way to get a web browser app and packager. If there were something better, we’d try to use it.
It’s effectively electron, but without the web browser & uses the system browser / javascript runtime directly instead of bundling it’s own. Not perfect, but easier to ship than electron!
It’s mostly chromium that’s the problem - for which you can blame Google. “everyone is on a 100Gbit connection to Google’s internal network, so who cares if we repeatedly download 500Mb build artifacts!” appears to be the thinking.
Pushing out git archives that fail git-fsck isn’t ideal either.
Makefiles are great for small Unix projects, not so much for something that needs to be built for Windows too… Windows developers live in a parallel universe of build tools and that coupled with the shear size of chromium helps to explain why they felt it necessary to make ninja.
The complexity of the project is pretty crazy though.
So I guess we can thank GitHub for at least trying to make the framework they used for Atom into a reusable platform, while politely declining to use it.
Long ago and far away, we had these things called “shared libraries” which allowed one to build code and reuse it, so that even if the build process was very long and complex, you only had to do it once. An elegant solution from a more civilized time.
Elegant like a spiderweb.
If we assume that it’s a good idea to use chromium, very little of this is actually electron’s fault. I’ve had the pleasure of working with google’s build tools at work; everything from weird assumptions to gigantic downloads to weird build tools to including its own little Debian Wheezy is all on Google. (As a bonus, they start all their python scripts with #!/usr/bin/env python, but their scripts are entirely python 3 incomparable, so I have a short script to just toggle whether /usr/bin/python is a symlink to python 3 or python 2.)
[Comment removed by author]
Sure: https://gist.github.com/mortie/ccd5b227fe6111fea017e7258d77d9a4
Yeah, there is no problem with excessive shitty tooling in web tech. They are not within a hundred miles. There are no suckless infidels in web tech.
The web can not be fixed. It would help though if people stopped treating it as a platform for complex applications.
Amazing. But the pain of complicated user builds hits so close to home.
Our C programmer tried to get a VM set up with Electron on OpenBSD so we could do testing. It was a massive time suck and never did get it working. It cost us a lot and the whole situation was very unfortunate.
At the moment, Electron is the easiest way to get a web browser app and packager. If there were something better, we’d try to use it.
This was posted recently: https://github.com/pojala/electrino
It’s effectively electron, but without the web browser & uses the system browser / javascript runtime directly instead of bundling it’s own. Not perfect, but easier to ship than electron!
I love it!
It’s mostly chromium that’s the problem - for which you can blame Google. “everyone is on a 100Gbit connection to Google’s internal network, so who cares if we repeatedly download 500Mb build artifacts!” appears to be the thinking.
Pushing out git archives that fail git-fsck isn’t ideal either.
Makefiles are great for small Unix projects, not so much for something that needs to be built for Windows too… Windows developers live in a parallel universe of build tools and that coupled with the shear size of chromium helps to explain why they felt it necessary to make ninja.
The complexity of the project is pretty crazy though.
I’ve used nmake with some success to build things on Windows.
So I guess we can thank GitHub for at least trying to make the framework they used for Atom into a reusable platform, while politely declining to use it.
Great conclusion