Live data from Hacker News

Is the madness ever going to end?

unixsheikh.com

211–220 of 629 posts

Re: Is the madness ever going to end?

#211

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…

To be fair, Discord is only as popular as it is because Microsoft was insistent upon alienating its Skype user base to the maximum extent of its ability.

Re: Is the madness ever going to end?

#212
post #116

> The entry barrier to programming needs to high! Programming is engineering, it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers and operating systems are made of magical dust. Reading this, made me wish the entry barrier to writing was higher. I mean you should definitely have a copy editor and proof reader to make sure you are not leaving ou…

I'm not normally one to fuss much over typos, but I similarly found it hard to take the author seriously when he makes a typo in the very same sentence that he attempts to extol the superior intelligence of IT professionals of yore. > In the past IT people, whether we're talking about programmers or something else, where very clever people. If you're going to talk down to people and insult their intelligence, please…

> in the very same sentence that he attempts to extol the superior intelligence of IT professionals of yore.

Whenever someone tries to express this sort of of thing, I always have to wonder whether these superior professional of yore are pioneers of the industry back in days when commercial commuting was just starting to bud, but it’s always some guys from the mid-late 90s who seem much angrier.

Re: Is the madness ever going to end?

#213

I feel comfortable with asserting that the author has never worked on a complex web application. This web-dev hate borders on pathological: this is a guy that seems to specialize in Unix/Linux tooling, doesn't have a single tutorial on web app development [1], and yet has an intense hatred towards a space that he barely understands. These types of arguments are incredibly embarrassing to read, not only because they b…

I don't necessarily disagree with your take but I think you should be making substantive counter-arguments to what the author wrote. Your post is essentially just attacking the author and of little substance in itself.

The original article isn't substantive. I mean, c'mon, the entirety of the argument against Electron apps is

> They eat up all the memory you have and still ask for more. They constantly crash and has no value over a native desktop application what so ever - well, perhaps with the only exception that now a 2 year old baby can make something shiny that you can click on with your mouse.

I'm kind of a curmudgeon about Electron apps, and I'm still reading that and going, "I can't think of a single time I've had an Electron app crash on me, what kind of genius two-year-olds are out there developing in React Native, and what kind of juvenile complaint is 'make something shiny that you can click on with your mouse' (as opposed to native desktop apps, which as we all know are matte black and only take keyboard input). Also, for Strunk & White's sake, 'whatsoever' is one word, and 'they' goes with the verb 'have', not 'has.'"

And the whole article is like this. He goes on to complain about PHP templating systems because PHP itself is a templating language, and sure, yes, argument to be made there! Just…not this argument. Most PHP templating systems compile their templates to pure PHP, so if anything is making "the application load four times as slow" it is not that. Then he goes on to tell us "all web servers has a build in router" -- there are either two or three syntax errors in that seven-word sentence, depending on whether you count "build in" for "built-in" as one or two -- and rails against how web frameworks are eschewing web servers' built-in routers (by which we mean…URL requests?) and instead insisting on implementing the revolutionary new (checks notes) front controller pattern. Yes, you're right, web development would be so much easier without that, wouldn't it? Also, while we're here, let's talk about line numbers. Why aren't we still using line numbers? Named functions are for wussies. In my day, we used GOTO both ways uphill in the snow and we liked it!

Wait, sorry. Where was I?

Anyway, it's actually pretty hard to make "substantive counter-arguments". The article is badly argued and badly written. I would not normally be quite so much of a jerk about the numerous syntax errors, except that this ends with a suggestion that people, you know, pay for this writing. I don't expect perfection (God knows I make tpyos all the time), but the closing paragraph starts with a sentence that literally has no verb. If your entire thesis is "IT people need to do better," well: engineer, heal thyself.

Re: Is the madness ever going to end?

#214

> Programming is engineering Is it? Genuine question that I've been asking myself for the past several years: In what senses is software engineering actually an engineering discipline? If you make a project trade-off for the sake of code maintainability, is that based on empirically tested knowledge or following a design pattern guided by an artisan's intuition about how code will be interpreted?

Programming and Software Engineering are related but not the same thing. There is yet another thing - coding, which is also something else. Yes, software engineers do program, and programming involves coding. But someone who has come up with, say, a computational algorithm or a formula may ask you to implement it in a form that a computer (or, more likely, a compiler) can understand. That’s coding. Programming, on the other hand, is what we do when we need to solve a specific problem, or a part of a problem, by writing a program or a library of modules, which involves several steps such as choice of data structures and algorithms that make it possible to solve the problem efficiently. Finally, software engineering is building software from various, potentially many, pieces which include custom program modules as well as those written by third parties. The degree of “engineering” involved grows exponentially as we go from mere coding to programming to, well, software engineering.

Re: Is the madness ever going to end?

#215
post #75

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…

I can’t think of any reason not to use Slack exclusively as a website. I’ve been doing it for years now, and it’s a better experience IMO. For Teams, the only disadvantage is you can’t share your screen and video simultaneously when running as a tab; but I find the screen sharing experience to be better otherwise when running as a browser tab. Also: all of these “shitty” Electron apps work just as well on Linux as th…

Lots of tools are better as websites - however underhand motives often mean mobile apps get pushed more and have done for years. Inevitably someone pops up to say "but what about essential feature X that you can't do well on the web" even though it's rarely genuinely essential or it's a worthwhile trade-off.

My GP surgery uses a fantastic website for streamlining comms where you'd never want to install an app that would be rarely used. It's so well integrated that they could ping me the link during a call and I had details back to them seconds later so I got a decision there and then as we spoke rather than breaking flow state and delaying it by days as they used to.

Funnily enough my dentist has a similar kind of app relating to pre-appt preparation - perhaps there's a fight back for common sense in these slightly more serious fields?

Re: Is the madness ever going to end?

#216
post #93

Earlier quoted context omitted.

> It's an attempt to save the more expensive thing (engineer time) for the cheaper thing (RAM) especially in the face of rapidly improving hardware (which may no longer be true). It's worth noting here that Electron trades engineer time you pay for against RAM your customers pay for. On the other hand, Electron got things to a state where Linux is often supported and where I can usually run the whole app well sandbox…

Customers ultimately pay for engineering time, too.

it is an interesting point though. Like I've tried to think of elegant solutions where we can get the customer's browser to preprocess work for us so we can reduce our total lambda/ec2 time. for example one could have their browser generate the thumbnails for an uploaded photo instead of just uploading the single image upload. After all, 1000s to millions of browsers can make short work of something that might be heavy on AWS.

Sadly I've yet to find many FE engineers that are all that experienced with WebWorkers

Someday this could be a good use of all those free CPUs

Re: Is the madness ever going to end?

#217
post #18

It will end when people like the author drop their victim mentality and start putting their own ideas into practice. It seems that this person is content with yelling on the sidelines about how good and efficient things used to be. Meanwhile, the shitty tech is winning. According to this author, bad code and bad tools and bad frameworks are reigning supreme over real engineering. Why? "The situation is really bad for…

> drop their victim mentality and start putting their own ideas into practice

How? Do you send pull requests to thousands of projects to delete their codebase?

Re: Is the madness ever going to end?

#219
post #107

Earlier quoted context omitted.

Ii run Slack outside of a tab and in its app format because it's easier to navigate to using keyboard shortcuts and OS level features. That may not be enough for you, but it's plenty reason for me, and I imagine many others.

Slack in browser tab user here. Got sick of the app and how slow it was pretty fast. It's just not worth it.

Isn't the native app just the Electron code repackaged for native, and not a true ground-up native app at all?

If the code is based on HTML/js/CSS and not Swift/Obj-C/C++ (etc) then you're really creating a web app running in a native microbrowser.

Which is very much not the same thing as writing OS and system calls directly - not least because it will be much slower.

Re: Is the madness ever going to end?

#220

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…

> I’m very critical when a company like Slack cannot find the time and resources to make native clients. It's not a matter of finding resources, it's a matter of finding that to be the best use of resources. Obviously they could have native apps for major desktop platforms with the energy put into the Electron app, and performance would probably be better, but would they have feature parity? And if you increase the r…

I agree with Waterluvian.

I believe feature parity is less important than the basic HCU of a responsive interface for the most basic features. Some of the most recent features they've added, like the "WYSIWYG"ification of the input box were arguably more disruptive to my use of Slack than any benefit it offered. If a good baseline performance for basic features like chat, image sharing and calls are achieved, then later into the lives of these clients the kinds of features that would lose out on parity ought to be more niche. Things like the presence of huddles (arguably just a different kind of call), bot command interface tooltips, and the ability to draw on shared screen.

Maintenance is a real challenge, but one that delivers the value of good HCU and performance on dev machines; a worthwhile operating cost to provide a product that is harder to unseat. Better performing programs also save memory for the rest of the user's programs like containers and IDEs, which can get pretty resource-hungry.

I think with the recent chip shortage, supply chain issues and potential catastrophes in the future with Taiwan, there's a pinch that will force us to be more resource efficient on a per-machine basis at least for a while. And we may find out that there are miraculous things we can do on the individual machines we have, with what felt like very little processing power, once we're forced to adapt away from overvirtualized, shallow quick-to-market apps.

EDIT: on further consideration, I'm wondering if it's not possible within things like electron, to have some kind of "just in time" style hybrid infrastructure where the most basic features are augmented to run native code quickly for the most heavily used parts on the most common platforms? I don't know enough to say.

Post reply on HN