

Native Mobile Apps Styled With CSS - Pixate (YC S12) Launches - pcolton
http://techcrunch.com/2013/01/15/pixate-debuts-a-framework-for-designing-mobile-apps-with-css/

======
jawngee
As someone who builds app for big brands (Conde Nast, Nike, Porsche, etc.) I
will not use this, despite any desire to actually do so.

Why?

You're shipping me a binary only. I want the source. I don't want to wait for
you to fix some shit that you may or may not get around to doing. I have a
really strict rule about this when it comes to client work, even stricter for
personal work.

Your idea that I should base an entire application on a closed source binary
that may or may not work is customer hostile, imho. You are inadvertently
leaving customers out to dry when something breaks or doesn't work correctly.
Unless your company has a team of devs ready to handle these cases ...

Would have been a good idea when the component market was roaring in the
Borland Delphi days, but we're in the future now were open source is the way
to go.

Pass.

~~~
hnriot
This is crazy, you're already using closed source when you link with the SDK,
which links with numerous other closed source components.

~~~
reidmain
UIKit is designed to be built upon. A lot of Apple stuff may be a black box
but it is designed to be subclassed. This is really an all or nothing affair.
Either this works perfectly for you or you are shit out of luck and you have
to compromise to fit inside their box.

~~~
Zev
_A lot of Apple stuff may be a black box but it is designed to be subclassed._

Aside from a small number of top-level classes[1] UIKit isn't designed to be
subclassed. When you subclass things like UIAlertView, UIButton, UISwitch,
UITextField, UIWebView… etc, you're in for a world undocumented gotchas and
spending hours to do small simple things.

1\. UIView, UIControl, UITableViewCell, UIScrollView, UIGestureRecognizer,
UIViewController, UIApplication and _maybe_ one or two other classes.

~~~
reidmain
And you've listed about 90% of the things I usual end up subclassing because
I've hit some limitation.

Also I wasn't talking specifically about UIKit. Foundation is another great
framework that I've subclassed many times.

It's not perfect but Apple puts a lot of work into documenting how to subclass
their frameworks. Third-party UI frameworks like this are much less forgiving.

~~~
Zev
Can you give an example of some things that you subclass?

~~~
reidmain
From Foundation? NSDictionary, NSArray and NSOperation instantly jump to mind.

~~~
Zev
What do you get out of subclassing NSDictionary or NSArray that you don't get
out of a category?

~~~
reidmain
Well in this case I subclassed them so I could have the backing data source
only weakly reference the items in the dictionary/array and because I
subclassed them I can use them wherever NSDictionary or NSArray is an accepted
parameter.

Apple's documentation also gives some examples:

[https://developer.apple.com/library/ios/#documentation/Cocoa...](https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/NSArray.html#//apple_ref/doc/uid/20000137-740795)

[https://developer.apple.com/library/ios/#documentation/Cocoa...](https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSDictionary_Class/Reference/Reference.html#//apple_ref/doc/uid/20000140-DontLinkElementID_1)

~~~
Zev
Why not use CFDictionaryRef and pass it along via toll-free bridging?

~~~
reidmain
I'm confused. How is that any easier? It's six of one, half dozen of the
other.

I'd much prefer to write Objective-C code than pure C.

------
reidmain
Are there any examples of really successful big name projects using third-
party UI frameworks that cost money?

Anything I use in my apps has to be open source in case either I come across
limitations or support is dropped. I can't create a dependency in my app that
could severely cripple me in the future.

It seems like using Pixate would introduce a huge dependency on your
application and everything that Pixate does is mapping down to something
already done in UIKit or perhaps CoreGraphics. I can understand the allure of
this framework because it would save you writing a lot of code yourself but
when you come across a limitation (which you undoubtably will because not even
the mighty UIKit does everything we need) and you implemented it yourself you
can then easily make improvements rather than waiting for a third-party. Sure
you could make requests but if Apple honoured every single improvement request
on UIKit they would never ship.

As an iOS developer I'm already in bed with Apple but their track record with
AppKit and UIKit speaks for itself. Their frameworks are black boxes but I can
build upon the shoulders of giants. Third-party UI frameworks like this feel
like I am constraining myself to very explicitly defined limitations and the
second I cannot adhere to those limitations I must be the one to compromise
instead of striking out on my own.

Is there something that I am missing with these third-party UI frameworks
because the opportunity cost has always seem to be too high for me.

------
killahpriest
If the pricing becomes more affordable, I think Pixate has a chance to totally
change the way native mobile front-end development is done.

Just look at the simplicity and familiarity with traditional front-end
development. <http://www.pixate.com/blog/2012/12/15/table-disclosure/>

View Controller:

    
    
       button.styleId = @"disclosure";
    

default.css:

    
    
        table-view #disclosure {
            background-color: linear-gradient(#75a4e6, #2670d8);
            border-radius: 15pt;
            border-width: 2pt;
            border-color: white;
            size: 27pt 27pt;
            font-size: 16pt;
            box-shadow: 1pt 1pt 1pt #333;
        }
    

If only they had a demo we could test how well Pixate lives up to its claims.

Example of use in XCode:
[http://www.youtube.com/watch?feature=player_embedded&v=h...](http://www.youtube.com/watch?feature=player_embedded&v=h4JVj0Fqheo#t=88s)

~~~
pcolton
You can install our free Pixate Playground app on your iPad and play with the
CSS in real-time:

[https://itunes.apple.com/us/app/pixate-
playground/id57867638...](https://itunes.apple.com/us/app/pixate-
playground/id578676382?ls=1&mt=8)

It's also open sourced: <https://github.com/Pixate/Playground>

~~~
mamcx
I download it and get:

.../Playground-master/Playground/PXViewController.m:9:9: 'PXEngine/PXEngine.h'
file not found

The framework file is not included...

~~~
killahpriest
<https://github.com/Pixate/Playground/issues/1>

------
AlexMuir
Getting Chrome malware warning for this article:

Danger: Malware Ahead! Google Chrome has blocked access to this page on
techcrunch.com. Content from d.adsbyisocket.com, a known malware distributor,
has been inserted into this web page. Visiting this page now is very likely to
infect your Mac with malware.

~~~
rcconf
I'm also getting this.

~~~
killahpriest
I didn't get it for TechCrunch, but did for this:
[http://www.cultofmac.com/192350/how-apples-obsession-with-
go...](http://www.cultofmac.com/192350/how-apples-obsession-with-google-is-
hurting-apple/)

------
stevenp
For me, not being able to try the library in my app is a deal-breaker. I'm not
willing to shell out $199 on faith alone.

------
yareally
It would have been nice to have it link to the framework instead of a
techcrunch article. First hand sources are always preferred if they're
available.

EDIT: forgot to include the link instead of just commenting:
<http://www.pixate.com/>

------
swampie81
relevant: <https://github.com/tombenner/nui>

~~~
reidmain
I'm very curious how much Pixate differs from NUI.

I looked into doing something like this and it seems like a pretty straight
forward idea. Map CSS properties to UIView properties. It felt like it was lot
of brute force work. Creating a parser and some sort of renderer for every
supported UIView seems like the majority of the work.

------
bornhuetter
Great idea. I think that anything that aids cross-platform development is
going to be very valuable over the next few years.

Building a platform agnostic front end without having to resort to
javascript/HTML could be a really useful step forward.

------
zopticity
Looks cool, but why can't this be achieved by simply using the native iOS
implementation?

~~~
lazerwalker
Assuming you're interested in custom UI elements, visual styling in native iOS
code is significantly more time-consuming than something like CSS (assuming an
equal level of familiarity with both). A lot of apps just end up using static
image assets for everything because it's that much easier and quicker. If the
performance is decent and the pricing fair, this could be a big time-saver.

------
rdl
This would seem to answer the "is no-idea a good idea for YC" question -- it
looks like a great product, and they applied as no-idea (according to the TC
article).

------
SvenAndersson
I like the subtle Arrested Development joke on the front page. "Loose seal!!"

------
pacomerh
Geeez whats up with the music, I couldn't watch the whole video.

------
alttab
So let me get this straight - Pixate wants people to build native iOS apps
with CSS.... um, ARENT WE JUST RE-IMPLMENTING THE WEB PEOPLE?!

Jesus! The one valid use case for native apps is games, everything else can be
solved with web apps. Why we are going out of our way to re-implement the ease
of web development on native apps should fucking tell you something. On top of
all this, they want to charge you $199 for it?

Disregarding the topic of whether or not Pixate itself is commercially viable,
but it makes me feel like XML-RPC all over again. Wasn't that what HTTP was
for in the first place?

We go through all this crap to make making "apps" convenient. Ultimately the
answer was in front of us the whole time we were just too stupid to see it.
The web will win. SECREST OUT!

~~~
rimantas

      > everything else can be solved with web apps.
    

Key word there is _can_. You sure cab try and sometimes succeed in replicating
native specialized components with html, js and css cobled together, and maybe
even to get it to work more or less OK. But why?

    
    
      > the ease of web development
    

You gotta be kidding. Developing web apps is not easy. Developing cross-
platform mobile web apps is even harder. Developing mobile web apps of
comparable to native performance is extremely difficult. I wonder is there
anyone who after spending some time to properly learn either native SDK still
prefers builng mobile apps with the web stack.

    
    
      > The web will win. 
    

The web will win what? Is there a war? A race? What I think will eventually
win is understanding what the web is for, what the apps are for and what is
the best tool for the job. Trying to fit a square peg into a round hole cannot
win.

