Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The viability of JavaScript frameworks on mobile

joreteg.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: The viability of JavaScript frameworks on mobile

#71

Post by buro9 »

WorldMaker wrote: post #69
buro9 wrote: post #3

With Microcosm we consciously chose to go the other direction: Do the work server-side and serve HTML. Basically... the old way of doing things. An example site https://www.lfgss.com/ is 280KB on first load (and most of that is Mozilla Persona) and subsequent requests are usually around 10KB. Even though that company is now dead, I'm still working on it and aim to strip out Persona (it's deprecated) and to set a firs…

Persona is not deprecated. It was moved to "community ownership", which is not "deprecated" just as much as the average open source project is not deprecated. It's a bit like saying that if Red Hat stopped paying it's developers to work on the Linux kernel then Linux itself must be deprecated. I wish more sites would use Persona and so I'm heartily disappointed to hear someone expecting to strip it out of an existing…

I'd love to continue using it... but I don't want to run an instance as I want to point at someone else's instance. If I have to run my own instance then I need to know I can maintain it and keep it secure, and I am not a Node guy and I find the code and all of it's dependencies to be too much for me to say that I am the man to keep an instance secure and maintained.

The thing is that I want it to perform as well as my application. Just look at Persona's portion of blame for the time, transferred bytes, transfer waterfall, connections: http://www.webpagetest.org/result/151020_X5_17EP/ (and that's with connection preconnects working... older browsers have it worse).

Persona is the biggest performance hit on my web app, and it's holding me back and I do not wish to run my own instance (just to put it behind CloudFlare and make the whole thing fly).

Whilst performance hurts, and it does hurt, and whilst I live under the shadow of "Mozilla aren't owning this and pushing it forward"... I'm very seriously thinking of using https://github.com/go-authboss/authboss and making a centralised front-end for it so that I can achieve a very similar thing in a simplified way that I can support and maintain.

The key thing though... I need performance from it. I don't have that today. I have a web account... but it needs to perform and I've seen no improvements on that front in the entire time I've used it.

PS: I even checked Auth0 and others, but I'm doing so many logins per month that it would cost 100x the costs to run my entire platform to use any of the paid services.

Re: The viability of JavaScript frameworks on mobile

#72

Post by magicalist »

pygy_ wrote: post #64
emsy wrote: post #62

Earlier quoted context omitted.

I don't say Mithril is bad but code size is no indicator for performance. Counterexample: The minified Box2D code is ~760kB large and impressively performant.

It is an indicator of load time. Most users bounce off pages that take longer than 3 secs to load. Mithril isn't the fastest of the virtual DOM libraries out there, but it is usually good enough, even on mobile.

Usually latency due to dependent requests are your killer on mobile. Even Edge throughput wasn't that bad once it finally got going.

Re: The viability of JavaScript frameworks on mobile

#73

Post by hack_mmmm »

Web and Mobile has many frameworks(JS/native) that can be used to solve similar problems. I am wondering how we can write code that can be re-written quickly on other frameworks as a metrics of performance tests. I definitely think that developers should test there code/app on slower/older phones. A performance mindset creates better scalable tech and can save the company a lot of money in the long run and at the same time can be a core of user experience

Re: The viability of JavaScript frameworks on mobile

#74

Post by elithrar »

bronson wrote: post #45
luketheobscure wrote: post #35

I think Ember is ahead of the curve on this one. Ember 2.0 introduced no new features, and instead only focused on stripping out deprecations, dead code, or platform specific stuff for browsers they don't support any more. (Disclaimer: I'm heavily invested in Ember.)

The article showed Ember 1.9 coming in dead last because of code size. 2.0 is supposed to be a little better but do you really think it's going to be ahead of the curve? It seems pretty unlikely... I hope you'll say more.

> The article showed Ember 1.9 coming in dead last because of code size. 2.0 is supposed to be a little better but do you really think it's going to be ahead of the curve? It seems pretty unlikely... I hope you'll say more.

To be fair to Ember here - Ember includes Ember itself, Ember Data and jQuery in that payload. React is just React - you'll probably want to include Redux (2KB) or Alt (33KB) and then potentially a whatwg-fetch polyfill or superagent, normalize and other libs to (possibly) fill out some jQuery features (Zepto @ 9.1KB), if not jQuery itself.

Re: The viability of JavaScript frameworks on mobile

#75

Post by primigenus »

neovive wrote: post #18
vskarine wrote: post #4

Would be interesting to see Meteor stats there too

I've only tested Meteor briefly, but there is a pretty large initial download by default[1]. However, there are solutions using community libraries for pre-rendering and also hosting static assets to a CDN. [1] https://forums.meteor.com/t/first-visit-loads-are-ridiculous...

The issue in the forum thread you're linking to was not caused by Meteor but by the OP canceling a deploy halfway through the process: https://forums.meteor.com/t/first-visit-loads-are-ridiculous...

Re: The viability of JavaScript frameworks on mobile

#76

Post by soapdog »

exelius wrote: post #67
nostrademons wrote: post #38

Earlier quoted context omitted.

It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…

JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly push…

You can add your blocking JS code to a WebWorker which will execute on a background task. This makes your UI responsive and keeps your number crunching from your users perception.

You can learn more about workers at https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Re: The viability of JavaScript frameworks on mobile

#77

Post by soapdog »

albemuth wrote: post #39
kra34 wrote: post #37

or you could just write regular Javascript. Browsers seem to be pretty good at handling Javascript, CSS, and HTML. The default size of vanilla js is actually 0 KB and that's not even gzipped.

And after reaching a certain level of complexity what you have is an ad-hoc framework of about the same size but is a slow, bug ridden implementation of half of one of the ones in the OP.

That really depends on the work. There is a lot of APIs in the browser these days that people are not using. For example, there are people adding jQuery to a project just to have the selectors when querySelector and querySelectorAll have been available for some time.

With good care, you can create libraries suited for your problem and keep code size and complexity down. Don't forget that when adding frameworks you're also adding their complexity to your project. Imagine having to debug the internals of angular... I shiver just too think of that.

The thing is that using frameworks is cool up to the moment when you reach a framework quirk or bug and need to dive into it as well, then you're no longer working in your problems domain but on generic framework land and that can be much trickier than building your own, specially if it is a solution made for a single problem.

But yes, I agree with you that if complexity grows enough you start requiring a special type of developer with high skills to keep this bespoke code running well.

Re: The viability of JavaScript frameworks on mobile

#78

Post by robocat »

rch wrote: post #19
vskarine wrote: post #4

Would be interesting to see Meteor stats there too

How about Sencha Touch? I'm guessing it's a beast.

Kendo UI Mobile Gzipped: 136kB (not including jQuery). It is now called "Kendo UI Mobile" and owned by Telerik.

Heavy base library, so custom build only saved about 5% for us.

Good response rate to support issues, although sometimes valid issues are not fixed so we require custom workarounds to basic problems.

Great for POC, or pilot. Not so great for consumer apps using WebView IMHO.

Re: The viability of JavaScript frameworks on mobile

#79

Post by slackson »

notanintern wrote: post #63
briantakita wrote: post #49

Earlier quoted context omitted.

I like riot.js; a react-like library weighing in ~3.5 kb min+gzip. http://riotjs.com/ Browserify gives you modules. This technology can be used to structure the code & package only the bare essential functionality. http://browserify.org/

Riot looks a whole lot like Polymer.

They compare it to polymer in the docs - much smaller, for one.

Re: The viability of JavaScript frameworks on mobile

#80

Post by Roboprog »

thomasahle wrote: post #51
thinkcontext wrote: post #27

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

I don't quite get the Atwood article, in both of the benchmarks he shows, Kraken and Octane, the Android device scores better than any IOs device, when using the stock browser. It's only when using TMOUS they do worse, so why do anybody use that?

TMOUS = T-Mobile??? Or something else?
Post reply on HN