Linked by Thom Holwerda on Mon 7th Aug 2017 20:29 UTC
PDAs, Cellphones, Wireless

The Verge does this thing where they list what they consider to be the best laptop or phone or whatever, and they state the Samsung Galaxy S8 is the best phone for most people.

Samsung's Galaxy S8/S8 Plus is the best phone for most people. It's available across all four US carriers and unlocked. It has the best display on any smartphone right now, a head-turning, premium design, a top-of-the-line camera, reliable battery life, and fast performance. Thanks to Samsung's popularity and the support of all four carriers, the S8 also has plenty of accessories, from cases to battery packs to wireless chargers, available to it.

You can definitely make a case for the S8 being the best phone for most people, but personally, I still consider the iPhone to be the best, safest choice for most non-geeky people. Personally, I prefer Android, and for my personal use, iOS on the iPhone is an exercise in frustration - but iOS provides a more consistent, all-around phone experience that remains fairly static from phone to phone, it's a little simpler to grasp than Android, and Apple has an excellent support system in many countries that's far better than Samsung's hands-off let-the-reseller-handle-it approach.

I wonder - what do any of you consider the best phone for most people? If one of your non-geeky family members seeks your advice, which phone do you suggest they get?

The Verge named the Surface Laptop the best laptop, which I find a baffling choice. It's new and unproven, so we have no idea how it'll hold up over the next few years. An odd choice for sure.

Thread beginning with comment 647844
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[10]: iPhone
by woegjiub on Thu 10th Aug 2017 23:30 UTC in reply to "RE[9]: iPhone"
Member since:

Which is why you use a terminal-based slack client. Not seeing the issue here.

Needs graphics? Belongs in a browser.
Doesn't need graphics. Belongs in the terminal.

Reply Parent Score: 2

RE[11]: iPhone
by Alfman on Fri 11th Aug 2017 05:05 in reply to "RE[10]: iPhone"
Alfman Member since:


Which is why you use a terminal-based slack client. Not seeing the issue here.

Needs graphics? Belongs in a browser.
Doesn't need graphics. Belongs in the terminal.

This distinction is totally arbitrary - there's nothing exceptional about a terminal. I personally implemented a terminal emulator in the browser. The problem of course is that browser networking is more limited than native applications. For example the terminal connection had to be proxied through a server. This was not a design goal, in fact it was an "anti-goal" but forced by browser limitations.

The same goes with VNC clients. There are times I'd very much like to be able to run a VNC client in the browser (which by the way is a "graphical" app), but it isn't possible to run it as a pure web app because of browser limitations. While there are HTML5 VNC clients, they are forced to overcome browser limitations by offloading functionality to code running elsewhere. In practice this is problematic because while a client can connect to the remote server, but the remote server may not be able to connect to other devices on the local LAN as a native app could.

What needs do you have that require your software to run outside of the browser?

Bittorrent is an example.

Other applications don't work because they don't have access to the file system. For example, a media player that automatically indexes your files. Heck, we can't even get browsers to agree on codecs.

SIP is another example of a protocol that can't be implemented in a browser because of browser limitations. Browsers are limited to WC3 standards (and proprietary extensions), but the world is full of standards that aren't covered by WC3.

If I want to write an app that displays SNMP status messages, I have to rely on out-of browser code to do it.

I was working on an SDR project, where I needed to access a USB radio, HTML5 doesn't have a radio API.

I develop HVAC software for one of my clients, and we've actually been moving to HTML5 for the UIs, but we're forced to sideload a local native daemon because the browser can not access the SQL database and is unable to access the HVAC control units directly. It's absolutely crucial these systems work without internet (they don't even have internet access).

There was an effort to standardize websql, but the WC3 reached an impasse. It would never be as feature-rich as a native database anyways.

In theory, even if you were fully committed to keep adding more and more APIs to the browser to address it's limitations:
1) This will never cover 100% of the use cases.
2) The browser will grow more and more bloated, will become as complex as a whole operating system
3) The attack surface will end up growing much larger than it is today.

I don't mind that you'd like to promote HTML5 for more things, but for better or worse people do more with computers than just use the browser. Even if you personally don't, you cannot speak for others. This really is my main gripe with your posts.

It pisses me off to see people with multiple tabs or multiple windows open at once. Open something, work on it, close it. You've got a fast computer for a reason. If something takes more than 5 seconds to open, throw it away (see: IDEs, etc.)

You keep making the same mistake of thinking what's good enough for you is good enough for everybody in every case...but it's not. I like tabs and find them useful, and I could not work efficiently without multiple windows because many of my tasks require me to go back and forth or examine data side by side. It would be unproductive to close windows constantly rather than simply keeping them open and switching between them.

Client-side javascript (and soon, wasm) can definitely run offline and access local files. It's likely a matter of your tools of choice not having been written as webapps yet, as opposed to it being a shortcoming of the platform.

Yes, but again with major caveats and limitations

I'd be impressed if you could point me to a backup application that works 100% from a standard browser with no native helper processes. Or even just a local file search utility would be useful.

Edit: To be clear, browsers could solve all of these limitations, however it's at odds with their goal to make untrusted code run safely on the local machine. Consider how "old java" and activeX were shunned for their large attack surfaces. This is the reason why browser apps are unlikely to ever become as capable as native apps. While you may not care about these native capabilities, there are some of us who do. Fair enough?

Edited 2017-08-11 05:17 UTC

Reply Parent Score: 2

RE[12]: iPhone
by woegjiub on Fri 11th Aug 2017 07:41 in reply to "RE[11]: iPhone"
woegjiub Member since:

For most of those use cases, I use terminal apps (especially music, searching, torrents etc.), but there are certainly users who sit in a middle zone, not satisfied with what web apps can do, but not comfortable with using terminal daemons and tools.

I do see the majority of users being able to be completely satisfied with web apps in time, but I'll admit that there is a subset that will want GUI apps that have native functionality.

Reply Parent Score: 2