So if you need a framework so you can pretend to have a native version of the application

No, you need a framework so you don't need to reinvent the wheel for every project you work on. With Sencha's frameworks, I can write a pretty slick-looking responsive site in a few hours (or days, for something larger) that would take literally months to roll on my own (and for the record, yes, I can and have rolled my own, back in the dark ages).


why not just focus on having a webpage instead of a shitty application which is just a web page?

Two reasons. First, it increasingly doesn't make sense to force your end users to download and install potentially untrusted code - never mind needing to maintain separate versions for every major platform you target (oh, you want this on iOS and Android and Windows and Linux and OS X, etc?), when you can accomplish the same result in one nice tidy webapp. Second (and you can fairly call this a matter of personal preference), IMO just about everything looks like crap in a browser on a phone, and even that assumes the browser handles it correctly (yeah, like I want to support Chrome and FireFox and *shudder* MSIE and Dolphin and Safari and Opera, etc - Going right back to all the joys of supporting multiple OSs, woo hoo!).

The concept of a "webpage" hasn't limited itself to some statically published version of a document-with-markup in over 20 years; that model lost so thoroughly that pining for it doesn't even count as beating a dead horse anymore, more like trying to clone a mammoth from frozen DNA.


This sounds like lazy people who want to claim they have an app, when all they're doing is pointing to a web page.

It really doesn't matter to me what you want to call it, whether an app or a webpage or a widget or a three-handled family gredunza, if it accomplishes the intended goal... All just a matter of using the right tool in your box for each task - Sure, you can hammer in a screw, but sometimes a plain ol' nail will do the job just as well.

Sounds like a job for.. Bookmrkr! Do you love bookmarking? What to broadcast your bookmarks to your social network? Check out Bookmrkr!!

If only it were that easy. The problems with cross-platform development are myriad. The LCD experience has already been outlined, so here are the others:

1) It's write once, TEST everywhere, and you can't debug the code you actually wrote -- only the specific translation of that code into native code. And that sucks beyond words. It can be incredibly time consuming to the point where it easily erases any time you saved in development. And the longer the lifecycle, the more of your budget this is going to consume.

2) On a related note, profiling and performance tuning is a bear. If you do anything that requires performance, cross-platform is the wrong way to do it.

3) The potential for bugs is twice as high, because now you don't just have to worry about bugs in the native SDK, but also in the abstraction as well. While the OEM can generally afford to test the hell out of their SDKs, cross-platform suites have much less resources at their disposal. And it shows.

4) You are always playing catchup. New features take longer to implement, because you have to wait for the third party to either implement the new feature, or to implement it right.

5) You're needlessly adding another layer of dependence. None of the "popular" third party platforms are anywhere close to guaranteed that they'll be around in a month, or 6 months, let alone 2 years from now. If your favorite library goes away, you find a new one and make a few changes. If your entire SDK goes away, you're fscked.

If your software doesn't matter at all, if it's just a hobby, has no business case, and you have no plans (or potential) for going commercial, then by all means, use whatever development tool strikes your fancy. Personally, I would never recommend that anyone use cross-platform tools for anything they plan to support indefinitely. Even for a prototype or an MVP -- too often the prototype becomes the codebase for the final software, despite prior assurances to the contrary. Don't waste effort developing something you can't build on, unless you have no other choice.

It has RDA of calories, and if you're drinking soda, then 100% of the calories are from sugar (or corn syrup, for most soda in the US). There is no RDA for sugar specifically because there are no scientific guidelines, not because the FDA is part of some grand conspiracy to keep it a secret.

What? Most artists never make anything on record sales, they get their money from tours, doing commercials...

There's a handful of them on the left coast, and they're putting in another handful on the right coast. Statistically nobody in the middle of the country buys interesting vehicles anyway. Toyota is about to start selling a FCV finally, and they're licensing their fuel cell to BMW and it will probably make it into an i5 in a year or two.

The real problem with hydrogen is that it is horribly annoying at best. It's just dumb on every level.

I find gwebapps are slightly more usable in Chrome than Firefox. I use Chromium on Linux and actual Chrome on windows, so that gmail and gmaps work properly.

Amazon is probably doing something bad and stupid as usual. I had to remove their store app from my devices because it made them unusable. All of them. Locks, hangs, FCs, even in other apps. Amazon can't code their way out of a nutsack. You can see this in their site, too. They break it every few months.

That's not what we're talking about. We're talking about installing a bootloader and using it to install a community-tested, community-developed replacement for the OS. Something you can't do on iOS, even when you need to, because Apple has shit it up.

So like I said, you have no idea what you're on about. You just download it and install it. You don't build anything.

So again, like I said, you get a well-supported device and then you install AOSP (I'm running SOKP on my Moto G XT1063) and then you don't have to dick with it. Maybe eventually I'll check back to see if there's an update. Usually you can dirty flash those, so there's not much hassle involved.

All you did was demonstrate your ignorance.

Confirmation bias.

Yes, they didn't use the policy against farmvillains, only when it was important, like against trannies and whatnot. But their rights aren't important to you, so you didn't hear about that while it was happening.

What? I say, what, son? That shit went away with ISA, and it had nothing whatsoever to do with pulseaudio. Nothing. Pulseaudio did nothing to mitigate that because none of those issues went away if you still have that hardware, because pulseaudio does not handle that part of the audio system. Do you know anything about the software we are now discussing?

You know what's different about consumer and pro audio? Nothing. As it turns out, consumers also want high-fidelity audio, and they want to be able to mix multiple streams. The only difference lies in what the industry is willing to sell us.

Actually, pulseaudio has notably drained batteries in the past, because shitcode.

Yes, it absolutely does. It ties functionality together in a way which is designed to be difficult to tease apart specifically because of NIH.

We have seen this proven true with pulseaudio.

Which should surprise nobody

Which it hasn't, and many slashdotters have given examples in this and other systemd-related threads, which you have willfully ignored because they don't fit the narrative you swallowed.

Bullshit. It's much, much slower now, not least because the subset of printer drivers included is pathetic. What's pathetic about the list of supported printers that extremely common printers supported with precisely the same drivers that they have already shipped plus just a different PPD are not included. But it also takes much longer to hit windows update and find your printer driver than it did on XP.