

We need more native code - dhaivatpandya
http://poincare101.herokuapp.com/post/18

======
krschultz
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

~~~
ssp
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.

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

~~~
ssp
It was also called "web browser" one of the last times it was tried. Those
became quite popular I believe.

Flash has done quite well actually, but one flaw is that it is completely tied
to the web browser, so it doesn't provide a really native experience. AIR
would be a better counter-example. Also, flash is quite unreliable.

Java applets had an addtional problem in that they required a huge standard
library and took forever to start up. I'd suggest instead to download the
standard library on demand.

~~~
sophacles
"Web browser" downloads and runs compiled bytecode instead of
html/css/javascript now (as the gp is suggesting)? Without a special plugin?
Huh, news to me.

~~~
ryannielsen
I'd love to hear what you consider to be the significant difference between
"bytecode" and "code". Compiling ASCII code down to bytecode or machine code
doesn't change semantics (not often significantly, at least); code is code.
The browser is downloading and running code, and is offering an increasingly
robust and attractive platform from which to do so.

How's that different from Java or Flash or Silverlight or anything else that
requires a "special plugin"?

~~~
sophacles
From a semantics point of view: the post I originally replied to asked about
compiled bytecode, not textual code.

From a deeper point of view: Theoretically you are correct. But in
practicalities... Peresumably you get 2 benefits from compiling the code to
bytecode:

* obfuscated source so people can't steal your secret sauce.

* faster execution because the compile step is skipped.

The second one has real practical limitations: for any major gain, the
bytecode has to be in a format that allows fast execution, which usually
includes taking out certain checks that can be done at compile time, taking
advantage of lower level runtime stuff and in some cases, optimizations for
the hardware arch below. This is all well and good, but when you have multiple
engines interpreting the bytecode, this can be done in very different ways. In
practice, to get from a robust bytecode to something that takes full advantage
of the system, effectively invokes a second compile step from bytecode to the
vm's internal representation. This is what a lot of JVMs do. I'm not sure
anything would actually be gained in that case.

Further, a robust bytecode format would required, since there are already
piles of hacks in the JS libraries we all use to handle various browser
differences. To get a bytecode that allows this, we end up with something that
looks more like a simple source code transform than any bytecode that gives
significant speedup out of the gate. (and at that point, your obfuscation of
the code starts to go away too - you could just disassemble it to something
that looks like jsmin output).

------
mrmekon
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.

------
ajross
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.

------
shykes
> "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.

~~~
Produce
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.

~~~
shykes
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 :)

~~~
Produce
>And that's where, in my experience, JS has a leg up.

I have to disagree with this. Creating a form which displays a list of users
and another to edit their details is trivial in, say, .NET's winforms. With
[PHP,Python,Whatever]/HTML/JS it's a comparatively painful exercise. No form
designer, you have to worry about low level stuff like data binding, the
default styling is too basic to be of use. It's a major step backwards, hence
people being excited about Meteor (<http://www.meteor.com/>) - it's finally
bringing back the RAD tools that we've been lacking for so long.

~~~
rdavl
It is trivial as long as your assignment is trivial and supported out of the
box. Also, .NET is a complete platform, while PHP/Python/JS are programming
languages not frameworks. For example Cake, Django or Rails would [parhaps] be
better comparison. Also RAD tools are generally, in my opinion, not as helpful
on complex projects as they are for simple applications.

------
tmcw
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.

~~~
andymatuschak
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.

~~~
tmcw
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.

~~~
andymatuschak
It's true: you could fix these specific bugs with JavaScript (though I don't
know if you could ever get Services working!) But you'd get a _huge_ amount of
standard behavior if your code editor were based on Cocoa's text system. As it
stands, you'll always be playing catch-up as AppKit changes the behavior of
Mac OS X's text views from release to release (and as the rest of the apps on
the system move with these changes "for free").

------
ridiculous_fish
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.

------
hdctambien
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.

------
mvanveen
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.

------
melling
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?

------
gliese1337
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.

~~~
untog
_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.

~~~
gliese1337
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.

~~~
srid68
Will you be interested in testing such a application framework and are you
sure that this will be useful for a lot of people. I am not sure why this is
difficult. There are already solutions like this. The only problem i see are
they are not cross platform or made simpler to experiment

I visualized a service where I would like to upload my Web App (Html/Js/Css)
and download a native apk/iap so that I can sign using my keys and submit to
the App Store/App Market as My Native App. (First Version)

I am sure this is solvable by lot of people in Hacker News.

What I have working is just a cross platform micro web server embedded in exe,
apk, iap, dmg* to run on Android/IOS/WP7*/Win/MacOsX/Linux which can host Html
Applications (Html/Css/Javascript), but currently working on server side
handlers to access native features.

I am not sure whether there is any market for this type of app framework. I am
exploring this to reduce my own workload in developing apps as a Senior
Project Manager(Cannot create Enterprise Apps in 3 different Architectures
(Java/ObjectiveC+/C#) even though you can unify the syntax to C# using
Unity3D/MonoTouch/Mono for Android. My personal goal was to iterate faster on
development and use C# & Native Code where appropriate. I don't want to be
locked into any one architecture.

------
daleharvey
"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
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)>

~~~
daleharvey
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

------
chj
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.

------
japhyr
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.

------
aufreak3
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.

------
iamtoby2003
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
First comment says it all

