arturadib

16 ms·

91.
Twitter reverts back to traditional server-side rendering, cites performance(engineering.twitter.com)
1 points by arturadib 14y ago|0 comments
92.
by arturadib 14y ago
Alternate title: FB down 20%+ since IPO You'd be gambling enough already if you bought FB stock at 20x earnings (the tech norm for well-established companies), let alone at 100x. At 20x, you'd be speculating on FB's ability to sustain its c
93.
ShellJS: Say goodbye to bash scripts(twitter.com)
1 points by arturadib 14y ago|0 comments
94.
CoffeeScript: Before and after(twitter.com)
1 points by arturadib 14y ago|0 comments
95.
by arturadib 14y ago
There is nothing wrong with #LowHangingFruits. They can be just as good as harder-to-get fruits, and one would be silly not go for them first. And it's not just social media that's low-hanging in the Valley -- that'd be an oversimplificatio
96.
by arturadib 14y ago
Node is popular not only because it's very fast (yes, it's still pretty darn fast even if there might exist faster alternatives), but because it's JavaScript. That's an enormous advantage for startups as (a) the JavaScript hiring pool is mu
97.
by arturadib 14y ago
There's no wheel being reinvented. XULRunner is based on XUL, which makes it fundamentally different from the goal of above projects (that is, to use HTML technologies alone to build 'native' apps). Some of us at Mozilla Labs have tried to
98.
by arturadib 14y ago
The hardest part of all of this is getting a runtime that builds/installs seamlessly across platforms. I just did an 'npm install appjs' as per docs, and it failed (Mac). I myself have gone through great lengths to create a similar (minus W
99.
by arturadib 14y ago
appjs.purpose !== emberjs.purpose (former gives a cross-platform runtime, latter is merely a JS framework)
100.
by arturadib 14y ago
I've been a SimpleNote user for a while, great to see the platform layer finally coming out. I have a few questions: - As a potential customer, I'm curious as to how sustainable is the company. I understand there was a YC seed investment in
101.
by arturadib 14y ago
This is all fantastic and crucial, but please don't assume that Heroku's success was solely due to these technological ideas. (It's the typical assumption us hackers make). Being a YC company Heroku had immediate access to a bunch of startu
102.
by arturadib 14y ago
That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language. In Node, you would have a process responding to web requests, and launch a separate process -- via a conv
103.
by arturadib 14y ago
> Bad Use Cases: CPU heavy apps I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here: http://jul
104.
by arturadib 15y ago
Care to elaborate? Firebase's FAQ seems to suggest that they're still working on a solution.
105.
by arturadib 15y ago
Another great step in the right direction. That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and security models. It seems to me that most of these services launch before figuring ou
106.
by arturadib 15y ago
Yeah it's just in case there are no surviving references to those vars. For example in the hello world code app gets GC'd unless it's in a callback in setTimeout().
107.
by arturadib 15y ago
Think of Node-Five as a very small WebKit/Gecko engine for Node.js. It is written in JavaScript on top of Node-Qt, whereas Node-Qt itself is written in C++. When I say "native apps" in this context I simply mean you don't need a traditional
108.
by arturadib 15y ago
Not the same, but sometimes similar. (For example the QPainter API is similar to the Canvas 2D API, etc). Node-Five is for folks who are more familiar/prefer HTML5 APIs over Qt's proprietary API.
109.
by arturadib 15y ago
> do not allow running of the GUI in anything but the main thread That's right. AFAIK everything is running in a single thread.
110.
by arturadib 15y ago
Some Qt APIs are inherently asynchronous (like QHttp) but the graphics-related ones I'm binding to are not (like QPainter). So the situation is analogous to the DOM in web browsers. The calls are synchronous and run in the main thread. As
111.
by arturadib 15y ago
That comes from node-gyp (Node's addon build tool)
112.
by arturadib 15y ago
Node-Qt apps are really semi-native since the app itself is written in JavaScript. So you can easily make your app auto-updating, just like a web app. (iOS is an exception due to Apple's restrictions, unless they're OK with QtWebKit which I
113.
by arturadib 15y ago
Hi, OP here. For folks who prefer HTML5 APIs, I'm also working on a layer that translates these Qt APIs into HTML5 primitives (like Canvas and AudioContext): http://news.ycombinator.com/item?id=3816870 (There are some neat demos there :))
114.
by arturadib 15y ago
Hi, OP here. As explained that message happens when you mess something up in the C++ bindings, not because of JavaScript actually running out of memory.
115.
#Believe #DontListen(twitter.com)
2 points by arturadib 15y ago|0 comments
116.
Node-Five: Build native apps using Node.js + HTML5 APIs (Windows, Mac, Linux)(github.com)
8 points by arturadib 15y ago|0 comments
117.
Node-Qt: Build native apps using Node.js + Qt (Windows, Mac, Linux)(github.com)
79 points by arturadib 15y ago|26 comments
118.
by arturadib 15y ago
OP here. Fire off any questions to @arturadib, happy to help.
119.
Play with the PDF.js API directly from your browser(jsbin.com)
4 points by arturadib 15y ago|1 comments
120.
by arturadib 15y ago
I think Grunt is great for a lot of projects because it offers out-of-the-box solutions for most common needs. However, at Mozilla's PDF.js we needed more flexibility - there were so many JS packaging tools out there, each shining for speci

More ›