341–350 of 384 posts
Earlier quoted context omitted.
RAM is cheap, my time is not. VSCode is the best game in town (for me), and my 32GB computer has no problem with its RAM requirements. Even 8GB would be enough for VSCode depending on what else your toolchain requires.
> RAM is cheap RAM is cheap for you. It's always silly when people bring up their top-of-the-line computer into discussions about performance. Software shouldn't be just for the top 1%.
Earlier quoted context omitted.
I'm a bit curious about what's wrong with Bluetooth on the web. Is it just because Safari and Firefox don't support it yet?
It’s important to note that it’s not a matter of effort for Firefox. They’ve decided that the it’s not something they want to implement[1]. The reasoning is that they think it allows low enough level access to potentially mess with devices who weren’t made to be resilient to malicious input, and didn’t like that the proposed method of allowing web Bluetooth is based on a default allow policy with a blocklist, which m…
Then again, almost every time a Firefox thread appears here it gets filled with comments pointing out how low its adoption is so I guess "well, yeah" sums it up (he said, commenting from Firefox)
Earlier quoted context omitted.
I dislike apps and avoid installing them in general terms. They're bloated and frankly I have better things to store on my phone (mostly music, but also photos, conversation histories etc). I do not need an "app" for submitting a form. Looking at a website. etc etc My favourite thing about using a website? It can't send me attention grabbing notifications. It can't harass me for perms. I'm 100% an outlier. My friends…
Same. I have only a few apps installed that my phone didn't come with. No games. No social media apps. Even email I access via Safari. If I absolutely must use an app for something, I typically install it, do what I need, and then delete it.
I believe it's primary use case is storage efficiency but it works perfectly fine in your use case of preventing the code from running while you're not actively using it
As the solo founder of a couple of 'popular' websites I get asked regularly if I want to create an app. When I ask them what they want the app to do what a website can't, they can't name a single USP, especially now notifications work on all devices. And really, who has the time to maintain a website and two apps? Or rebuild a decade old platform in a janky cross compiling solution like Flutter that is always on the…
> And really, who has the time to maintain a website and two apps? Or rebuild a decade old platform in a janky cross compiling solution like Flutter that is always on the brink of being sunsetted? I'm a solo dev for a startup and this is something I always hammer home to my non-technical co-founder. I tell him that spinning up an app that would have parity with our current app will not only take close to a year for a…
He is just trying to piggyback an another distribution channel to get more visibility and another place to be found. It has nothing to do with UX.
Earlier quoted context omitted.
Yep. And it gets worse. Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing while the drawbacks have only been somewhat mitigated. We're getting to the point where brows…
Mobile operating systems have really good security models, and native apps are even more isolated compared to the websites. I really wish that we would have similar isolation options on desktop/laptop OSes.
Earlier quoted context omitted.
Apple RAM is expensive. Every other kind of RAM is pretty cheap. 32GB DDR4 can be had for under $30, and 16GB DDR4 can be had for about $25. I'm not sure who you think has a computer, is developing software, and can't afford that. Maybe someone in India, I guess. Too bad if that's you, but "top 1%" is a laughable claim when RAM is so cheap. 16GB of RAM is nowhere near "top of the line". You're just trolling here, "hn…
> Apple RAM is expensive. Every other kind of RAM is pretty cheap. 32GB DDR4 can be had for under $30, and 16GB DDR4 can be had for about $25. I'm sure that's pretty cheap for you , yes. Taxes and other fees tend to increase those prices outside the US, by the way. > I'm not sure who you think has a computer, is developing software, and can't afford that. There is a market for lightweight code editors, isn't there? >…
And not being able to afford $30 as a developer for a decent amount of RAM puts you in the bottom 1% of developers globally. Yes, I made that up just as you are making up your own numbers. But as I explained, you don't need 128GB of RAM, you don't need 64GB of RAM, you don't even need 8GB of RAM, you can still develop with VSCode with 2GB of RAM. Nobody is handing out free RAM, so if you need more, save your rupees, or pennies, or euros, or whatever. The daily cost of it spread over time is miniscule for anyone on the planet, and you will get back the investment in saved time.
Earlier quoted context omitted.
Hi there! Indeed, QML is very buggy. But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications. So, many bugs get fixed through open-source contributors (KDE, individuals, etc) And that might be a big reason why non-critical bugs don't ge…
> But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications Yep. That's precisely the point, you get all this stuff from a billion dollar project for free. I really would not mind writing some C++ instead, even if it was more difficult. I…
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
[1] https://github.com/Open-App-Library/QBasicHtmlExporter
In 2015 Robin Hutcheson partnered with a vendor, ParkSLC, to deploy an iOS and Android app that is the only possible way to pay for street parking in many areas of downtown SLC. She seemed awfully proud of herself in this announcement, bragging about how it hasn't really fallen over much in the first few months in the field:
https://archive.org/details/Press_Conference_-_ParkSLC_Mobil...
But that's not the bar. For public infrastructure it needs to continue to function for the life of the system. So let's fast-forward to Kubecon 2024 in SLC. I'm staying with a friend further south, so I had to rent a car. I pull up to a restaurant where I'm meeting some business partners and park right here:
https://www.google.com/maps/@40.7647761,-111.8938564,3a,75y,...
In a past life there would be a parking meter right there at the stall where I could drop in some coins and be on my way. Now let's talk about how Robin's fancy new parking system is going now that we're in the app-infested future.
It's November in the early evening, so it's not exactly warm and cozy. The first problem is that the little blue post you see in the Google Streetview back in Oct 2022 isn't there now. So I have no idea what the stall number is. Fortunately the blue post for the spot behind it is there, and I determine it's counting up going north. I guess the stall number is one higher than the one behind it, and that's all I have to go with.
I walk up to the super-advanced new fancy kiosk and hit the button to turn on the screen. Icons on the screen invite me to start tapping away to register. No response. The touchscreen functionality is completely broken.
There's a sticker with a QR code and a website, parkslc.com. Okay, maybe I'm not being phished here. Better do a quick web search to make sure. Yup, ParkSLC appears to be The Thing. So I go to parkslc.com to get the link to the app and discover that it's only distributed via Google Play. But I'm running GrapheneOS because I don't want Google spying on me. So it looks like the only way I can park on W Temple in downtown Salt Lake City is to allow Google to spy on me?
Great. Well, I do have another dummy account on the phone with a sandboxed install of Google Play with a temporary account I created just for that user on that phone, so I was able to attempt to install the app. It still "phones home" to Google but maybe without enough information for Google to determine who I am. But at that point I'm greeted with an error like, "This app was designed for an older version of Android. Go pound sand."
Great. So this app isn't even being updated, I guess. I wonder if other people with newer Android devices are getting this same error. Regardless, by then it's been about 7 minutes while I've been sitting on a concrete bench in the cold trying to pay to park so I can go to my business meeting. So far both the kiosk and the app have been dead ends.
My last option, it seems, is to browse to parkslc.com and see if there's a way to pay via Firefox. After scrolling around more than I should have had to I finally find a "Pay Online" link and follow it. It asks me for a phone number, so I punch that in. I get an SMS. I have to create a pin. It asks me for a "Zone Number." I punch in what I guess it's supposed to me. Then it prompts me for my credit card. I start punching that in, but when I get to the drop-down menu to select the year of expiration... nothing. No response to my taps. No ability to just type in the year.
Great. So the website doesn't work with Firefox. Another 3 or 4 minutes wasted on another dead end. Okay, so I launch Vanadium and restart the whole process again. This time around the drop-down menu worked, and I was finally able to complete the process, after futzing around with a broken kiosk, a broken app, and a broken website for 12-13 minutes out in the cold night air of Salt Lake City.
As the app-based system she deployed in SLC fell into ruin behind her, Robin has since flown on to be the administrator of the Federal Motor Carrier Safety Administration. Good for her! I'm sure there's blame to be passed around here, as it's in the current transportation administration in SLC to maintain the system in working order. I just wonder how many spare kiosk touchscreens they have lying around from a system built in 2015. And I wonder if anyone still has the source code for the app that doesn't work with newer versions of Android. Or if there's anyone around who can even push an update any more. Obviously Robin didn't seem to do enough to ensure the system she deployed would end up being robust and reliable public infrastructure just 10 short years down the road.
And not to pick on Robin too much, this is endemic in our institutions everywhere. As an industry we need to do much, much better. One lesson from my anecdote is that there should always be a website, and it should be as simple and compatible as possible, especially if it serves as public infrastructure.
I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…
I can't say about gaming, but a huge chunk of popular apps out there are PWAs with a native wrapper. If built well people aren't even going to notice.
Earlier quoted context omitted.
Any text editor that struggles to load a large text file on a modern computer is, simply put, inefficient. If 20 years ago they managed to write programs that could handle such cases and today many (web) apps fail at this task means we're going backward. My point is that it's much harder to write efficient code in the web ecosystem because you're bound to specific abstractions from the browser. Once deviating from sa…
> Any text editor that struggles to load a large text file... Define "large". If it's bigger than the biggest text file I'll ever open, then I don't care. My point is that "efficient" code isn't absolutely necessary in many, many cases.
notepad++ solved this problem 20+ years ago.
I agree it’s an uncommon use case but it’s kind of sad when an app struggles to open a file like that on a modern machine in 2024. Just sad.