We need more native code

http://poincare101.herokuapp.com/post/18

by dhaivatpandya • 14 years ago

44 43 14 years ago

poincare101.herokuapp.com

hdctambien• 14 years ago

Cross platform is probably exactly the reason more native code isn't being written.

You get more surface area for your app and you don't have to worry about if the platform you are writing for will exist tomorrow.

ajross• 14 years ago

The premise is wrong. Plenty of native code is being written, just not by "app" writers. The UX domain has been ceded to interpreted/managed environments (with a few holdouts: ObjC apps on iOS being the biggest one) and it isn't coming back.

But under those apps sits a huge middleware, system management, driver, kernel and firmware stack. This world is very much alive. It's just a well-developed field without a lot of innovation happening in its tools. System s programmers don't spend a lot of time writing about the super-cool new environment of the week.

melling• 14 years ago

Maybe the Go language will become cross platform enough to get people back to a compiled language. iOS and Android could use Go libraries? I was watching a Rasberry PI video and wondering how fast Go would compile on them. A "modern" C would help get people back to compiled languages.

Btw, would a Go to C compiler solve the platform issues?

shykes2• 14 years ago

> "Is it because native code is much more difficult to write? That shouldn't be an excuse."

That seems like a perfectly valid excuse to me. All other things being equal, if it's more work to write an native app, why would you? And with the incredible improvements in the Javascript ecosystem, "all other things" are indeed quite often equal.

Produce2• 14 years ago

It's the other way round, hence web apps having, pound for pound, far fewer features than desktop apps. Getting a nice, usable UI working on the web requires a hell of a lot of low level work which has been abstracted away in the desktop GUI libraries for almost two decades. This whole thing reminds me of KDE4 - the foundation allows more interesting things but it takes a very long time before it's feature-complete.

shykes2• 14 years ago

I think comparing the number of available features per "pound" of effort is a mistake. Features are a binary thing for a given project: either the platform does what you need, or it doesn't. What matters to me is the amount of effort needed per "pound" of relevant feature. And that's where, in my experience, JS has a leg up.

The other crucial argument, which was made in other comments, is that the advantage of JS is further multiplied by its cross-platform nature. Basically every device that matters supports it. I believe that makes the comparison to KDE4 slightly less relevant :)

daleharvey2• 14 years ago

"We need to write the same app multiple times for each platform"

no we do not

We might have to in some circumstances, but that is a pretty terrible goal

jlarocco• 14 years ago

Actually, Javascript isn't the greatest example for cross-platform compatibility.

Assuming you're giving out the code (because Javascript has to...) there are more platforms with good C and C++ compilers than there are platforms with good Javascript interpreters.

The Wikipedia page for V8 [1] doesn't even list Solaris as a supported OS, for example.

[1] https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

daleharvey2• 14 years ago

I am sitting next to 5 devices, all 5 of them given a link can open a browser page and do what functionality most apps require, draw a ui, take input, process some output, save stuff etc

only 3 of those devices can actually run arbitrarily compiled apps, and of those 3 you have to build against an entirely different ecosystem (osx, ubuntu and android)

sure you can get a c compiler in most platforms, but that doesnt mean native apps are portable, they are by definition not

rch• 14 years ago

I was going to quip that Opera supports Solaris, but I guess that is no longer the case:

"...Opera has discontinued its support for Solaris. The Opera versions you see here are old and will no longer be updated."

-- http://www.opera.com/browser/download/?os=solaris-sparc&...

Can't say I blame them for dropping the platform though.

tmcw2• 14 years ago

Yes, but this is missing the reasons why people aren't psyched about native code and are psyched about javascript.

There are inspiring stories of people reusing modular bits of javascript that others write. Look at npm, and github. This doesn't happen on anywhere near the same level with cocoa, due to the culture of closed-by-default, the near-zilch focus on stuff like cocoapods, and the fact that most people are making 'products' and don't like to credit the giants they're standing on.

This also uses, but doesn't make or properly explain, what it means by 'better'. Javascript is worse for... the desktop? Notification based apps? This doesn't ring true, and isn't backed up by facts or citations in this article.

TileMill ( http://mapbox.com/tilemill/ ) is nodejs wrapped by incredibly minimal native windows (basically just chrome & an embedded browser) on three OSes. Should we have built three separate UIs, in cocoa, windows apis, and gtk? Would that have been 'better'? No.

andymatuschak2• 14 years ago

Now, I'm not trying to incite a native vs. web flame war here, but I believe that building separate native UI layers would have actually been much better. I hope I can provide some constructive criticism on the native app for the Mac:

The app, as it stands, does not behave like any of the others on my screen. This greatly increases the startup cost for me, since it doesn't follow the idioms I've already learned (and which I'm concurrently employing in these other apps).

For instance, the code editor doesn't behave like any other text editor on my screen (including the Xcode and TextMate source editors open alongside): Ctrl+Arrow doesn't navigate; double-click-and-drag doesn't select by word; my services are not available in the contextual menu; etc.

The keyboard shortcut for "change tab" that works in all the other tabbed windows on my screen does not work in this interface. The same goes for zooming shortcuts, "find" within the source editor, etc.

Then there are more fundamental disconnects: there's a "save" button in the interface, for example. That's an extremely rare thing to see in a Mac app. In fact, as of Lion, the user should never have to explicitly save.

Now, of course, building a native UI layer (in terms of design, not just ABI) would be a great deal of work. You could reasonably argue that it wouldn't be worth that work, but I'd just like to point out that it would indeed provide a much better experience.

tmcw2• 14 years ago

Thanks for the notes!

I've filed one issue for a keyboard shortcut for change tab: https://github.com/mapbox/tilemill/issues/1380 and there's already one for find functionality: https://github.com/mapbox/tilemill/issues/968 .

Lion-esque save-constantly behavior would be a bug at this point. Map rendering would need to be instant and isn't.

Tying these changes to 'a native UI' though, doesn't make a lot of sense: none of these changes are impossible, or even more difficult, because the code is in javascript rather than cocoa.

krschultz• 14 years ago

Web apps solve three problems.

1) immediately update your users all at once. Supporting 5 versions of legacy code sucks and adds friction to iteration.

2)monetization. Ads are more acceptable online. Subscriptions have better lifetime value than single purchases. And piracy is prevented.

3) usage metrics are a lot easier.

Bonus: cross platform.

If we can roll some of those up into a native app framework on top of. Net or JVM people might go back. Where is the Scala on JVM equivalent of Ruby on Rails that makes writing desktop apps fun again? (Doesn't have to be scalar or JVM, in just sayin')

*sorry for the typos, I'm fat fingering this on a smartphone If

esrauch• 14 years ago

There are perceived differences that make the difference non-ad monetization more complex than that. I think people would be less willing to pay a flat fee for a website than for an app. Part of it is that web operators feel they need to be on a subscription model rather than flat-rate, but it isn't like there is no maintenance cost for a native app.

jay_kyburz• 14 years ago

cross platform is not a bonus, it's my number one reason to build web apps..

"hacking a solution for the web that would work much better on the desktop is definitely not something you want to do."

the important question being which desktop?

ssp2• 14 years ago

I've sometimes wondered whether you could solve those problems within a system that provided a more native experience. For example, consider a new kind of client that would download and run bytecode instead of HTML/CSS/JavaScript.

The bytecode would have a built-in abstraction layer over various platform facilities such as graphics and sound, allowing it to look and feel much more like a native application.

sophacles3• 14 years ago

This was called java applets, then flash, then silverlight the last few times it was tried.

sciurus• 14 years ago

http://en.wikipedia.org/wiki/Java_Webstart

repsilat• 14 years ago

> a native app framework on top of. Net or JVM

We may need a new word - these platforms fall on the "managed" side of the native/managed split, but on the "native" side of the web/native one.

acuozzo2• 14 years ago

> Bonus: cross platform.

I run Links+ (http://links.twibright.com/) on OpenBSD to access the WWW. I don't have X11 installed, as I find GUIs to be far too distracting. Do you know of any ``cross platform'' web apps that work well in my environment (besides HN, of course)?

theootz• 14 years ago

You are, by far, in the minority of users. It doesn't make sense for dev's to extend that "cross platform" capability to use cases such as yours in most instances.

mrmekon• 14 years ago

It seems to be more of an Internet Culture thing than a Software Developer thing. There's a huge industry of C/C++/Ada/Assembly/.NET/JVM programmers out there, behind the scenes. Many of them are working for big companies, and big ol' companies generally aren't cool with their employees even talking about what they do online. You know that old 'the opinions expressed in this blog are my own and do not represent the company I work for or their investors or their advertisers" spiel? That's considered lenient.

But the Internet likes to talk about itself, so here it seems the only world is Javascript. And this corner of the Internet likes to talk about "tech startups", which is a very broad sounding term that actually refers to a very narrow set of almost exclusively web-technology companies. Not much hardware coming out of YC.

Additionally, this is somewhat of a "get rich quick" crowd, and nothing gets you a bigger market faster than a 'web app', whatever you define that to mean. It was always hard to get the average computer user to install desktop software, let alone pay for it, and that hasn't changed much.

aufreak3• 14 years ago

It seems to me that NaCl stands the best chance of reviving "code to the metal" programming in a web environment.

1. It is more cross platform than most native code today - the same assembly runs on win-mac-linux without recompilation.

2. Has cross platform audio+3d (no AV input yet, but soonish I guess)

3. Your code runs in a web environment and is launched with a link, so you can leverage on the GUI support available in the browser.

japhyr• 14 years ago

Is there a middle ground where you build a web app, and then offer a desktop app for people willing to install it? For example, I want to write some lesson planning software for teachers. It would fit the web app model well for many reasons, but there are compelling reasons to make it a desktop app as well. I plan to build the web app first, and with traction offer a native app.

This seems to parallel the current trend of building a web app and a separate dedicated mobile app. It's extra work, but done right it makes a powerful suite of ways to distribute your product.

gliese13372• 14 years ago

What I would really like to see is something that leverages all of the skill available for and effort put into web development directly for native application development, with minimal impact on the developers it's trying to win over. E.g., an HTML+CSS+JavaScript compiler that will take your web-app code and generate a native application for whatever target that behaves just like that source code would have if it were rendered in a browser.

One of Microsoft's really good, ahead-of-the-time ideas was HTML Applications, which are essentially that and have been around (but pretty much forgotten) ever since IE5. Not a compiler, but a special interpreter based on a browser that runs HTML+CSS+JavaScript as a native application, with a special execution environment that gives script access to the operating system and some extra HTML tags for window styling.

untog2• 14 years ago

E.g., an HTML+CSS+JavaScript compiler that will take your web-app code and generate a native application for whatever target that behaves just like that source code would have if it were rendered in a browser.

You are looking for Adobe AIR.

gliese13372• 14 years ago

Possibly. I looked at AIR briefly a while back, just before my lab transitioned away from Flash development, and while it does seem like it's on the right track, all I got out of it was that it's supposed to be used with ActionScript and runs JavaScript in an even more restricted security environment than browsers give you. Maybe it does do what I want if you strip away all the Flash junk obscuring it, I just haven't seen that demonstrated.

Aside from being interpreted rather than compiled, Microsoft's HTML Applications are really the closest thing I've seen to my Ultimate Vision, and I've actually used that platform to build major desktop applications.

chj• 14 years ago

If an application was created to be consumed like fast food, then I would say go for javascript/html/css. If it is created to be used a lot and last long, then I would suggest go native, even just for the sake of saving a few battery bars.

ridiculous_fish• 14 years ago

The rise of JavaScript mirrors somewhat the rise of C. Both C and JavaScript were initially tied to a particular platform (Unix and web browsers, respectively), both languages rose to prominence because of the dominance of their platform, and then both languages springboarded to transcend the platform. Their technical merit did not matter much, as long as they were good enough.

So today we see JavaScript being promoted as a first-class language for servers (node.js) and desktop apps (Windows 8, WebOS) when it's so obviously ill-suited to both tasks. I suppose the thinking is that the strong tool support and pool of developers already familiar with the language make up for its technical failings. It's distressing to see carefully crafted languages like C# being shouldered aside to make room for technically inferior ones, like an unqualified rich kid using daddy's connections to get a job. But in practical terms it may not matter much, as the APIs are more important than the language.

Anyways, the web calibrates user expectations down way low - heck, half of the sites I visit are trying to mislead me in some way, and quality can be dialed down when users can't demand their money back. This is a recipe for just awful software, but it's possible to break through that by building something obviously better. Remember how unappealing the so called "sweet solution" for the iPhone was, compared to native apps? Rock solid, reliable programs with a great user experience are a joy to use, and that sort of program can only be built using native APIs.

mvanveen• 14 years ago

This post just seems fundamentally misguided.

The author's point that "there's lots of things that are difficult in the world, but, that doesn't mean no one is attempting them" seems to be his strongest defense for a native app. Other than that, we have the claim that " hacking a solution for the web that would work much better on the desktop is definitely not something you want to do."

First of all, Light Table is a desktop app. Yes, the view layer will run in a web browser. But the runtime exists on your desktop. It is not a cloud editor like Cloud9, and will be running compiled byte code on your desktop in order to deliver that experience. In many respects, it is a native app (well, as native as a jvm runtime can be).

Second of all, I think that Light Table is definitely hitting the mark of attempting something ambitious and difficult. When you attempt ambitious, difficult things you want to lower as many barriers to entry as possible. It's a matter of exercising proper judgement and determining what you're striving to achieve. For the author of Light Table, that means writing a lot of javascript and lisp. For someone else, it might mean writing a lot of Objective C.

But, for God's sake, don't say that you should write a desktop app as a native app simply because you feel like there needs to be more "native code" in the world, especially in a day and age when your javascript compiles down to said native code.

iamtoby2003• 14 years ago

writing mobile game apps in C is totally cool and everything. but for small startups, surviving and quicker profit are way more important than adopting some aristocratic way of programming

robwgibbons• 14 years ago

First comment says it all

We need more native code

Related Stories