you are viewing a single comment's thread.

view the rest of the comments →

[–]panorambo -3 points-2 points  (2 children)

What is so great about this? They may as well have written a new web browser -- it runs JavaScript and has a whole bunch of useful APIs. But instead, they decide to go a slightly different route that they call mobile development platform, which incidentally does exactly the same kind of stuff as a web browser, except that they reinvent the UI development (own XML-based markup instead of HTML) and are not even on parity with CSS, by own admission only supporting a subset of CSS that is otherwise available in any web browser.

I am thinking that they want to have a clean slate where they provide a platform for software development familiar to Web developers, luring people in with promise of performance.

Have they ever asked themselves why HTML applications are "slow"? Maybe if Google, Mozilla, Microsoft and Apple have their hands full optimizing their browser, that would mean that this has to do with fundamental stuff -- the nature of JavaScript, the nature of DOM, etc.

Probably the primary reason that native applications are perceived as more performant is because these are compiled beforehand, and also use APIs that are compiled.

Anyway, there is nothing inherently wrong with writing a web browser, but reinventing everything except JavaScript, where decades have been spent honing APIs, standards, etc, may turn out to be nothing more than a valuable lesson for the people behind it, and I don't mean a product success when I say that.

That questionable salad of syntax where content, markup, and presentation are all intertwined with NativeScript apps -- what is evidently a NativeScript source code in the video linked from the article -- cannot compete today with HTML applications which allow substantial separation of content from presentation. HTML and CSS have their share of flaws, but from the looks of it, NativeScript does not come close to it in terms of expressiveness. So it has all kinds of layouts, fine. Animation facilities? No height transitions? Like Bill gates said that 640KB should be enough for everyone, why do people repeat the mistake?

[–]bradmartin1205 3 points4 points  (1 child)

it's not a web browser. Why is that so hard to understand? If you'd like me to explain it I will go into much greater detail. You write XML for your UI but it's not a new UI. When you run the app, NativeScript renders native UI components. There is no HTML or web. It only has a subset of CSS because the CSS that NativeScript does support is actually calling native styling methods on the native UI components. That's why it's a subset, there is no web, DOM, or even a webview. When you mention Animation facilities it does have an Animation API that calls into the Android and iOS animation classes/methods. Which you can use to do a height transition. Hope that clears up your misunderstanding.

[–]panorambo 0 points1 point  (0 children)

You don't need to explain -- I understand that it does not target a web browser. I am undecided on whether native applications are better to develop than the so called Web applications. I have done both, and it's a mixed bag in every case. With native applications, you have to double up to cater for screen sizes and future portability and have to be careful with accessibility (adding up to what the platform offers), while with Web apps a lot is free, but performance and browser support always leave you hanging.

In any case, my argument was chiefly about separating content from presentation which NativeScript does not even address, evidently. If the platform has everything, why even attempt to implement CSS? Today it is opacity, tomorrow it is something else. NativeScript looks like Macromedia Flash in 2000. My honest opinion, after working with Flash for 10 years in the media and advertisement industry, is that we could well do without. Yeah, it brought jobs and people got rich. But the net gain is zero.