We need more native code(poincare101.herokuapp.com)
poincare101.herokuapp.com
We need more native code
http://poincare101.herokuapp.com/post/18
16 comments
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?
"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?
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.
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.
This was called java applets, then flash, then silverlight the last few times it was tried.
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.
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.
"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.
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"?
How's that different from Java or Flash or Silverlight or anything else that requires a "special plugin"?
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).
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).
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.
> 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.
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.
> 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)?
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)?
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.
> You are, by far, in the minority of users. It doesn't make sense for dev's [sic] to extend that "cross platform" capability to use cases such as yours in most instances.
Then it follows that devs shouldn't support, e.g., deaf users.
Then it follows that devs shouldn't support, e.g., deaf users.
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.
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.
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.
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.
> "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.
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.
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.
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 :)
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 :)
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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").
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.
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.
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.
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.
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.
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.
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?
Btw, would a Go to C compiler solve the platform issues?
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.
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.
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.
You are looking for Adobe AIR.
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.
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.
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.
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.
IIRC, you can make AIR apps using just HTML+JS. It has multiple modes (including Flash)- the HTML mode is a Webkit-based engine.
"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
no we do not
We might have to in some circumstances, but that is a pretty terrible goal
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)
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)
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
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
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.
"...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.
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.
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.
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.
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.
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.
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
First comment says it all
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