Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Native Apps Are Dead, Long Live Native Apps

Soulskill posted more than 3 years ago | from the netcraft-confirms-it-then-denies-it dept.

Android 168

cardoni writes "Dan Yoder, CTO at Border Stylo, offers insights on the current state of simultaneous iPhone / Android development using PhoneGap and his thoughts on the debate over native apps versus Web apps. Quoting: 'One problem with the debate is that it’s a false dichotomy, since you can embed a Web browser within a native application. And, conversely, you can extend an embedded Web browser to provide access to native APIs. The two alternatives have not been mutually exclusive for years now. And, focusing on the strengths of native applications ignores the benefits of Web applications. For example, there’s the appeal of writing code that will run on a variety of different devices, ranging from mobile phones, to tablets, to laptops, even to gaming consoles. Virtually every major device platform now sports a Web browser, and it can often be discreetly embedded within a native application. To boot, much of this code can be tested using a Web browser, which enables more easily automated testing. It’s also easier to find Web developers than it is to find native developers.'"

cancel ×

168 comments

Sorry! There are no comments related to the filter you selected.

So the question is... (1)

Pino Grigio (2232472) | more than 3 years ago | (#36590188)

Well at the very least, you need a native developer to develop the software the web developer uses to developer his web software. I think.... but as a native developer, I'm not sure whether I'm making myself redundant in ten years time by not going all in training for web development.

Re:So the question is... (1)

SirMasterboy (872152) | more than 3 years ago | (#36590298)

Right and wont you always need a native developer to develop the web browsers for all these devices and platforms?

Re:So the question is... (1)

snemarch (1086057) | more than 3 years ago | (#36590568)

How many native developers will be working on browser teams, though?

While I don't personally believe everything will move to web apps, a lot is. Some of it for good reason, some of it because CEOs and other stupids thinks it's a good idea... so it's happening.

But hasn't it always been like that in IT? If you cling on to one old platform and aren't willing to learn new technologies, you're eventually going to become irrelevant?

Re:So the question is... (0)

Anonymous Coward | more than 3 years ago | (#36590614)

How many native developers will be working on browser teams, though?

How many native developers does it take to screw in a light bulb?

Better to be redundant than totally miserable. (4, Interesting)

Anonymous Coward | more than 3 years ago | (#36590312)

If you're a native application developer, I suspect that you'd be absolutely miserable if you ever had to work on web apps full-time.

Web app development is challenging for all of the wrong reasons. Whether it's having to use horrid languages like JavaScript or PHP, or dealing with broken browsers like IE6, or dealing with shitty MySQL databases "designed" by people who didn't understand even basic relational theory, you won't find much enjoyable about it.

At least native applications are often built using real programming languages like C and C++. Even semi-native languages like Java, C# and, dare I say it, VB.NET, are much, much, much more enjoyable to use than JavaScript or PHP, or dealing with broken HTML, or fighting with stylesheets.

I'm glad I was able to retire without having to do too much web development. Everything about it was decades behind where native applications were at the time, and things still haven't changed.

Re:Better to be redundant than totally miserable. (0)

Anonymous Coward | more than 3 years ago | (#36590628)

If you're a web developer, I suspect that you'd be absolutely miserable if you ever had to work on native apps full-time.

Native UI development is challenging for all of the wrong reasons. Whether it's having to tweak the gravity of every single widget by hand, or dealing with users opening your dialog box on a netbook monitor too short to show the OK button, you won't find much enjoyable about it.

At least web applications allow you to create your interfaces using a real presentation language like HTML and CSS. Even broken HTML and CSS are much, much more enjoyable to use than figuring out how you're going to get your dialog box to fit on a cellphone screen, or coping with someone entering |||||||||||||||||||(x20, please use fewer junk characters) into a field, or fighting with accessibility APIs.

...Personally, I'm wondering if Microsoft's Windows 8 Big Reveal is going to be that html5 will replace UI development on native apps. I'll drop everything and run to C# if that happens. All of the power of native apps without having to put up with any of the bullshit of native UI.

Re:Better to be redundant than totally miserable. (0, Insightful)

Anonymous Coward | more than 3 years ago | (#36590992)

Dude, we can all tell that you're a web developer who has never developed a native application by the many misconceptions and outright bullshit you just spewed. Nice try, though. Maybe with some practice, you Ruby fanbois will someday sound convincing.

Re:Better to be redundant than totally miserable. (0)

Anonymous Coward | more than 3 years ago | (#36591192)

C'mon guys. We're all programmers here. Our lives already are absolutely miserable for any reason you can imagine.

Re:Better to be redundant than totally miserable. (1)

sarysa (1089739) | more than 3 years ago | (#36591090)

If you're a MOBILE native application developer, I suspect that you'd be absolutely miserable if you ever had to work on web apps full-time.

Web UI development is challenging for all the wrong reasons. Whether it's having to deal with inconsistent widgets across browsers, or dealing with users whose browser settings break your page, you won't find much enjoyable about it.

At least mobile applications allow you to either use their rich interfaces for run-of-the-mill layouts, or (better yet) create your own layouts for flexibility and portability. Even Android's XML hell is much more enjoyable than figuring out how to make your page compatible with both limited mobile browsers and their small screens AND the wide array of computer resolutions and browser variants, or coping with the heavy limitations on interactive content and convoluted hacks to get around them, or putting up with the unintuitive APIs.

I'm too young to declare myself as fortunate as the retiree whose parody was parodied, but I'm happy to say I've avoided professional web development thus far. Anything closer to the bare metal is freedom -- anything as far removed as web development, with all the layers above you just itching to break your page in the next revision, would probably make people take advantage of prop 215 to get through the day.

Re:Better to be redundant than totally miserable. (0)

Anonymous Coward | more than 3 years ago | (#36591626)

At least web applications allow you to create your interfaces using a real presentation language like HTML and CSS.

As someone who has worked a bit as a web developer I would like to remind you that HTML isn't a real presentation language and was never meant to be used to present anything other than flowing text in the first place.
HTML is a horror of ugly fixes to make a text file format into a format where you almost but not fully can make presentations.
I'd rather build a brainfuck CPU from transistors and write my own OS for it than touch that abomination ever again.

Re:Better to be redundant than totally miserable. (1)

shutdown -p now (807394) | more than 3 years ago | (#36592346)

At least web applications allow you to create your interfaces using a real presentation language like HTML and CSS.

We've had that for a long time in managed land - WPF & Silverlight on .NET have XAML which, unlike HTML, was designed as an UI markup language from grounds up. Java has a bunch of third-party solutions similar in concept as well. Finally, for "pure native", there's Qt Quick and its QML.

Re:Better to be redundant than totally miserable. (1)

rock_climbing_guy (630276) | more than 3 years ago | (#36592642)

As a web developer, I agree with you.

As a web developer, I recently used some Javascript magic to... drum roll please... make a box with text in it appear in a corner of my application display. Of course, the contents of the box have to be saved to the web session so that the box can be re-drawn and then the text in the box re-written from the web session. This took a while. Even after all these years, a dialog beyond [Confirm] [Cancel] has to be custom built using Javascript (or you can import one from the libraries such as jQuery).

I would say that the number one thing that makes web development challenging for the wrong reasons is the disconnect between the browser state and the server state. The browser can remember "cookies". The server remembers "session". They cannot be counted on to agree. Furthermore, I have to be concerned that a hacker can manipulate my Javascript client-side code in any way imaginable (since the Javascript is transmitted as raw source code).

I've never been involved in "native" application development, but I imagine it to be decades ahead of web development. That being said, I don't want to come off as being totally sour. It took me a while to bootstrap the web development skills that I now posses, and knowing how to tackle these challenges helps me come out ahead.

At least my SQL database is maintained by a competent professional.

Better to learn your tools than be miserable. (2)

SanityInAnarchy (655584) | more than 3 years ago | (#36593018)

Whether it's having to use horrid languages like JavaScript or PHP,

JavaScript isn't a bad language. It's not a great language, but it's much better than it's given credit for.

PHP is, however, a pretty bad language. Maybe it's gotten better recently, but it's not a great choice -- especially when, on the server, you have options.

or dealing with broken browsers like IE6,

That does suck. Last time I did web development, it took something like an hour a week. But that's really not bad, in the scheme of things.

We also eventually decided to drop IE6 when we noticed how little of our traffic included it -- we targeted at least IE7, which was much better in that respect.

or dealing with shitty MySQL databases "designed" by people who didn't understand even basic relational theory,

In this case, you're in the same boat as with PHP -- that is, you're working with legacy code developed by shitty developers. You find the same shit everywhere.

Or you can use languages that are actually enjoyable on the server side, and work with designers who actually do understand databases.

At least native applications are often built using real programming languages like C and C++.

I'd prefer JavaScript to C++, but then, I hate static types. But I'm confused that anyone in their right mind would prefer C to JavaScript. C, really?

Even semi-native languages...

What do you mean "even"? I mean...

like Java, C# and, dare I say it, VB.NET,

Are you really saying C and C++ are more enjoyable than the above?

And people are taking you seriously?

I could see the argument that they are more "powerful", in some sense. More efficient, certainly, in the hands of someone who knows what they're doing. But more enjoyable?

I enjoy not having to debug segfaults anymore. Let's start with that.

or dealing with broken HTML,

How is this any worse than, say, dealing with a broken GUI widget?

or fighting with stylesheets.

This is probably the worst part of web development right now, so I do agree with you there.

But I'd still rather fight with stylesheets than fight with manual memory allocation in C and C++, or with making Java, C#, and VB.NET programs actually cross-platform -- or even be sure they work on everyone's machine. There are far fewer popular browsers than there are ways people will fuck up Windows.

Everything about it was decades behind where native applications were at the time, and things still haven't changed.

Oh, they have changed.

There are aspects which are decades ahead of native apps now, but there are also aspects which are decades behind.

Re:So the question is... (0)

Anonymous Coward | more than 3 years ago | (#36590454)

I don't think that was actually the point here though... It's not that at some level native app designers are not needed. The point is that neither pure web app nor pure native app development is the answer - a mixture of the two is preferable and possible.

Don't worry dude! (1)

Weezul (52464) | more than 3 years ago | (#36591658)

He said "extend an embedded Web browser to provide access to native APIs".

He'll need ya on staff permanently fixing goatse sized security holes.

Hippies are dead, long live frosties (-1)

Anonymous Coward | more than 3 years ago | (#36590200)

FP in the hizzy my biznitches

mod +5

Sure (1)

Sigvatr (1207234) | more than 3 years ago | (#36590238)

Developers are simply scared of losing profits when their software can be manipulated and redistributed. The solution? Keep everything on their side of the fence. This is not a new idea. It just takes people some time to come up with reasonable sounding excuses.

JavaScript (0)

nemasu (1766860) | more than 3 years ago | (#36590250)

Isn't that why an x86 emulator was made in JavaScript? Best of both worlds! Native code IN a browser.

Re:JavaScript (1)

Luckyo (1726890) | more than 3 years ago | (#36591160)

All that we need is to run this x86 emulator... on a x86 machine. Inside a browser.

When all you have is a hammer... (5, Insightful)

flyingsled (1475035) | more than 3 years ago | (#36590258)

Everything looks like a nail. Web apps are nice and play in a certain application space. Same with Native apps. Saying that one is "better" than another isn't fair since the apps themselves are different, with different constraints (how do I access a file on the users local filesystem seamlessly from a web app?). If I was going for "I'm going to write an application to conquer the world" approach, I would probably want it to run on iPhone and Android, so a web app is probably a good option. However, if I know my application is fixed to one piece of hardware (the newest iPhone for example) a native app is better since I can access more of the hardware with a native application.

Re:When all you have is a hammer... (-1)

Anonymous Coward | more than 3 years ago | (#36590462)

Android apps are native apps.

Re:When all you have is a hammer... (3, Insightful)

pushing-robot (1037830) | more than 3 years ago | (#36590466)

Exactly. If your app uses basic business logic and you want to maximize your audience, write a web app. If you need the best possible performance, write a native app.

Next thread: The debate over stacks versus queues continues. Which will win?

Re:When all you have is a hammer... (0)

Anonymous Coward | more than 3 years ago | (#36590990)

The debate over stacks versus queues continues. Which will win?

This can be resolved experimentally. Take two statements and put them in memory:

  - "Queues are better than stacks"
  - "Stacks are better than queues"

Now pull the statements out of memory. The first one out wins.

Re:When all you have is a hammer... (2)

jd2112 (1535857) | more than 3 years ago | (#36591300)

Next thread: The debate over stacks versus queues continues. Which will win?

I'm working on a 'First In-Random Out' queuestack. That should settle that argument...

Re:When all you have is a hammer... (0)

Anonymous Coward | more than 3 years ago | (#36592512)

i hereby propose we name that the "firo quack"

Re:When all you have is a hammer... (1)

Darinbob (1142669) | more than 3 years ago | (#36592282)

Though the "basic business logic" may not always apply. If the basic business logic uses that that's local to your device and stores the results local to your device then it's pointless to do it all on the web. Why? Only yuppies who demand to be mobile would keep their data in the cloud, and they only do that so they can flash their thin phones at their peers as opposed to trying to get real work done.

Native apps are usually a win if you're not doing data-entry to a server somewhere.

Re:When all you have is a hammer... (1)

Ruke (857276) | more than 3 years ago | (#36590782)

Specifically addressing "How do I do _X_ seamlessly from a web app?", it's really quite easy to do if you're going the "Native Web App" route with something like PhoneGap. Phonegap comes with a lot of API functions for commonly used native functionality (file access, contacts, geolocation, etc.), and it's trivial to map any native code to a Javascript function. (For example, I've written an HTTP_GET shim for communicating with my server for a cross-platform PhoneGap app I'm developing, because JSONP is a terrible way of doing things.)

I'll grant you that there is still a time and place for both native and web-apps (web apps are SO SLOW), but that gap is constantly narrowing.

Re:When all you have is a hammer... (0)

Anonymous Coward | more than 3 years ago | (#36591316)

Oh I just love this "If you use X-technology-du-jour"!

Tomorrow that technology is something else and the old one is 'lame'. The only way I can think of this is having a tradesman turn up to your house frustrated because his hammer changed into a rubber chicken overnight. Oh and all chisels are bent into U-shapes today. Tomorrow they'll be Zs. It's bad enough all these APIs can't even standardize on the damn NAMES for anything either, or camel caps, or just about any other aspect of the code.

Part of being a good programmer is knowing when to "leave it the fuck alone" as well.

Re:When all you have is a hammer... (0)

Anonymous Coward | more than 3 years ago | (#36592726)

...Constantly narrowing but may never converge in terms of performance.

Re:When all you have is a hammer... (2)

Dr. Eggman (932300) | more than 3 years ago | (#36591696)

I came off a project not long ago which involved a web app-running browser embedded in a native app. There was even a decent reason why: Users could pre-enroll online or walk-in at a dedicated station. Either way, the same steps had to be preformed at least once, before the rest of the application (which was native because it involved special hardware) did the rest.

All I can say was, it was...er, an experience.

To begin, the Web application was powered by Java while the Native application was run by C#/.Net. Don't let anyone tell you these two play nice, because they certainly don't; there were bizarre display issues present in the Native app that didn't happen in any other browser we were testing on (including IE.) Nevermind the challenges presented by getting the two applications to communicate and coordinate in order to provide a seamless integrated interface; we really should have relied more on Web Services than we did (but the reasons behind that are a whole other story.) Most importantly, in order to integrate the two well, you need a developer or developers who understand how to write good web apps as well as good native apps (also, in this case a developer who knows C# and Java, which I eventually came to.) I think you hit the nail on the head with your post; these are two very different things with their own strength domains. I'll just add that mixing them is questionable for most solutions, difficult for all of them (Fun, though!)

Web Or Native it doesn't matter (3, Interesting)

zbobet2012 (1025836) | more than 3 years ago | (#36590262)

"It’s also easier to find Web developers than it is to find native developers." A good programmer shouldn't really care what level he is working in, best practices etc. are fundamentally the same. Every decent programmer I know has dabbled in everything from assembler to javascript, at the very least. The good ones have written large applications in both or more. Making this a useless dichotomy, because whatever the application a poor programmer can drag an entire team or application down on his own.

Re:Web Or Native it doesn't matter (4, Interesting)

Dahamma (304068) | more than 3 years ago | (#36590738)

"It’s also easier to find Web developers than it is to find native developers." A good programmer shouldn't really care what level he is working in, best practices etc. are fundamentally the same. Every decent programmer I know has dabbled in everything from assembler to javascript, at the very least.

Let's face it - it's easier to find a web developer because web development is easier. I'm sure a lot more primarily C++ programmers have used Javascript than vice-versa. A significant number of "web developers" come from an artistic/graphic design background and have probably never even used a compiler. And that's not a knock on web developers any more than you'd knock a pediatrician for not being a pediatric surgeon...

Re:Web Or Native it doesn't matter (3, Interesting)

Ruke (857276) | more than 3 years ago | (#36590874)

While that's fine in theory, there's still the matter of experience on a platform to take into account. While a good programmer will be able to implement HeapSort in both Javascript and C, there's still the matter of whether he's familiar with Interface Builder's delegation system, or if he's got the DOM box model down pat. A good programmer should be able to pick up these skills in (relatively) short order, but some times you just want someone who's already an expert.

Native is more sexy (1)

whiteboy86 (1930018) | more than 3 years ago | (#36590266)

Truly exciting things happen in native environments.

Re:Native is more sexy (1)

Dahamma (304068) | more than 3 years ago | (#36591726)

Like cannibalism!

lowest common denominator (4, Insightful)

Bram Stolk (24781) | more than 3 years ago | (#36590282)

Well... running on many platforms sounds nicer than it actually is.
You tend to end up with an app that is tailored to the lowest common denominator of the platforms.
If you want to shine, you will want to go native.

Also with web apps (4, Insightful)

Sycraft-fu (314770) | more than 3 years ago | (#36590386)

It really does become the "Write once, debug everywhere," thing. Unless you are using very simple HTML and pretty much no interactivity, at which point you are a web site not a web app, you are going to have to have a shitload of "gotchas" and different cases. Not just for major different platforms like Android, Windows, etc but for different browsers.

Now if you want to do all that, well and good, but be serious about the amount of effort it takes and the amount of time savings, if any, over doing things native.

For complex applications, there isn't a "Just write it once," way of doing things.

Re:Also with web apps (1)

spottedkangaroo (451692) | more than 3 years ago | (#36590564)

Write once, debug everywhere

That's what phonegap is for... it's like the jquery of mobile.

Re:Also with web apps (1)

porl (932021) | more than 3 years ago | (#36591486)

i thought jquery mobile was the jquery of mobile? :P

Re:Also with web apps (1)

Anubis IV (1279820) | more than 3 years ago | (#36590632)

Exactly. To some extent, this difference between web apps and native apps is becoming the difference between Google's offering and Apple's with the cloud. Apple has iCloud coming out, but isn't going to be offering much in the way of web apps to access it (they have said that they'll be bringing some of the MobileMe web apps back later in a new form, but won't have them at launch). In contrast, Google's cloud platforms all have web apps built for them.

The advantage of Apple's approach is better fit and finish, whereas Google's approach allows you to access it from any device, pretty much regardless of the brand or apps available for it. If you'll always have your Apple device with you, the lack of being able to access the data from anywhere may not matter. Conversely, if you won't always have your devices around, then the lack of access from anywhere can be a deal breaker.

Re:Also with web apps (0)

Anonymous Coward | more than 3 years ago | (#36590870)

um, have you actually tried? i have. your suppositions don't match my reality whatsoever. the differences between the two webkit implementations in android and iphone are negligible, and javascript/css/html5 run just fine. if you can't make the average run of the mill app run in a webview, it says a lot more about your programming skills than the apple and android's native UI.

Re:Also with web apps (0)

Anonymous Coward | more than 3 years ago | (#36592470)

If you haven't come across differences between Google's Webkit and Apple's Webkit, you probably aren't doing anything too complex. Granted, that might not be a bad thing.

However, if you haven't come across differences in Apple/Google Webkit, Mozilla, Opera, and IE, I very much doubt you've tried writing a single web app.

Re:Also with web apps (1)

MobileTatsu-NJG (946591) | more than 3 years ago | (#36590908)

Wow. Ten years ago, this comment here on Slashdot would have been argued to death. "CROSS PLATFORM CROSS PLATFORM!!"

I agree with you by the way, I just remember all the fuss back then.

Re:Also with web apps (1)

shutdown -p now (807394) | more than 3 years ago | (#36592374)

In the context of mobile app development, though, it's much simpler - we're basically talking about WebKit on iOS and WebKit on Android. The difference is much smaller than your typical desktop test suite of IE, Firefox, Chrome and Safari.

Re:lowest common denominator (0)

Anonymous Coward | more than 3 years ago | (#36590432)

You tend to end up with an app that is tailored to the lowest common denominator of the platforms.

But that's going to happen anyway when you target mobile platforms. It doesn't matter if it's iOS or Android. The very act of targeting such platforms is that you'll always be inferior to desktop applications.

The same goes for web apps, too. The moment you decide to write a web app instead of a native desktop app, you're already selling your users short. You're offering them something inferior.

Re:lowest common denominator (2)

whiteboy86 (1930018) | more than 3 years ago | (#36590570)

Those exec fools at RIM (BlackBerry) and Windows (WP7) think that if they gave us some crazy "modern" non-native development environment then somehow developers will cheer.

They should gave us straight C to low latency audio, straight C to OpenGL and straight C to input, that is it. With all this we can optionally compile JavaScript, Python, browser you name it... but without native access no serious dev. will even try to download their "innovative" SDK.

And please stop selling us Java, we know enough already. iOS is such a success due to slick apps that are native, can't you see the difference between non-native vs. native example Android vs. iOS ?

Re:lowest common denominator (1)

shutdown -p now (807394) | more than 3 years ago | (#36592386)

So far, every mobile platform that started with the premise of "high-level tools only" for development, has gained support for native code. I have little doubt that newcomers will follow soon.

Different UI conventions (3, Informative)

pjlehtim (679236) | more than 3 years ago | (#36590292)

Android and iOS have very different UI conventions. TFA mentions the problem but then ignores it. By using PhoneGap (or any of the other similar products) you still need to build two different apps if you want to get good results. Just look at PhoneGap's featured apps examples. Almost every single one of them is written for iOS. If you bring them to Android users wont accept them as native. They will feel wrong. I wrote a post about this very problem into my blog few weeks back: http://www.androiduipatterns.com/2011/06/differences-between-android-and-ios-ui.html [androiduipatterns.com] Benefit of PhoneGap etc. is that you can use web technologies to write the apps. It is a false hope, though, if you expect to "write once, run everywhere". Juhani

Re:Different UI conventions (1)

Kalriath (849904) | more than 3 years ago | (#36590538)

Plus they forget to mention that if you just wrap your PhoneGap web app with a web view, it'll get on Android Market fine but Apple will reject it out of hand for being a "web clipping".

Re:Different UI conventions (2)

PCM2 (4486) | more than 3 years ago | (#36590578)

Just look at PhoneGap's featured apps examples. Almost every single one of them is written for iOS. If you bring them to Android users wont accept them as native.

And then, don't most Android handsets have custom vendor skins? Web apps won't ever blend seamlessly with every Android UI. And the user experience on Android 3.x is fairly distinct from Android 2.x, too. Any development tool that really aims to help your apps be more "cross-platform" will let you target different platforms, not shoehorn the same UI into all of them.

HaHa. (0)

msauve (701917) | more than 3 years ago | (#36590302)

"the appeal of writing code that will run on a variety of different devices"

That's just it. Apple wants to limit your ability to do that. [daringfireball.net]

Re:HaHa. (1)

Alan Shutko (5101) | more than 3 years ago | (#36590618)

They did rescind that in the 14 months since the article was written. Now you're perfectly free to write code that works on a variety of devices. And if you write code that runs poorly on a variety of devices, you'll be savaged in the reviews (as Safari Books Online was, with their Phonegap app release http://blog.safaribooksonline.com/2010/11/24/ipad-app-safari-to-go-update-november-24-2010/ [safaribooksonline.com] ). They came back and rewrote it native, and people are much happier.

Re:HaHa. (0)

Anonymous Coward | more than 3 years ago | (#36591064)

The same Apple that gives away DashCode with every Mac? Everyone is always afraid of Apple being evil and the argument usually has something to do with, "they're GOING to do this. Sure they haven't said they will, but I know they're evil so they're GOING to do it."

As for the silly blog post you linked to: Anything that attempts to kill Flash is good for everyone other than Adobe. It's not that they're trying to limit anyone's ability to write code that will work on a variety of devices. Their support for web apps and HTML 5 contradicts that view. It's not like they're pushing some new type of Active X or something. They're just helping everyone out by publicly shitting on Adobe. Personally, I can't wait until Flash is dead and there are fully featured, open source alternatives to Adobe's products. Their web authoring software is useless, especially for the price, and someday Gimp will be to Photoshop what OOo is to Office. Without Apple it's doubtful the web would have been able to detach itself from the parasite that is Flash. I see less and less sites using Flash these days aside from advertisements and video and it's losing ground in those areas as well. Good riddance. There's little that Flash can do that ajax can't do better.

web apps pump up the data costs and roaming (1)

Joe_Dragon (2206452) | more than 3 years ago | (#36590356)

web apps pump up the data costs and roaming rates starting at $0.015/KB make them cost a lot.

Or do both... (1)

jeffy210 (214759) | more than 3 years ago | (#36590368)

I think the way I like to see it is a common data access and back-end processor and then exposing things via APIs so that the front ends can be written in native/web/smoke signals, whatever you want allowing you to take advantage of the target devices best capabilities.

Re:Or do both... (0)

Anonymous Coward | more than 3 years ago | (#36590458)

This requires good planning, and thorough designs. Such things are beyond the abilities of many developers (sadly).

Re:Or do both... (0)

Anonymous Coward | more than 3 years ago | (#36591676)

This requires good planning, and thorough designs. Such things are beyond the timelines of many managers (sadly).

FTFY

Re:Or do both... (1)

tepples (727027) | more than 3 years ago | (#36592328)

I think the way I like to see it is a common data access and back-end processor and then exposing things via APIs

So you're trying to choose a language in which to write this "common data access and back-end processor", so that the application can run even if offline. Would it be written in C# so that it can run on Xbox 360 and Windows Phone 7? Would it be written in Objective-C so that it can run on a Mac or an iPhone? Would it be written in Java so that it can run on Android and BlackBerry? At that point, why not just use JavaScript and hit every current computer, every current phone, and every current game console but one?

Way I see it... (1)

yarnosh (2055818) | more than 3 years ago | (#36590404)

The way I see it, a web app is a new kind of application. It is its own niche where doing certain things is easier or more convenient. We'll need native apps for the forseeable future any time we want to access local hardware or integrate with the user's desktop/mobile device environment. A web browser is just way too much of a sandbox for a lot of applications. Sometimes apps need to interact with each other in ways that apps running in different tabs of a web browser just cannot.

Re:Way I see it... (2)

PopeRatzo (965947) | more than 3 years ago | (#36590560)

The way I see it, a web app is a new kind of application.

Unfortunately, the more the big companies try to push everything into a web app, the worse it's going to be for those of us that want apps to make stuff instead of apps to consume stuff.

Web apps are to native apps what 1970s TV was to 1970s cinema.

And this comment is one that only a handful of people will understand because I haven't worked hard enough to make my point clear.

I don't mind the growth of web apps, but I've noticed a certain stagnation to native apps lately that I suspect is because of it. I hope it's just temporary.

Re:Way I see it... (0)

Anonymous Coward | more than 3 years ago | (#36590962)

the worse it's going to be for those of us that want apps to make stuff instead of apps to consume stuff.

you don't consume digital content, that's an idiotic idea.

Alternative to "consume" (1)

tepples (727027) | more than 3 years ago | (#36592364)

Anonymous Coward wrote:

you don't consume digital content, that's an idiotic idea.

Then what's the general word for doing something with digital works other than creating them? What word covers viewing, listening, playing, etc. without being specific to a single medium?

The Native App Will Never Die... (4, Interesting)

FlyingGuy (989135) | more than 3 years ago | (#36590420)

and the reason is that with all the utility of HTML / CSS / JavaScript it is still brittle

DOM is getting even more bloated, inefficient and slow. CSS is out of control and when put to the extreme it is like reading RegEx that you didn't write that has 400 expressions in one string. That coupled with differences in even handling the box model between IE and everyone else is enough to drive a sane person over the edge, especialy with the kludges in CSS that were glued on to handle those problems.

JavaScript is supposed to be the language used to manipulate the Document Object but it was so poorly implemented that jQuery was required to make it reasonably useful.

For those reasons people keep writing native apps that work correctly the first time out of the gate.

Re:The Native App Will Never Die... (1)

drolli (522659) | more than 3 years ago | (#36591076)

Yes, thats right. The simplest way to write a cross-platform app is to write as must as possible in ANSI C and then bind it using appropriate glue code to the different platforms.

Re:The Native App Will Never Die... (1)

tepples (727027) | more than 3 years ago | (#36592382)

The simplest way to write a cross-platform app is to write as must as possible in ANSI C

Xbox 360 Xbox Live Indie Games and Windows Phone 7 require all applications to be 100% pure .NET IL. ANSI C does not compile to this target. So what's the simplest way to write a cross-platform app that includes Xbox 360 or Windows Phone 7 among its target platforms?

Re:The Native App Will Never Die... (1)

shutdown -p now (807394) | more than 3 years ago | (#36592408)

The simplest way, arguably, is to write it in C++ - at least you get a more or less decent object model that way, and can automate memory management with smart pointers, string handling with string wrappers etc. And every mobile platform today that has a C compiler also has a C++ compiler.

Re:The Native App Will Never Die... (1)

Bogtha (906264) | more than 3 years ago | (#36591478)

Some major misconceptions here.

DOM is getting even more bloated, inefficient and slow

It's never been faster. There have been huge performance improvements over the past few years.

CSS is out of control and when put to the extreme it is like reading RegEx that you didn't write that has 400 expressions in one string.

CSS's syntax has barely changed since its very first version 15 years ago. Its readability is like Perl - some developers make an unholy mess, others produce very readable code.

That coupled with differences in even handling the box model between IE and everyone else

Your information is out of date. Microsoft implemented the W3C's box model in Internet Explorer 6, released a decade ago.

JavaScript is supposed to be the language used to manipulate the Document Object

The DOM was explicitly designed to be language-neutral. This was a design goal from the outset.

it was so poorly implemented that jQuery was required to make it reasonably useful.

jQuery is a very nice toolkit, but it didn't make JavaScript more useful. By definition, it cannot do so, being implemented in JavaScript itself. It made it quicker and easier to write. The DOM could have been designed with a much nicer API, but that's neither JavaScript nor implementation.

Re:The Native App Will Never Die... (1)

FlyingGuy (989135) | more than 3 years ago | (#36591874)

DOM More efficient? Oh please, FF on Windows with 1 tab with /. open it is 100 +/- Megs of Ram ??? You call that efficient?

FF on OpenSuse with my gmail table my /. tab and a search tab ( google ) open and it is using 400 megs of ram? Efficient? Really?

Yes and that syntax is horrible and it is worse then Perl and Perl sucks sweaty donkey balls.

Really then why are we still writing kludges to deal with all the differences?

I guess we have different definitions of what useful means, I mean really different. Quicker and Easier to use = more usable.

Even with HTML-5's "improvements" we still have to:

  • write really bad JS functions to do the most basic things like preventing text from being entered into numeric fields.
  • Date Formats, really? I mean really? I cannot just feed it an appropriate mask, really?
  • I have to handle keystrokes in JavaScript, really?
  • I have to write code in to deal with the fact that a checkbox was not checked and so therefor it does not exist in post? Really?
  • I have to go 16 ways around hogans barn to emulate a grid control that is available in pretty every modern RTL for most every language? Really?
  • I have to deal with overflow: hidden; which does not work unless you specifically call out the width AND the height of a div? Really?
  • I can't have vertical centering in a div unless I screw around with line-height? Really?

The list is bigger and bigger but the one that really get to me is the utterly insane CSS hack to do drop down / fly out menus. Really????????

And you wonder why people still will do anything to write native apps instead of this broken kludge of a mashup between DOM / JS / CSS.. Good grief

Re:The Native App Will Never Die... (0)

Anonymous Coward | more than 3 years ago | (#36592500)

DOM More efficient? Oh please, FF on Windows with 1 tab with /. open it is 100 +/- Megs of Ram ??? You call that efficient?

FF on OpenSuse with my gmail table my /. tab and a search tab ( google ) open and it is using 400 megs of ram? Efficient? Really?

I wouldn't know where to look, in the FF code to verify it, but most programs / OS's are just fine with using whatever RAM is available. If FF is using 400 megs (its probably history, autocomplete, JIT Javascript, add-ons, etc) its really only a problem if your system is maxed out on RAM usage and your applications are fighting for RAM (swapping).

 

Yes and that syntax is horrible and it is worse then Perl and Perl sucks sweaty donkey balls.

Subjective. What would you rather have the syntax be?


Really then why are we still writing kludges to deal with all the differences?

I guess we have different definitions of what useful means, I mean really different. Quicker and Easier to use = more usable.

Even with HTML-5's "improvements" we still have to:

        * write really bad JS functions to do the most basic things like preventing text from being entered into numeric fields.

I agree
 
 
        * Date Formats, really? I mean really? I cannot just feed it an appropriate mask, really?

 
I AGREE!

 
        * I have to handle keystrokes in JavaScript, really?

How would you prefer to do it, exactly?

 
        * I have to write code in to deal with the fact that a checkbox was not checked and so therefor it does not exist in post? Really?

It should be stateful, meaning that a post should always be checkbox=checked or checkbox=unchecked. There should always be a submitted value, regardless of state. Is that what you mean, because if so I agree.

 
        * I have to go 16 ways around hogans barn to emulate a grid control that is available in pretty every modern RTL for most every language? Really?
        * I have to deal with overflow: hidden; which does not work unless you specifically call out the width AND the height of a div? Really?
        *

            I can't have vertical centering in a div unless I screw around with line-height? Really?

I pretty much agree with all of this. These are all really silly.

 

The list is bigger and bigger but the one that really get to me is the utterly insane CSS hack to do drop down / fly out menus. Really????????

I'm fairly sure you can do that without much mucking with CSS if you'd rather not do so. Not 100% sure about this though.

 
And you wonder why people still will do anything to write native apps instead of this broken kludge of a mashup between DOM / JS / CSS.. Good grief

I feel like the problem is that DOM/JS/CSS doesn't currently offer the kind of granular control over the UI as any native application would, and thats pretty much a showstopper for a lot of things. Also, my personal pet peeve, XmlHttpRequest() failing to work across domains is just dumb.

the only problem is... (1)

PJ6 (1151747) | more than 3 years ago | (#36590472)

web apps still suck compared to the real ones.

Yeah right. Native is going nowhere fast. (0)

Anonymous Coward | more than 3 years ago | (#36590508)

Call me back when EVE Online or any other REAL game goes mobile or browserbased... Pffh!
Wait... EVE does have an ingame browser... hmm....

Native is where the cool stuff happens. I've been doing distributed web applications for school and it's so boring! On the contrast, experimenting with Unity3D never ceases to amuse me.

People are getting a little confused here (1)

matthewv789 (1803086) | more than 3 years ago | (#36590610)

This isn't really about native apps vs web apps, but rather what technology to use to build the front end appearance and behavior of actual apps. Apps that use HTML/CSS/Javascript for this task, instead of Java or Objective C or whatever, are thus known as "hybrid" mobile apps.

In other words, PhoeGap etc. allow one to build a front-end interface in HTML5/CSS/Javascript, then package that up as an actual native application for various platforms (leveraging the platform's web browser under the hood). The frameworks usually allow you to take advantage of various native APIs that aren't normally accessible through a web browser (ie, that a normal web app can't use) and store data locally (ie, run the app offline), while reusing the same code across various platforms (and possibly as an actual web application version, as well).

The amount of "platform-native" programming required to implement the app on various platforms is thus minimal.

Also, some of the performance concerns are not as much of a problem as you might imagine, due to hardware-accelerated CSS3 transitions, etc. on various platforms. (Others actually convert Javascript to native code, obviating some of the potential performance issues.)

One approach might be to write a regular web app first, targeted at "modern" smartphones (primarily iPhone and Android), then convert that to a PhoeGap application that can be targeted as a native app for those platforms (and more, such as Blackberry and Windows Phone 7).

For more about this, see:
http://www.technologyreview.com/computing/37831/ [technologyreview.com]
http://www.appmobi.com/index.php?q=node/95 [appmobi.com]
http://www.amazon.com/Developing-Hybrid-Applications-iPhone-JavaScript/dp/0321604164 [amazon.com]

Makes since (1)

rsilvergun (571051) | more than 3 years ago | (#36590668)

Re:Makes since (1)

shutdown -p now (807394) | more than 3 years ago | (#36592426)

It's kinda strange to compare "HTML5 + JavaScript" to VB. VB is just the language - it can only meaningfully be compared to JS alone. Even then, what, exactly, do you find wrong about it? Aside from the fact that it's strongly typed (which is not a flaw by itself), it's a fairly modern language; miles ahead of Java. for example.

As for HTML, when comparing it to something like Silverlight, the only point on which it is ahead is portability.

Battery life (2)

firewood (41230) | more than 3 years ago | (#36590764)

Software people sometimes forget physical limitations. Web apps require more CPU cycles for the same work (even if just to run a JIT compiler), more CPU cycles will consume more of the user's battery life, and battery energy density isn't getting that much better over time.

Re:Battery life (1)

caywen (942955) | more than 3 years ago | (#36592200)

I'll be truly happy when javascript jockeys finally discover the benefits of compilation and stronger typing and stop treating the rest of us developers like we don't understand some brave new world or something.

Re:Battery life (1)

tepples (727027) | more than 3 years ago | (#36592422)

I'll be truly happy when javascript jockeys finally discover the benefits of compilation and stronger typing

So I've compiled a native application. How do my users execute it on their appliances? They can't because it hasn't been digitally signed by the appliance's maker. JavaScript applications, on the other hand, don't need to be signed by a third party to be deployed.

Re:Battery life (0)

Anonymous Coward | more than 3 years ago | (#36592474)

True but it depends on what you're doing. For a certain class of applications you can do the heavy lifting on the server side and the web browser just acts as a somewhat universal display/interface method which requires little CPU.

Cross Platform development is a nice dream and all (1)

Anonymous Coward | more than 3 years ago | (#36590768)

But do we really need to turn a text document format into an application framework again? Do we really have nothing better to do than recreate old Microsoft technologies?

Really, I haven't seen much good come from these "web apps". All I'm seeing are applications we already had being stripped down and made more resource heavy and inconsistent than ever before. Why do we have a billion different layouts for message boards and blogs? Why do we need a billion different icon designs and color schemes? Why do we need a billion different custom context menus? Why do we need to break everyone's back button? Why do we need a billion different video players? Why does this site look different in that browser? Why do none of these buttons look like the buttons I usually see? Why do these scroll bars, forms, and other widgets behave differently from the widgets I usually see? Why does that menu drop down on hover and this one when I click? Why do we use hover when there are so many touch screen devices out there? Why do some sites steal my middle click so I can't open things in new tabs? Why do various google sites use spans with onclick events when they're made to behave exactly the same as a standard link? Why do none of these GUIs follow the conventions of my platform? Why is it normal for an article of text and an image or two to use up a few hundred megabytes of memory? Why is it okay for Google Docs to make my CPU cry when it does less than MS Office 2000? Why are simplistic based painting applications on a Core2Quad less performant than Photoshop 7 on an old G4? Why is any of this normal?

Why did we accept this as the platform of choice going in to the future?

Re:Cross Platform development is a nice dream and (1)

Ol Olsoc (1175323) | more than 3 years ago | (#36592290)

We accepted it in the same way we accept cell phone sound quality versus landline phone quality.

We're told how great these web based apps are, and darned if some or most of us buy it. We get the computers running fast, so we come up with apps that slow it down. It's the latest form of software bloat. The time may come when we look back fondly on those Vista basic machines foisted on us a few years back.

TRUE native is dead (0)

Anonymous Coward | more than 3 years ago | (#36590808)

There are web apps, and local apps. But these days local apps are increasingly done with managed code.

It's been years since I've had a job where unmanaged code was permitted. I won't claim there aren't still some around, but they're fading into the background of development and for good reason.

So it is true, native apps are dying, but it has nothing to do with the web.

Been doing this for ages... (1)

cbybear (256161) | more than 3 years ago | (#36590810)

I've been working on an iPhone app called Phresheez, where the majority of the content is display via built-in web view in the native app. That let my partner in development make the Android version easily. Actually, he got the Android version working before I got the iPhone. And that was over 3 years ago.

It's proved to be an excellent way to manage the app. We still do a lot of native work (accessing sensors, custom features, in-app purchase, etc.), but the majority of user interaction takes place via a web view. It "talks" to the native app (via a delegate method on the iPhone, I don't know the Android details) and vise-versa.

The really wonderful part is that we can 'upgrade" the web part of the app at any time. As soon as the user restarts the app, they have the updated web app inside it. Our web app updates on a very regular cycle (a few times a week) versus the native apps which have been updated every few months as necessary (more on the Android than the iPhone, mainly due to easy of update with Android vs. iPhone). /. where the old is news again... :)

If you assume... (2)

sgage (109086) | more than 3 years ago | (#36590900)

... that Web access is going to continue to be cheap, fast, and always-on, then web apps and the whole cloud thing makes some sort of sense. Though there are still privacy and security issues.

But I don't assume that Web access is going to continue to be cheap, fast, and always-on. I sincerely hope that I'm wrong.

Re:If you assume... (0)

Anonymous Coward | more than 3 years ago | (#36591298)

That is the elephant in the room. Both Google and Apple are betting that it will, and if they don't put some serious work into making sure that it stays available, a team up of someone like Comcast+Cox+AT&T could shut them down almost over night. And given the kind of stuff that the FTC lets through, that whole team could end up owned by a single player.

Re:If you assume... (1)

darjen (879890) | more than 3 years ago | (#36592036)

If you're a popular commerce site like Amazon or Ebay, you will need to be connected to the web either way, even if you write a native application. The only reason I see a real need to write a native app is for games, audio editing, or photo editing. If you're a blog, content, or shopping site, I would focus on polishing your web app and leave it at that.

Re:If you assume... (1)

shutdown -p now (807394) | more than 3 years ago | (#36592440)

They're talking about offline web apps. Basically, imagine a bunch of HTML5 & CSS packaged into a native app which simply creates a fullscreen browser widget and loads that HTML into it. Oh, and exposes non-UI-related native APIs (filesystem access etc) to JavaScript running in that browser.

If I may interject... (0)

Anonymous Coward | more than 3 years ago | (#36591130)

Appcelerator seems to be an awesome compromise between the two... develop in a language webdevs are familiar with (Javascript) across many different hardware platforms (iOS, Android, Blackberry etc). It's not web dev, it's Javascript [runtime?] compiled to Objective-C (and Java for Android etc). It's a bitch to learn but once you get the hang of it it's super easy to throw together an app in no time. http://appcelerator.com/ (their docs aren't the most accurate, it's best to read the kitchen sink code).

Xamarin will be the sweet spot (0)

Anonymous Coward | more than 3 years ago | (#36591358)

http://xamarin.com/

Desktops vs. laptops (1)

cela0811 (1901860) | more than 3 years ago | (#36591472)

Native apps and web apps are like desktops and laptops. Laptops are more convenient and portable, but are harder to upgrade and generally less powerful. Laptops have advantages, but they aren't going to replace desktops anytime soon. Instead they will coexist until technology advances enough that laptops can replace desktops. Web apps are more portable and convenient; but native apps are faster and offer greater flexibility. They will coexist until computers are fast enough to run web apps at native speeds. Then the only native apps will be the OS and browsers. That is still a long time off. So stop worrying about it.

Huh? (2)

Marvin_Runyon (513878) | more than 3 years ago | (#36591492)

Dan Yoder

Who?

CTO at Border Stylo

Again, who?

Native Apps Are Dead

Oh, that again, whatever...

Jobs pushed this once.... (2)

sunfly (1248694) | more than 3 years ago | (#36591624)

Remember when Steve Jobs stood on stage and told developers they did not need to code native apps, because the iOS would ship with an awesome web browser? Didn't go too well, and they were forced to release native app support. Then Rubenstien left Apple to help build WebOS at Palm, that also did not support native apps. They may die someday, but it will not be any time soon.

Web! (0)

Anonymous Coward | more than 3 years ago | (#36591670)

Fwiw: I've only ever used the web browser to read slashdot. Native rss readers appeal to me but I enjoy slashdot in all it's quirky splendor. I've used native email clients, but I keep coming back to webmail.

Photo editing, video editing, I use native, but even tv and mp3 playing is acceptable to me with web services. Despite the downsides of not "touching the metal" -- as an iOS dev said having the same discussion at WWDC -- I tend to lean with what works best for the job, and the web -- in one shape or the other -- is getting the job done more and more each day.

Too bad... (0)

Anonymous Coward | more than 3 years ago | (#36592034)

Too bad most web apps suck ass. Also, developing web UIs seems to be massively time and effort consuming. I know our company spends about 10x the effort making sure our web facing UIs work than actually generating the data that the web UIs serve up.

Google's take (1)

loconet (415875) | more than 3 years ago | (#36592104)

Went to a talk on this at IO this year, here is Google's take on it [youtube.com] .

Web apps are native apps (1)

caywen (942955) | more than 3 years ago | (#36592158)

Sorry, I just don't see "web apps" as being any kind of meaningful term. It's not an application model, it's a deployment model, which is a different thing. The bits come down through some channel and execute on your system. Some bits execute remotely, but that's been happening for decades.

Cool... when no encryption. (0)

Anonymous Coward | more than 3 years ago | (#36592232)

Try to do RSA 1024 and AES 256 in a Phonegap Application with JS algorithms. You will have lot of fun there, specially waiting to the encryption / decryption happens. There is some things you still need to use Native for. Another example is trying to use a X509 certificate in the phone keychain and connect to the valid IP that this certificate was issued for.

For basic apps it is ok to work under the premises of general abstraction libraries (HTML + JS + CSS -> Webview -> Objective C) , but there is other places where the applications might need some more encryption and privacy protection than standard - i.e. Bank applications and more private access applications.

Native app vs native app (1)

Lost Race (681080) | more than 3 years ago | (#36592302)

FTA:

One problem with the debate is that it's a false dichotomy,

O RLY?

since you can embed a Web browser within a native application.

That's a native app.

And, conversely, you can extend an embedded Web browser to provide access to native APIs.

That's a native app.

The two alternatives have not been mutually exclusive for years now.

Whatever. If it runs in a plain old web browser, it's a web app. If it uses platform-specific native code it's a native app. Duh.

Re:Native app vs native app (1)

shutdown -p now (807394) | more than 3 years ago | (#36592574)

That's a native app.

You have a funny definition of a native app, when it applies to something that's 1% C/C++/Obj-C (and even that you don't write yourself but use a pre-made wrapper), and 99% HTML/JS.

For all practical purposes, from developer's point of view, these are web apps. They only become "native" when they are packaged prior to submitting to app stores.

Oh For Gosh Sakes! (1)

SilverHatHacker (1381259) | more than 3 years ago | (#36592658)

That's not how you use that bloody phrase! No one in the tech world seems to comprehend that the meaning is "The [old] king is dead, long live the [new] king". In this case, the title should be "Native apps are dead, long live web apps". Does it never occur to anyone that the way it is used here makes no sense at all?

dfsddsf (-1, Offtopic)

sliavre (2315644) | more than 3 years ago | (#36592852)

Check out our handy GHD Australia [ghdstraighteners-us.com] buying guide for advice:GHD Diamond Limited Edition [ghdstraighteners-us.com] : This is the original GHD Straighteners [ghdstraighteners-us.com] that people are raving about GHD Precious Gift Set [ghdstraighteners-us.com] .You is on the way to be within of GHD Rare Styler [ghdstraighteners-us.com] a enhanced on all sides to apperceive some-more about a Tory Burch Shoes [toryburchsale2us.com] organ siphon as christian_louboutin Pumpsnicely getting a features of Tory Burch Sale [toryburchsale2us.com] the organ siphon afterwards celebration of Cheap Tory Burch [toryburchsale2us.com] the mass this examination.Tory Burch Flats [toryburchsale2us.com] oneczna pogoda jest ca?The top most of course Tory Burch Flats [toryburchsale2us.com] is the price and the affordability but if Tory Burch Flip Flops [toryburchsale2us.com] have looked beyond that then they have been able to discover Tory Burch Boots Sale [toryburchsale2us.com] several other things to.Nobody can ignore the existence of Tory Burch Outlet [toryburchsale2us.com] in the fashion world.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>