461–470 of 629 posts
On every post dedicated to this topic, I feel obligated to mention these 3 links: https://htmx.org/ https://unpoly.com/ https://hotwired.dev/ These are the tools that promote the idea of keeping app state on server and client/server talking HTML, not JSON. If you're not yet familiar with the concept, you'll love reading Essays here: https://htmx.org/talk/ (scroll down and look to the right side).
Earlier quoted context omitted.
I’m very critical when a company like Slack cannot find the time and resources to make native clients. I’m so #%^*ing tired of it taking three Mississippis to show a channel I click on. But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude. It’s a brilliant tool for shipping early and fast. My only criticism with these start-up use cases…
But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude. Compared to what? Java? Have you used c#.net, or for that matter Delphi or VB6 in their heydays? To me, I look at electron and I would put it roughly on par with QT. Although, like the vb vs delphi argument, i think electron gives you a good initial boostrap and makes you feel product…
http://www.smashcompany.com/technology/my-final-post-regardi...
So basically hardware improved 1000 times, but out of that improvement, corrupt programmers took 999 for themselves, to make their lives easier. The end user got almost no benefits. Where is my Minority Report UI?
It is a valid question though: "Did we spend the speedup the hardware gave us wisely?" It's reasonable enough, in my mind, that we spend some of the speed to great higher level language, so that we could solve problems faster. Besides that, in all honesty, did we spend the remaining speed all that well?
Most of the problem we solve are still data input, some calculations and an output. Some times we skip the calculation bit, and just retrieve our data a little later, other times we skip that part too, and just store stuff.
With the exception of video and gaming... what have we actually build in the last 15 years that couldn't be done before. Sure, we can scale to more users, but we use more servers that ever to do so. For the average office and home usage, we wasted so much speed, and it's not clear where it went.
The chat applications are the best example, my Google Chat eats 700MB of RAM, yet the only added a "Create video call" button and inline images, as compared to IRC or other platforms from 2000 and earlier.
Don't get me wrong, there are stuff like neuroimaging, better weather reports, climate models, simulations, CAD, all that good stuff, but that's not helping the average computer user who just wants to check Facebook and read spam.
Earlier quoted context omitted.
I think that's what's offensive to the purist engineer mind. These aren't engineering decisions, they're business decisions (or maybe the closest thing you could call them would be "financial engineering" decisions). The best thing, by pure engineering criteria, is not what gets built. The best thing for the business is what gets built. In that context it's a complaint as old as the hills. ...and not specific to comp…
Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole problem, the reason Engineers exists, is to manage technology such that the constraints of money and time can be met.
Optimizing for quality and time can be a winning solution, particularly if you can achieve novelty as well. Countless corporations and founders have had success with the strategy (Apple under Jobs comes to mind.) Optimizing for quality and cost is also viable: Deming preached it, and e.g., Japanese car manufacturers have showed it to be a highly successful strategy.
Earlier quoted context omitted.
> These aren't engineering decisions, they're business decisions All engineering (including "real" ones like civil or mechanical) is about fitting your requirements within budgets. When one's building a skyscraper, you try to build it in a way that minimizes the cost while satisfying all requirements (it shouldn't fall down given such and such conditions, etc.) Engineering is largely the art of solving problems that…
"Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands." - Someone
"The perfect race car crosses the finish line first and then completely disintegrates"
- Ferdinand Porsche
(I took some liberty with the translation - the idea is that everything breaks at the same time.)
Earlier quoted context omitted.
I think that's what's offensive to the purist engineer mind. These aren't engineering decisions, they're business decisions (or maybe the closest thing you could call them would be "financial engineering" decisions). The best thing, by pure engineering criteria, is not what gets built. The best thing for the business is what gets built. In that context it's a complaint as old as the hills. ...and not specific to comp…
Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole problem, the reason Engineers exists, is to manage technology such that the constraints of money and time can be met.
The thing is, slack has not been short of time OR money for at least the last 5 years. They could have easily built leaner, faster native apps and customers would have appreciated it.
This "ivory tower" stuff smacks of just world/just market fallacy.
I suspect there are deeper issues here. For example, vendor lock-in inhibiting competition paired with the "electron app team" being a powerful fiefdom within the company.
IME the concealed undercurrent of politics tends to provide a better explanation for many hard to understand decisions at large companies than unexpected technical prudence. Why does Uber's app require 150 developers? Why is Facebook's app such a beast? Why did they create a whole new "lite" app rather than slimming it? Why does Google have 13 messengers?
Reaching for a calm, rational engineering decision to explain each case is tempting, but wrong.
The author is fighting a strawman. Rather than engage with the specific problems these solutions were built to solve they dismissively regard them as just flavor of the week trends purely for the sake of chasing newness. This is true of the entire post, but I'll tackle just one since it's emblematic of my issues with all the rest: The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper…
> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". Expecations have changed. It is 2004, your company needs a simple CRUD app so your employees can work with some structured data in a DB somewhere, let's say so sales can check inventory levels in an existing database. A single developer can start up a Winforms project and throw something together in a matter of days to weeks.…
I remember writing one utility that would turn off the monitor with a global key shortcut. It had a little window with just one button, and would minimize to tray.
I was able to build it just by downloading the free version of Visual Studio and reading the docs. The extent of my programming knowledge at that time was doing some silly LOGO stuff in school.
Same story with Adobe Flash.
Nothing available today matches.
Honestly.. Yeah.
Modern tools operating at higher levels of abstraction allow teams to create large amounts of functionality very quickly for more platforms. This changes the economics of software supply.
It's a fallacy to look at an app and say "I'd like this more if it were native instead of written in Electron" because Electron is part of how that app was delivered with that functionality at that price point. It's like ordering a $20 pub steak and saying "I'd prefer this steak if it were A5 Wagyu."