Hacker Newsnew | past | comments | ask | show | jobs | submit | prizzom's commentslogin

How do you downvote garbage non-content like this?


I think the missing piece here is that onramp contains the definition of a very simple virtual machine. One that the reader could implement themselves (though a reference implementation is also provided).

After it incrementally builds on itself all the way up to a fully functional C compiler.


Honestly, I don't know what you were expecting. QT sucks pretty much everywhere. For universal UI I think the three choices are native (and if you have to pick one start with iOS because of reach and the fact that iPhone users pay for apps), React Native, or Flutter.

The problem with 3rd party frameworks is that you're always playing catch up. So if you're soloing it / developing a proof of concept you're good but if you're a real business you'd have a hard time selling me on anything but native.


Businesses don't necessarily want to maintain 10 versions of the same thing just so that it can run on different platforms. It is costly and they don't like costs.

You're thinking from the perspective of a solo developer making an ios app and nothing else.


Seems like you are thinking from the perspective of "internal enterprise app, possibly sideloaded to use inside warehouse", or something along those lines. Those can really look like anything, but there is a high chance it will be designed and tested on a single platform anyway (since the company can purchase specific devices), so why bother with multi platform. I have seen plenty of cases like these in my work, and those apps always suck and are eventually replaced by native ones.

If you are building an app which is supposed to be used by regular end consumers, native is the only real way to go. And as prizzom mentioned, choosing native iOS toolkit is a good idea if you want to sell, because Android users are not very keen on paying for apps.


Have you seen apps?

slack uses html, steam uses extremely slow html… big companies do not care.


Slack doesn't use HTML for iOS app, it's native.

Steam also recently remade their apps. Authenticator and chat for steam uses native ui toolkit (styled to look like Steam desktop app). Store browsing still uses html frame, but that is less relevant for Steam on mobile.


As soon as someone spells it QT and not Qt, I dial down my valuation of their opinion


Things I like about this article:

+ A focus on viewport size instead of screen size.

Few people browse websites in full screen in fact "Full Screen" browsing is used almost entirely for people using a web browser for presentations or physical kiosks. A completely different use-case than regular desktop browseing.

I loathe the fact that when I tile my windows to half my screen size the website "helpfully" switches into a tablet/mobile layout. Incidentally WCAG (which I consider a well-meaning but ultimately largely useless set of guidelines) can be blamed for a lot of this nonsense.

Things that I hate about this article:

- Like many "analysis" articles they start with a misleading validation of their sample size. 120,000 datapoints is not terribly big.

- Implying that these screensizes can't be grouped together. Resolutions #3 and #4 are practically identical 393x660 vs 390x664 is essentially a rounding error.

- Implying that any sane person should be considering how their desktop/mobile website should be displaying on a smart watch. This is totally different use case and (admittedly having never built anything for a smartwatch) I assume (hope?) that unless you've somehow identified your design as being smart watch compatible the browser is very liberally going to strip most of your layout and styling anyway to just text and headings.

- Implying that anyone should care about the minor differences in screen sizes. As a veterean of the Flip-phone days when the scourge of "form over function" phones (think Beyonce clamshell phone) was at its previous highest. There is no solving this problem. Apple swooped in an took a strong-armed approach to screen sizes that made developing on iOS EXPONENTIALLY EASIER than supporting MIDP or Android.

- A useless masonry visualization of viewports in a garish orange/purple contrast that is impossible to read. Thanks for nothing.


Now a days I almost always work fullscreen, even when programming if I have docs and vscode I'll just tab between the two. I don't even use multiple monitors cause I find I end up causing myself some pain from bad posture.

I feel like I must be a minority, My workflow is almost entirely switch desktop+ switch tab.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: