jQuery Mobile and done.
Web vs. native: let’s concede defeat
211–220 of 515 posts
Re: Web vs. native: let’s concede defeat
#212Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won. Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now. It’s not for every site to try and…
The problem is two-fold: it sucks for web developers who end up having to learn a new shitty framework every day, dogshit tools to even work with CSS and JS, endless preprocessor and transpilers, perverted markup and tag hell to support said shitty frameworks and having to deploy massive fuuckton heavy sites for a simple blog post. It also sucks hard for the end users : they can see their whole months mobile data all…
Sure. And you're also made out of meat and will die soon. And we're living on a planet that is in the long term doomed even if we half-evolved, tool-using monkeys get our shit together. (Did you know that we're half-way through the lifespan of forests? [1] That one day the conditions just won't be right for them anymore? That never fails to sadden me.)
But the interesting thing to me is what happens when we move past the existential despair that comes when we first recognize the true nature of things. Sure, things are fucked, but they always have been. What's next?
When I was as bitter as you sound here, I took a break. Burnout sucks. But eventually I found myself coming back to technology because it's my best chance to make the world suck slightly less. Or, put more accurately, to shift it in the direction of my irrationally high ideals.
So maybe take a break? Go hike the Pacific Crest Trail or work on a goat farm or something. You're not going to help anybody, yourself included, by soaking in something you hate indiscriminately. At least rest until you can come back and focus your hate in a laser-like beam on one particularly awful thing.
Re: Web vs. native: let’s concede defeat
#213Earlier quoted context omitted.
Answer me this: What is the point of a plethora of platforms, if nobody in their right mind develops native?
It seems we have different assumptions we're basing our arguments on. I get the impression that the huge diversity of linux distros is enabled primarily by the fact that more and more development these days is web and not native.
There isn't any great diversity in Linux distros interface-wise. You basically have a handful of distros that use X Windows and one of the four old window managers.
Re: Web vs. native: let’s concede defeat
#214What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users. I've done it. The one thing it requires is a lot of coordination. Notify the users to keep their equipment on the network from time X to Y. Notify the infrastructure team to schedule a push. Have the dev team on standby in case the push goes bad. Have the softw…
This ease of updating can be beneficial for some types of software (e.g intranet LOB). I have two issues with it for consumer software:
* the customer is powerless when it comes to deciding whether to upgrade when e.g. the company decides to change strategies.
* the customer data lies unsecured, covered by a standard privacy policy in some foreign jurisdiction somewhere. HTTPS by itself is useless when the data is available to pretty much anyone working at the company and in some cases the server providers too. I think this covers 99% of web services out there like Evernote, Dropbox, FB, Google's stuff, etc.
Re: Web vs. native: let’s concede defeat
#215The author is correct that modern web applications are hacks all the way down. It's crazy sometimes. But it fucking works!
Look at Google Docs, which has changed the way teams collaborate. Look at Unity which recently ported their player to the browser. Look at the Autodesk 123D suite.
With technologies like WebGL and Emscripten, we're just starting to see the tip of the "native on web" iceberg. And it's awesome. I know because I'm helping build the iceberg... :)
Re: Web vs. native: let’s concede defeat
#216Native apps are by definition less portable than web based ones. As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.
>As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc. This is because you are using tools and paterns to avoid having to think about the differences. Those tools are also on native platforms, and those differences apply to the web.
Yes but it's quite easy to handle to differences using shims / transpilers and feature detection.
Re: Web vs. native: let’s concede defeat
#217Earlier quoted context omitted.
"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in." To be fair, that could be said about most software projects. "80% done, now the last 80% remains." Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games)…
To be fair, that could be said about most software projects. Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist... With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff". When the "unkno…
I agree, but one minor nit: when major problems crop up "pretty late in the development cycle", this typically means a waterfall development cycle.
Waterfall approaches are really only appropriate when there's nothing particularly risky. I plead with the HN audience: never let a manager choose the waterfall model by default. They often happen because they make contract negotiation easy. But that's only because they save all the trouble for later.
Re: Web vs. native: let’s concede defeat
#218Earlier quoted context omitted.
> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles As far as I am concerned those things only exist to inflate ad views, they have negative usability impact. I don't really see why a long document should be broken up in pages to be readable. > The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos rela…
> There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with. Except when people nest the images as deep as posible and overlay other elements in front of the images so you can't simply right click the image, you have to inspect source and hunt for that image URL (or check resources tab in developer mode, or whatever). /rant
That usually happens because someone has decided they need some special javascript "gallery" for the user.
Twitter's default user timeline is the worst example of this that I know.
Re: Web vs. native: let’s concede defeat
#219Native apps are by definition less portable than web based ones. As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.
> Native apps are by definition less portable than web based ones. I don't believe it is that clear cut. I think you are ignoring the fact that native developers have frameworks of their own. Using Boost, GTK+, or Qt gives various layers-of-thickness over the OS so the native code is portable. Some, like Qt, also cover mobile operating systems as well as desktop ones. These frameworks are not young either; so while w…
I haven't seen anyone use Boost, GTK+ or Qt cross mobile / desktop.
Re: Web vs. native: let’s concede defeat
#220Earlier quoted context omitted.
Lack of support for shared state is no disadvantage! When you write multithreaded programs in a language such as C++ or C#, you try to impose on yourself the same restriction, in the interests of making your life easier... (I haven't used web workers, so maybe they're in fact awful to use. But from what I've read, it looks like the right decisions were made, pretty much.)
Why be so protective? Perhaps somebody invents some programming tool that makes it easy to reason about shared state. This is exactly the kind of mind-set that makes it difficult to develop for the web. Also, shared immutable state is a useful (often perhaps even essential) property for building efficient code in a multithreaded environment, even when using the message-passing style.
Tastes differ. I don't have any problem with erring on the side of overprotectiveness when it comes to multithreaded programming.