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

41–50 of 85 posts

Re: The viability of JavaScript frameworks on mobile

#41

Post by nostrademons »

mwcampbell wrote: post #40
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…

Why doesn't Chromium render more elements on the GPU?

They had (have?) a project to do that:

https://www.chromium.org/developers/design-documents/gpu-acc...

http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...

I don't know what the status is of it. It'll help paint times (probably significantly), but it can't do much for layout, because the way the CSS spec is written, certain CSS properties require global calculations to figure out where every box should be laid out. (Think about floats, where they're supposed to butt up against other floated boxes, even if they don't have the same parent.)

Re: The viability of JavaScript frameworks on mobile

#42

Post by buro9 »

k__ wrote: post #6
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…

In terms of interactivity this probably only works for the most basic stuff. Also, only for the apps that need to be "always connected" anyway.

It's a forum, the example given in the article is also a forum. They are directly comparable.

Re: The viability of JavaScript frameworks on mobile

#43

Post by intruder »

tomcam wrote: post #24
BinaryIdiot wrote: post #9

This is good. Many frameworks are just too freaking huge for mobile but even when you use tiny frameworks and you dump a bunch of images into them you're going to have similar issues (at least on load). Honestly using the DOM API isn't all that hard. Yes it awkward, verbose and sometimes cumbersome but it's still pretty straight forward. I'm actually really liking react lately but if I want something done well for a…

This is heartening. How do you deal with cross-browser differences, especially considering you're supporting older mobile devices?

You deal with them one at a time. It's not like there's magic involved.

Our SPA isn't even using jQuery. Loadtimes are fast, app is very fluid.

Many people seem to not understand that when you query the dom for a node, you can store that node and reuse it throughout your app.

Re: The viability of JavaScript frameworks on mobile

#44

Post by rch »

aikah wrote: post #30
rch wrote: post #19

Earlier quoted context omitted.

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

Sencha Touch is pretty fast. When I was doing to Cordova development it was still the fastest js framework when it comes to UI responsiveness. Does it makes sense when it comes to developing mobile websites ? I don't know. I think sticky headers , footers , transitions and stuff like that make very little sense for a website. What kind of mobile website would you develop with a mobile UI framework ?

Maybe logging in to the admin side of one of my applications to check analytics, approve new memberships, and the like? I shouldn't need to package and distribute that as an app, but some of the mobile-friendly widgets are handy.

Re: The viability of JavaScript frameworks on mobile

#45

Post by bronson »

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.

Re: The viability of JavaScript frameworks on mobile

#46

Post by [deleted] »

aikah wrote: post #17
aabajian wrote: post #11

I know GWT isn't the most popular framework (it isn't really a framework, is it?), but I've been a fan of it for a while. It solves three critical problems that have plagued web development: 1. Cross-browser compatibility. 2. Code performance. 3. Code organization (there are many JavaScript frameworks whose selling point have been making JavaScript more organized). But in regards to this article, one often overlooked…

Sure but GWT == writing Java, downloading an heavy an complex SDK , and writing imperative UIs. Sure it comes with widgets but you can find the same widgets in JS. Compare with React,AngularJS and co : way more popular,declarative UIs , if you need static typing you can use Typescript which needs no heavy runtime. GWT might make sense for some LOB app for desktop but not for a mobile webpage.

[deleted]

Re: The viability of JavaScript frameworks on mobile

#49

Post by briantakita »

pygy_ wrote: post #22

This is where small frameworks like Mithril shine. The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC. http://mithril.js.org/

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/

Re: The viability of JavaScript frameworks on mobile

#50

Post by DCoder »

aikah wrote: post #17
aabajian wrote: post #11

I know GWT isn't the most popular framework (it isn't really a framework, is it?), but I've been a fan of it for a while. It solves three critical problems that have plagued web development: 1. Cross-browser compatibility. 2. Code performance. 3. Code organization (there are many JavaScript frameworks whose selling point have been making JavaScript more organized). But in regards to this article, one often overlooked…

Sure but GWT == writing Java, downloading an heavy an complex SDK , and writing imperative UIs. Sure it comes with widgets but you can find the same widgets in JS. Compare with React,AngularJS and co : way more popular,declarative UIs , if you need static typing you can use Typescript which needs no heavy runtime. GWT might make sense for some LOB app for desktop but not for a mobile webpage.

Google Closure Compiler [1] can also perform dead code removal, but it requires extra work annotating all public APIs and naturally it can't cope with dynamic/indirect calls.

[1]: https://developers.google.com/closure/compiler/

Post reply on HN