snearch + node.js   207

Dance to Calypso | Matt Mullenweg
So we asked ourselves a big question. What would we build if we were starting from scratch today, knowing all we’ve learned over the past 13 years of building WordPress? At the beginning of last year, we decided to start experimenting and see.

Today we’re announcing something brand new, a new approach to WordPress, and open sourcing the code behind it. The project, codenamed Calypso, is the culmination of more than 20 months of work by dozens of the most talented engineers and designers I’ve had the pleasure of working with (127 contributors with over 26,000 commits!).

Calypso is…

Incredibly fast. It’ll charm you.
Written purely in JavaScript, leveraging libraries like Node and React.
100% API-powered. Those APIs are open, and now available to every developer in the world.
A great place to read, allowing you to follow sites across the web (even if they’re not using WordPress).
Social, with stats, likes, and notifications baked in.
Fully responsive. Make it small and put it in your sidebar, or go full-screen.
Really fun to write in, especially the drag-and-drop image uploads.
Fully multi-site for advanced users, so you can manage hundreds of WordPresses from one place.
Able to manage plugins and themes on Jetpack sites, including auto-upgrading them!
100% open source, with all future development happening in the open.
Available for anyone to adapt to make their own, including building custom interfaces, distributions, or working with web services besides
Wordpress  Calypso  React.js  Javascript  Node.js 
january 2016 by snearch
Scala founder: Language due for 'fundamental rethink' | Java programming - InfoWorld
nfoWorld: You mentioned Swift. What's your take or perspective on Swift, which Apple just introduced, and on another language that's becoming popular, Node.js?

Odersky: You could say that Swift related to Objective-C is a little bit like Scala related to Java. It runs on the Apple platform, but it's a higher level, a more functionally inspired language than the standard language. In fact, if you look at it, it borrows a lot of features from Scala. In a sense, it's a validation of what Scala does. To see that reflected in Swift shows that we must have done something right here.

Node.js is an interesting platform because it leverages JavaScript on the server, and it has essentially the reactive programming model, the event-based reactive programming model. What we do with Scala and the Typesafe platform -- that would be Akka and Play -- is very similar, so we also leveraged the reactive programming model, very much so, just like Node does it, but we do that in a setting that is strongly typed.

InfoWorld: You said a couple years ago that there were a lack of tools for use with Scala. Has this been remedied?

Odersky: Yes. Both the Eclipse Scala IDE and the IntelliJ Scala plug-in work are now mature and work generally very well. There is now also a very good Scala-specific debugger. Also, lots of third-party tools for code coverage, style-checking, bug-finding exist. Some of them commercial, (for example), the one by Semmle.

InfoWorld: Is there anything else you want to mention about Scala?

Odersky: We are in the middle of a paradigm shift [in] the industry, and there will be a new equilibrium between functional and object-driven programming, and Scala is leading that.
Scala  print!!!  Odersky_Dr._Martin  OOP  functional  programming  Swift  Node.js  Webdevelopment  Objective-C  Akka  Play  reactive  Eclipse_Scala_IDE  IDE 
september 2014 by snearch
You might not need a WebSocket | Hacker News
tribaal 5 hours ago | link

I live in Africa.

Websockets suck here. BGP routers here flap very often, nuking TCP connections because hey, power cuts. Guess what happens?

Tip: If you're "out to change the world", make sure you can turn your wifi card every 30 seconds and still get a decent-ish experience (yes, long-polling HTTP works, so does good old timer-based polling).


jkarneges 4 hours ago | link

Indeed. These days, you have to expect users will wander out of their wi-fi range or have crappy mobile connections. Whenever I ride the train with my 4G tether, my TCP sockets die every few miles.

I lose ssh and my websockets, but long-polling apps keep working. Kind of ridiculous, but that's the world we live in.

Making your websockets resilient means pinging and aggressive reconnecting.
Webdevelopment  websockets  long_running_commands  polling  Afrika  Socket.IO  SockJS  Node.js 
july 2014 by snearch
Introducing 1.0 | Hacker News
Oculus 10 hours ago | link

The undoubtable mention of SockJS will appear multiple times in this thread. has been plagued with scalability issues since its original release (can't speak on the new version) and is suppose to be fix that. The main difference between SockJS & is their connection establishment. SockJS begins by attempting to use Websockets and regress to long polling while starts with long polling and slowly works its way up to Websockets.

For a good debate on this with the creator of SockJS:!topic/sockjs/lgzxVnlth54
Node.js  Webdevelopment  Sock.IO  SockJS  websockets 
may 2014 by snearch
Npm's Self-Signed Certificate is No More | Hacker News
weixiyen 18 hours ago | link

Node.js is not ready.

The main problem with Node.js is that the libraries out there simply are not good, are broken / don't do what it says it does, or have critical issues outside of the most basic use cases. I'm talking about the popular libraries (like down to all the ones being contributed by the community. I've found flaws in every single library I've used so far, and they are flaws not present in their Python and Ruby counterparts.

Error handling in Node.js is one of the worst of any language.

NPM is now deploying breaking changes to production, without apology.

Javascript is also a terrible language for larger teams, unless everyone follows the same exact convention, as the language itself is extremely flexible, more so than any language I've seen.

I've spent 2 years in this ecosystem, and pretty much anything else feels liberating in comparison, be it Python, Ruby, Go, Erlang, etc etc.

The only thing Node.js has going for it is a community of front-end developers who want to dabble in backend architecture, but I just feel this whole entire ecosystem is too fragile for my tastes.

Like MongoDB, as people begin creating successful businesses out of it and reach a certain scale, similar articles bashing Node.js are all but inevitable.
SSL  certificate  Zertifikat  Node.js  Socket.IO  sockjs  libraries_programmers_tools 
march 2014 by snearch
How I want to write Node: stream all the things | Hacker News
aegiso 14 hours ago | link

> JS's lack of strong typing limits your ability to reason about streams (a lot more than just streams, too) and further limits your ability to write performant stream computing software

I think you missed my point so I'll restate: in practice you don't reason about streams in Node, because the community (a product of the simplicity of the streams API) has a packaged solution to your problem. It plugs right in. And this ecosystem exists because of the simplicity and dynamicity of the constructs used.

I actually agree with you that Haskell does it "better". It's purer and cleaner. You'll probably have less bugs if you write everything in Haskell.

Except it doesn't matter to me, because Haskell doesn't have anything close to the plug-and-playability of npm modules -- and this is a pure social product of the stupid interface that Node exposes compared to Haskell. Node is shittier, and that's why it's more capable at solving the problem I have -- constructing powerful apps in close to no time, and zero lines of my own code.

I guess what I'm saying is that sometimes worse is better.


codygman 12 hours ago | link

Can you qualify "Haskell doesn't have anything close to the plug-and-playability of npm modules" because I don't quite get what you mean? Maybe it is because I can't think of anything plug-and-play in node that isn't plug-and-play in Haskell.


aegiso 1 hour ago | link

Sure. I want a git server with push notifications. Two lines with the pushover module in node.

I would be pleasantly surprised if this existed at all in the Haskell community. Even more so with two lines of my own code.

Node.js  Streaming  asynchronous_event_processing 
february 2014 by snearch
Make No Promises | Hacker News
graue 2 hours ago | link

This is definitely some impressive performance. In Firefox 24 the core.async example is significantly faster than When.js on average (though in repeated trials, the running times vary over wide (and overlapping) ranges).

Some commenters seem to assume David's point is "use core.async because it's faster than promises". I don't think so. My takeaway from this post is that, having been persuaded core.async is awesome and will give me joy as a programmer (and see David's other posts for evidence of that, e.g. [1]), performance concerns should not prevent me from going for it, because it's competitive.

For me personally, Clojure and ClojureScript still have a long way to go to catch up with JavaScript-based development using Node.js and say, Angular. A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective. I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server. Here, Node frameworks like Derby[3], which emphasizes sharing nearly all your code, and Airbnb's Rendr[4], seem light-years ahead.

But when you consider that this is an early release of a language and async lib written by a surprisingly small team, with basically no corporate backing, it's a pretty amazing accomplishment. I love ClojureScript in theory and I'm eager for the day when I can love it in practice too.






ddellacosta 2 minutes ago | link

I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server.

I think this is definitely a "the glass is half-empty" interpretation. I mean, let's point out that you're complaining about an environment where you can share code between a codebase running on the server and one on the client--and it isn't JavaScript. And it's not ideal? Of course it's not ideal. But you can do inter-op with Java (server-side) and JavaScript (client-), using the same syntax, and with cljx, you can do this in the same file. This is freaking awesome, even with the messy bits that come along with it, in my opinion.

A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective.

As far as this point, there's less I can disagree with: the community, while small, is awesome, but there is a way to go before ClojureScript, at least, is going to have the ease of "install and get going" that you have with other platforms. Everything from testing to getting a reasonable console up and running is in a state of flux and cannot be favorably compared to JavaScript, other than the argument that ClojureScript provides a better enough programming experience to outweigh the ease-of-setup that JS provides. For me that's more than enough, but for others I can understand that it's not, yet.

But it absolutely is improving, very quickly. We really need more people to be using CLJS and hyping it (as David Nolen is doing) and putting in the time to shave the yaks that need shaving--as people like David Nolen, Kevin Lynagh ( as well as the aforementioned cljx), Chas Emerick (many contributions, but recently, Mimmo Cosenza (the fantastic Modern CLJS series: and many others are doing--so that we can get to that point where the advantages clearly outweigh the disadvantages. I think that time will come, but it's going to require some serious work.

But even now there are compelling reasons to use ClojureScript, including libs like core.async. I think you'd find that, with a bit of patience, there is a lot there to keep you invested in the tools and the community.

masklinn 25 minutes ago | link

> The purpose of a promise is to allow an asynchronous operation to be cancelled.

It's not, and the javascript Promise/A spec has no such facility.

Promises — at least in javascript which is the language observed here — are used to return asynchronous results and be able to combine them in various manners (chain, multiplex, select), but not to cancel them.

The purpose of promises in javascript is very much to improve upon callbacks-based systems in order to make them easier to understand and reason about, and more composable.
Webdevelopment  Clojure  ClojureScript  CONs  Node.js  Derby.js  Rendr.js  Angular.js  core.async  Promises  purpose  higher_quality 
august 2013 by snearch
What it’s like building a real website in Node.js
Some of the libraries can save you a ton of time

I found that one of the features I wanted in the site was a facebook login. While I’ve previously dealt with facebook connect in php and found it relatively painless there I expected something like that might be a headache in node. After finding the connect-auth library it turned into a piece of cake with a little monkey see monkey do thrown in from following the examples. I wanted to interact with S3 to store images and found a wonderful project called knox. Pretty much anything you can think of theres probably a tool that integrates with node that is of high quality and actively developed.
Node.js  Facebook  login  S3  connect-auth  knox  libraries_programmers_tools  Webdevelopment  What_it’s_like_building_a_real_website_in_Node.js 
june 2013 by snearch
javascript - How to decide when to use NodeJS? - Stack Overflow
ou did a great job of summarizing what's awesome about node. My feeling is that node is especially suited for applications where you'd like to maintain a persistent connection from the browser back to the server. Using a technique known as "long-polling", you can write an application that sends updates to the user in real time. Doing long polling on many of the web's giants, like rails or django, would create immense load on the server, because each active client eats up one server process. This situation amounts to a tarpit attack. When you use something like node, the server has no need of maintaining separate threads for each open connection.

This means you can create a browser-based chat app in node that takes almost no system resources to serve a great many clients. Any time you want to do this sort of long-polling, node is a great option.

It's worth mentioning that ruby and python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that node does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with json native to both the client and the server is pretty nifty.

I look forward to reading other answers here, this is a fantastic question.

Edit: It's worth pointing out that node is also great for situations in which you'll be reusing a lot of code across the client/server gap. The (currently brand new) meteor framework makes this really easy, and a lot of folks are suggesting this might be the future of web development. I can say from experience that it's a whole lot of fun to write code in meteor, and a big part of this is spending less time thinking about how you're going to restructure your data so the code that runs in the browser can easily manipulate it and pass it back.

Edit: Here's an article on Pyramid and long-polling, which turns out to be very easy to set up with a little help from gevent: TicTacToe and Long Polling with Pyramid
Webdevelopment  Node.js  PROs  print!! 
june 2013 by snearch
Ask HN: Is NodeJS stable enough to build the next Twitter? | Hacker News
russell_h 2 hours ago | link

We've built the control plane to Rackspace Cloud Monitoring in Node.js, and overall the experience has been positive.

A few things to look out for:

1. Error handling. In node you can't just wrap your code in a try/catch. And even if you register a listener for uncaught exceptions, you almost certainly have state shared between requests (for example, a database connection pool), which makes trying to handle such exceptions risky. To use node effectively, you need to be very careful to prevent exceptions from being thrown in unexpected locations.

2. Code rot. It is a lot less obvious what is idiomatic in Javascript as compared to Python, etc. Its easy to end up with a wide range of styles and patterns, which make maintenance difficult.

3. Missed or double callbacks. These are interesting mostly because they are not something you would see in synchronous code, and they can be quite difficult to troubleshoot (especially double callbacks).

Mitigating these issues is as much a cultural challenge as it is technical. Lint everything, review code aggressively, and don't merge code that doesn't have tests. Choose libraries carefully (the ecosystem has come a _long_ way in the last few years).

All of that being said, these are things you should be doing anyway. Develop a good tech culture, but get your product out and grow your user base. If you become the next Twitter you'll have the resources to undo any mistakes you make now.


olegp 1 hour ago | link

We are using Node at and I agree with most of the points above.

Error handling is the major issue, because you need to handle all errors manually, i.e. you can't use try catch to trap all errors further down the stack. If you don't handle all errors your Node process will terminate and you may lose some state. Even if you're confident in the stability of your code, I strongly advise that you use a watchdog process like supervisor to start a new process if the current one terminates.

We've handled this issue and kept business logic code simple by using which uses fibers to present synchronous APIs, allowing us to use exceptions for error handling.

Be very careful when choosing third party packages, since if they don't handle all errors, again your process will terminate and there's nothing you're able to do about it, even if you're using fibers.

One last issue is changes to the core APIs. Since some of them are still in flux, it is advisable to provide an abstraction layer above them so as to be able to weather any changes. For example when streams2 came out, we only needed to upgrade Common Node, with no changes to the application itself.

fooyc 10 minutes ago | link

Node.js itself is fine.

The real problem with node.js is the libraries. Just don't use them.

A huge portion of existing libraries is full of hidden bugs, shortcomings, race conditions, edge cases, security issues, unscalable, or unmaintainable (and unmaintained).

This is exacerbated by the fact that npm makes it really easy to publish a library.

Many small buggy libraries.

Core modules are too low level (e.g. http), and you really don't want to use an overlay library.

Not to mention that doing something not trivial fully asynchronously is not as fun as it sounds. You will spend a significant time tracking bugs, fixing edge cases, and making your code stable.

There is still no way to make async code better in core (no promises); and there are a handful of incompatible promises implementations.

Oh, and node.js is not really fine actually. It's not doing everything using asynchronous I/O as you would expect. Node.js uses a thread pool for things like DNS resolution and disk I/O. Only 4 threads by default, for all those things with very different latencies. This means that 4 DNS queries can occupy node.js's 4 hidden worker threads, and block your disk I/O for minutes.
Node.js  CONs 
may 2013 by snearch
Building HTML5 Apps with Yeoman and Backbone | Hacker News
Wintamute 57 minutes ago | link

A quick word of warning for anyone following this guide. You should never sudo npm install. That's giving root privileges to anyone that care's to upload code to the npm package registry. npm should work fine without sudo.


sneak 5 minutes ago | link

Furthermore, it doesn't appear that any of these fad language repositories do any sort of package signing, so you're vulnerable not just to the people who upload their own code, but anyone who may compromise the mirrors, too, because even if you trust the source, there's no way of verifying the code hasn't been modified on the mirror.

See also:

Webdevelopment  warning  npm  Node.js  print!!  Yeoman  Backbone.js 
may 2013 by snearch
Blazing fast node.js: 10 performance tips from LinkedIn Mobile | LinkedIn Engineering
Note that everything on this page, except for the user's name, is static: that is, it's identical for every user and page reload. So a much more efficient approach is to have Node.js return just the dynamic data needed for the page as JSON:

{"name": "John"}

view raw ReturnJustJson.js This Gist brought to you by GitHub.

The rest of the page - all the static HTML markup - can be put into a JavaScript template (such as an underscore.js template):
Node.js  Tipps_und_Tricks  Webdevelopment  underscore.js  Templates  Framework  Express 
may 2013 by snearch
« earlier      
per page:    204080120160

related tags

002  ActiveRecord  adduser  Afrika  AIM  AJAX  Akka  amazon  Android  Angular.js  API  application  appropiate_size  Arduino  Ashkenas_Jeremy  async  async.js  asynchronous_event_processing  Authentication  await  AWS  AWSBOX  Backbone.js  Backbone_on_the_client_and_the_server  Backend  benchmark  bm  book_recommendation  Bootstrap  Bottle  browserify  C  C#  C++  callback_hell  Calypso  Cappuccino  casper.js  certificate  chat  Chatroom  cheerio  Client/Server  Clojure  ClojureScript  cloud_computing  Coco  code_sharing_tool  Coffeescript  CoffeeScript  Comet  CommonJS  Compilerbau  Composer  connect-auth  connect.js  CONs  core.async  CORS  CouchDB  cps_continuation_passing_style  criticism  Csikszentmihalyi_Mihaly  Dahl_Ryan  Dart  Databases  Debugging  demo  deployment  Derby.js  Development  DigitalOcean  Django  dnode  Docker  Dokku  DOM  ebay  EC2  Eclipse_Scala_IDE  eintauchen  embedded  Embedded_Systems  env.js  epoll  Erlang  error_handling  eventing_framework  EventMachine  event_loop  Expres  Express  F#  Facebook  fd  FFI  Filo_David  Firefox-Lesezeichen  Flask  Flow  forever  for_beginners  framework  FreeBSD  Freelancer  functional  FunScript  fun_in_programming  get  Gevent  Golang  Google_TV  Gorilla  GorillaScript  Grafana  Gunicorn  hapi  Hardware_Basteleien  Haskell  Hayes_Ted  Heroku  higher_quality  Homebrew  Home_Automation  html  html5  http  http-server  Hypermedia  IDE  InfluxDB  Insightful  inspiration  Interpreterbau  Interview  iOS  Jabber  Jade  javascript  Jaxer  jquery  JSON  Kal  kaufen  knox  kqueue  Lernherausforderung  Lernprojekt  Lesezeichen-Symbolleiste  Let's_make_a_Web_App  libev  libevent  libraries_programmers_tools  libuv  Lift  load_limiting  login  long_running_commands  Lua  LuaJIT  LuaNginx  Luvit  MEAN  MEAN_Stack  Meteor  mgo  mich_produzieren  Middleware  mobile  model  modern  modern_JS  module  MongoDB  MongooseJS  Multithreading  MzScheme  nconf  NeDB  new  new_architecture  NFC  nginx  Node-RED  node.js  Node.js_won  Noodlejs  NoSQL  NowJS  npm  OAuth  Objective-C  OCaml  Odersky_Dr._Martin  offer_web_services  OOP  Opa  OpenSSL  OSCAR  PaaS  Padrino  Perl  phantom.js  Php  Php5  Play  PNG  POE  poll  polling  Postgresql  print  print!  print!!  print!!!  Prism  Profiling  programming  Promise.js  Promises  PROs  protocol  purpose  Python  Qt  rabbit.js  RabbitMQ  Racket  RAD  Rails  RaspberryPi  Raspberry_Pi  React.js  reactive  Rendr.js  request  REST  Restify  reverse_proxying  RFID  Rockway_Jonathan  Roden_Golo  RPC  Ruby  S3  Sails.js  Scala  scaling_website  screen_scraping  Security  select  Selenium  server_side  Shell  Sinatra  Sinatra_Framework  Single_Page_Apps  smart_home  SOA  Sock.IO  Socket.IO  Sockets  sockjs  Spine.js  SQL  SSE_Server_Side_Events  SSL  Stack  Standardisierung  static_typing  StatsD  streaming  streams  Stylus  Swift  System_Administration  Templates  template_engine  testing  The_Road_to_Node.js_v1.0  Tipps_und_Tricks  TLS  TOP  Tornado  Tornado_Framework  TowerJS  trampolining  Trend  tutorial  Twisted  Typescript  TypeScript  underscore.js  uWSGI  V8_Javascript_Engine  v8_Java_Script_Engine  Video  vServer  warning  webcast  webdesign  webdevelopment  webdriver  WebDriverJS  webhosting  webserver  Webservices  websockets  What_it’s_like_building_a_real_website_in_Node.js  WiFi  wireless  Wordpress  XBee  XMPP  Xvfb  Yahoo  Yeoman  Zertifikat  Zigbee 

Copy this bookmark: