I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.
> share 30% of my revenue with them for barely any reason Does the App Store collect sales tax and remit on your behalf? If it does then I think it's worth it or face registering both in the EU and UK ($0 tax threshold) as well as 50 US states (once you hit the allowed limit) will take you a long time.
Did we lose our way in making efficient software?
191–200 of 515 posts
Re: Did we lose our way in making efficient software?
#192In terms of frontend, which the post focuses on (Google Docs and a 30MB doc), I guess I'm conflicted. While I tend to favor native apps + web pages, I'm also a daily Tiddlywiki user, and I really think web apps have their place (heck, one idea I'm working on is a lightweight local server that lets you run web apps like Tiddlywiki). But without a doubt, Tiddlywiki is more resource intensive than Emacs (my go-to for notetaking when I'm not on TW). My tab for a 6MB Tiddlywiki file uses 155MB of RAM, and my (heavily customized, dozens of open buffers) Emacs session uses 88MB. So I do think the author has a good point.
[0]: https://fennel-lang.org/ [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki [3]: https://makoserver.net/
Re: Did we lose our way in making efficient software?
#193One problem is that we use a full word processor that's powerful enough to typeset a book to distribute basic text documents when simple markup would be just as readable, and more easily usable on a wide variety of devices (and easier to make accessible for disabled people) So when my doctor sends me a one page checklist of how to prepare for a procedure, I have to open it in a powerful word processor and since it's…
On Windows, Wordpad was plenty enough for most needs, came preinstalled for free and barely consumed any resources, but I understand it's no longer shipping with Windows. Office 365 is now where the money is, even for basic needs.
Re: Did we lose our way in making efficient software?
#194In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.
Re: Did we lose our way in making efficient software?
#195“My father told me he wanted Microsoft Word on his laptop. So I told him to use Google Docs instead. When that turned out to suck, I installed Libre Office instead.” Why didn’t you just, like, get him Word? Why did you make him try to use a shitty web app that assumes everyone’s computer is brand new, then install an open-source program that’s going to be constantly playing catch-up with Word’s updates and may cause…
Aren't Microsoft trying their best to turn Word (and the rest of Office) into a shitty web app?
Re: Did we lose our way in making efficient software?
#196This seems to take a moral stance that efficient is better. However that’s not always practically true. Efficiency often means inflexible and brittle with respect to change and time. Abstraction generally trades efficiency for ease in change over time, or parsimony for the developer in exchange for expense at runtime. If it doesn’t matter - it doesn’t matter. If the goal is making a document format that is flexible e…
Except the post you're responding to was literally in response to a user problem trying to edit a 30MB document in Google Docs. So it very much does matter, from the user perspective.
> Comparing Google Docs to a program hosted on an Apollo era flight computer is obtuse to an extreme, and I would rather write my collaboratively edited documents with Google Docs than Apollo era flight computer any day no matter whether one is less parsimonious than the other.
Straw man. The post compares Google Docs to LibreOffice (a competing product), and points out that LibreOffice solves the user's problem (editing a 30MB document) and Google Docs cannot.
Re: Did we lose our way in making efficient software?
#197Earlier quoted context omitted.
> It was the path of least resistance, so we took it. Well said. I believe many of the "hard" issues in software were not "solved" but worked around. IMO containers are a perfect example. Polyglot application distribution was not solved, it was bypassed with container engines. There are tools to work AROUND this issue, I ship build scrips that install compilers and tools on user's machines if they want but that can't…
It's very platform specific. MacOS has had "containers" since switching to NeXTStep with OS X in 2001. An .app bundle is essentially a container from the software distribution PoV. Windows was late to the party but they have it now with the MSIX system. It's really only Linux where you have to ship a complete copy of the OS (sans kernel) to even reliably boot up a web server. A lot of that is due to coordination prob…
Re: Did we lose our way in making efficient software?
#198Again and again people complain about this. But it remains a fact that essentially nobody actually wants this. Developers certainly like to have their completely integrated, connected and universal computing platform (the web). And users do not seem to particularly care about performance as long as it is good enough . And that is exactly the standard that is set, software is allowed to be so bad that it doesn't reall…
Yep. The most successful startup I worked at had a SPA that downloaded 5MB bundle and preloaded a bunch of data. Took nearly 10 seconds to startup. Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining. They still raved and raved about that software because it solved an ex…
The problem with the long startup is that it tends to cloud any discussion on performance. Code loading and parsing is basically the biggest bar in the app-perf breakdown of your profiles, and thus spins this narrative that this is the thing to optimize for, because it's the biggest bang. Rather than say, responding to user selections, reducing jitter and sluggishness while scrolling, etc...
I'm starting to believe that for a large class of apps, developers should look at it as if they are writing video games: the user will tolerate the spinner before the level, but then it needs to be silky smooth after. And the _smooth after_ requires a whole class of other optimizations; it's striving for a flat memory profile, it's small ad-hoc data transfer, it's formatting data into usable layout at lower levels in the stack, it's lazy loading of content in the background, etc... Those are the areas where web-devs should be looking a
(again, this only applies for that sort of SPA; e.g read-only content, blogs and such, should display _fast_).
Re: Did we lose our way in making efficient software?
#199I'm not going to deny that we could do better, but it is more nuanced than that:
OP uses Word as an anecdotal example, but Word is not designed with a goal of being optimized. It is designed with a goal of being backwards-compatible to decades of history.
We cannot assume that all software shares the same goals because they simply do not. When we look at the problem any given software is trying to solve, performance optimization is almost always important, but almost never #1... #1 is "solve the problem". Doing it fast is always secondary to doing it at all.
Re: Did we lose our way in making efficient software?
#200I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.
> share 30% of my revenue with them for barely any reason Does the App Store collect sales tax and remit on your behalf? If it does then I think it's worth it or face registering both in the EU and UK ($0 tax threshold) as well as 50 US states (once you hit the allowed limit) will take you a long time.