7 ms·

Even when browsers are powerfull enough the mess what is trying to shoehorn technologies created for hyperlinked text into apps development will still be a mess

Even when browsers are powerfull enough the mess what is trying to shoehorn technologies created for hyperlinked text into apps development will still be a mess. It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. As for the appeal "run everythere"—that's just some more quirks. Good luck with that. I am very experienced web developer and probably know html, css, js and all that jazz better than I do know Objective-C and Cocoa Touch, but building mobile apps with web technologies is the last thing I want to do.

mtrimpe 14y ago
It's all about who is able to get their VM in the most places; Java already lost that battle and Flash is on the way out. It seems like JavaScript is the new ActionScript.
- macspoofing 14y ago
  >It seems like JavaScript is the new ActionScript Not even close.
  - andybak 14y ago
    Why not?
    - macspoofing 14y ago
      It's a very strange comparison to me. JS is intrinsically tied to the DOM, HTML and Web technologies, the underlying VM has widely used open-source implementations (V8, WebKit, Gecko), and JavaScript is not controlled by any single company.
      - mtrimpe 14y ago
        My comparison was of a more practical nature and practically speaking the most distributed VM is the browser. The browser itself used to be too slow for many use cases which led to Flash filling in the gap, but thankfully that's rapidly changing with improved JIT VMs and HTML5 standardization efforts (WebRTC e.a.) all leading to the eventual demise of Flash. Hence; JavaScript is the new ActionScript. P.S. They're both just ECMAScript flavors so in that sense I would say they're very close ;)
      - untog 14y ago
        JS is intrinsically tied to the DOM, HTML and Web technologies Not really. That just happens to be the most common use of it.
  - cpdean 14y ago
    I can't wait till node.js gets ported from its fringe-language to ActionScript. Asynchronous callbacks will make Flash run so much faster.
    - killahpriest 14y ago
      Uhh, the callbacks aren't from node. The fallbacks are from vanilla JavaScript. You just notice them more in node, because you're doing event stuff, like making http connections. You have callbacks in browser JavaScript when you use AJAX.
- dmackerman 14y ago
  Uhh, what?
macspoofing 14y ago
What mess? HTML/CSS/JS is exceptionally good at building user interfaces. And you're on the right side of technology by attaching yourself to the HTML bandwagon. I would go as far as to say that if you're starting development on a new ("form-based") native app, your first choice should be HTML. You only go native if you have a very good reason to do so.
- pjmlp 14y ago
  Because each single browser out there has a different understanding of what HTML/CSS/JS means. Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.
  - andybak 14y ago
    Not true. A reasonably large subset of HTML/CSS/JS is perfectly cross-platform if you: 1. Use industry standard libraries (jQuery or a lightweight alternative. 2. Can ignore pathologically broken browsers (<=IE7 mainly)
    - rimantas 14y ago
      The problem with this that reasonably large subset applies mostly to content related stuff. For web app you will need more envelope-pushing things and the picture won't be as nice there. Not to mention other issues that are not taken care by HTML at all: views management, efficient lists, etc. etc.
  - macspoofing 14y ago
    Even with multi-browser support, it isn't that bad. But we're not talking about websites here, are we? We're talking about using HTML/CSS/JS to build native apps for mobile devices - which are by and large webkit-based. This greatly simplifies everything.
    - blub 14y ago
      Oh really? Let's take my webkit-based mobile browser then and look at an instagram picture. Hm, it's cut in half and I can't scroll. Mobile web apps are actually iOS webapps that most of the time work on Android. Stop pretending you actually care about standards and cross-platform, you're only interested in doing less work, learning fewer things and holding users firmly by the balls in the cloud.
mistercow 14y ago
>trying to shoehorn technologies created for hyperlinked text Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text. >It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. I would say the opposite is true. Native doesn't protect you from quirks. On the contrary, it makes them worse. If you use HTML5, you're (eventually) dealing with standards that you can rely on so that you know your app will still work years down the road. Point your modern browser at the website for the movie Space Jam, and it works exactly the same today as it did in 1996. But with native frameworks, you have no such security as a developer. The "standard" is defined as "whatever the documentation currently says". Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature without deprecating it first? Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself. And that's to say nothing of the power that you lose when you write native apps in today's world of walled garden app stores. Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like blue today"? Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell your iOS app outside of the App Store, and it won't run on any other platform.
- rimantas 14y ago
  > For 75% of its development, HTML has been taregeted at > greater things than hyperlinked text. Where did you get this kind of nonsense and numbers? Before Web Applications 1.0 which evolved into HTML5 were was little considerations for web apps. > If you use HTML5, you're (eventually) dealing with standards that you > can rely on so that you know your app will still work years down the > road. Oh my, where do I start… I rather not. You know, I've been making websites since 1996, I happen to know a thing or two about web standards and web browsers and I happen to be on HTML5 mailing list since before it was known as HTML5, so let me just say: you cannot rely on anything. > The "standard" is defined as "whatever the documentation currently says". As opposed to what? You do know that no browser implements HTML 4? You do know, that versions of HTML are basically meaningless? > Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature > without deprecating it first? Except that did not happen. Your web app won't run on pure spec. It needs browsers. Guess who develops browsers. Guess who picks up which features to implement. > Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself. I guess your up to date web app has better luck with broken Android browser of the previous versions. > And that's to say nothing of the power that you lose when you write native apps in today's world of walled > garden app stores. I lose no power. Some people are scared by walled gardens because… well, because they are supposed to get scared. > Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like > blue today"? Oh, those scary stories of the days past. There is a name for them: FUD. > Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell > your iOS app outside of the App Store, and it won't run on any other platform. As opposed to many many ways to sell your web app. Good luck with that.
sojacques 14y ago
Saying that HTML is nothing but a technology created for hyperlinked text is like saying the mobile device you're using all the time was created to pass phone calls. While this is true, it is a truly weak statement. You make it sound like learning the native will magically lead to create better working apps. This is just not true. I'm not saying going native doesn't have to potential to help developers create faster apps, but when making something like this feed, HTML5 would not seriously be a bottleneck. And you're claiming to be a "very experienced web developer"? Dunning-Kruger much?

mtrimpe 14y ago

It's all about who is able to get their VM in the most places; Java already lost that battle and Flash is on the way out. It seems like JavaScript is the new ActionScript.

macspoofing 14y ago
>It seems like JavaScript is the new ActionScript Not even close.
- andybak 14y ago
  Why not?
  - macspoofing 14y ago
    It's a very strange comparison to me. JS is intrinsically tied to the DOM, HTML and Web technologies, the underlying VM has widely used open-source implementations (V8, WebKit, Gecko), and JavaScript is not controlled by any single company.
    - mtrimpe 14y ago
      My comparison was of a more practical nature and practically speaking the most distributed VM is the browser. The browser itself used to be too slow for many use cases which led to Flash filling in the gap, but thankfully that's rapidly changing with improved JIT VMs and HTML5 standardization efforts (WebRTC e.a.) all leading to the eventual demise of Flash. Hence; JavaScript is the new ActionScript. P.S. They're both just ECMAScript flavors so in that sense I would say they're very close ;)
    - untog 14y ago
      JS is intrinsically tied to the DOM, HTML and Web technologies Not really. That just happens to be the most common use of it.
- cpdean 14y ago
  I can't wait till node.js gets ported from its fringe-language to ActionScript. Asynchronous callbacks will make Flash run so much faster.
  - killahpriest 14y ago
    Uhh, the callbacks aren't from node. The fallbacks are from vanilla JavaScript. You just notice them more in node, because you're doing event stuff, like making http connections. You have callbacks in browser JavaScript when you use AJAX.
dmackerman 14y ago
Uhh, what?

macspoofing 14y ago

What mess? HTML/CSS/JS is exceptionally good at building user interfaces. And you're on the right side of technology by attaching yourself to the HTML bandwagon. I would go as far as to say that if you're starting development on a new ("form-based") native app, your first choice should be HTML. You only go native if you have a very good reason to do so.

pjmlp 14y ago
Because each single browser out there has a different understanding of what HTML/CSS/JS means. Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.
- andybak 14y ago
  Not true. A reasonably large subset of HTML/CSS/JS is perfectly cross-platform if you: 1. Use industry standard libraries (jQuery or a lightweight alternative. 2. Can ignore pathologically broken browsers (<=IE7 mainly)
  - rimantas 14y ago
    The problem with this that reasonably large subset applies mostly to content related stuff. For web app you will need more envelope-pushing things and the picture won't be as nice there. Not to mention other issues that are not taken care by HTML at all: views management, efficient lists, etc. etc.
- macspoofing 14y ago
  Even with multi-browser support, it isn't that bad. But we're not talking about websites here, are we? We're talking about using HTML/CSS/JS to build native apps for mobile devices - which are by and large webkit-based. This greatly simplifies everything.
  - blub 14y ago
    Oh really? Let's take my webkit-based mobile browser then and look at an instagram picture. Hm, it's cut in half and I can't scroll. Mobile web apps are actually iOS webapps that most of the time work on Android. Stop pretending you actually care about standards and cross-platform, you're only interested in doing less work, learning fewer things and holding users firmly by the balls in the cloud.

mistercow 14y ago

>trying to shoehorn technologies created for hyperlinked text Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text. >It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. I would say the opposite is true. Native doesn't protect you from quirks. On the contrary, it makes them worse. If you use HTML5, you're (eventually) dealing with standards that you can rely on so that you know your app will still work years down the road. Point your modern browser at the website for the movie Space Jam, and it works exactly the same today as it did in 1996. But with native frameworks, you have no such security as a developer. The "standard" is defined as "whatever the documentation currently says". Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature without deprecating it first? Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself. And that's to say nothing of the power that you lose when you write native apps in today's world of walled garden app stores. Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like blue today"? Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell your iOS app outside of the App Store, and it won't run on any other platform.

rimantas 14y ago
> For 75% of its development, HTML has been taregeted at > greater things than hyperlinked text. Where did you get this kind of nonsense and numbers? Before Web Applications 1.0 which evolved into HTML5 were was little considerations for web apps. > If you use HTML5, you're (eventually) dealing with standards that you > can rely on so that you know your app will still work years down the > road. Oh my, where do I start… I rather not. You know, I've been making websites since 1996, I happen to know a thing or two about web standards and web browsers and I happen to be on HTML5 mailing list since before it was known as HTML5, so let me just say: you cannot rely on anything. > The "standard" is defined as "whatever the documentation currently says". As opposed to what? You do know that no browser implements HTML 4? You do know, that versions of HTML are basically meaningless? > Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature > without deprecating it first? Except that did not happen. Your web app won't run on pure spec. It needs browsers. Guess who develops browsers. Guess who picks up which features to implement. > Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself. I guess your up to date web app has better luck with broken Android browser of the previous versions. > And that's to say nothing of the power that you lose when you write native apps in today's world of walled > garden app stores. I lose no power. Some people are scared by walled gardens because… well, because they are supposed to get scared. > Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like > blue today"? Oh, those scary stories of the days past. There is a name for them: FUD. > Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell > your iOS app outside of the App Store, and it won't run on any other platform. As opposed to many many ways to sell your web app. Good luck with that.

sojacques 14y ago

Saying that HTML is nothing but a technology created for hyperlinked text is like saying the mobile device you're using all the time was created to pass phone calls. While this is true, it is a truly weak statement. You make it sound like learning the native will magically lead to create better working apps. This is just not true. I'm not saying going native doesn't have to potential to help developers create faster apps, but when making something like this feed, HTML5 would not seriously be a bottleneck. And you're claiming to be a "very experienced web developer"? Dunning-Kruger much?