audreyt

Understood. Not meant as a show-off, but for people interested in comparing DOM-only versus AngularJS styles, here is a version that uses only DOM functions: https://audreyt.github.io/500lines/spreadsheet/as-without-an...

Thanks!

Here is the version — by popular demand — that only uses DOM methods and does not use Angular, still clocking at 99 lines:

https://audreyt.github.io/500lines/spreadsheet/as-without-an...

I have joined some short statements, but each line is still at most 99 characters.

Source code is at: https://github.com/audreyt/500lines/tree/master/spreadsheet/...

It was an interesting exercise — thanks for suggesting it!

Glad you liked it! This is my first serious attempt at "literate programming" style writing; it did take many attempts re-arranging the functions in logical order for the prose to make sense.

In my previous writeups such as http://g0v.asia/tw/ , I've followed SPJ's "writing a paper" guidelines ( HN: https://news.ycombinator.com/item?id=6989806 ) — almost to the letter — which was immensely helpful as well.

Fair point. I should have explained the context better; this is for "500 Lines or Less", the fourth in the Architecture of Open Source Applications series, aimed more at new students than professional programmers, so separation of concern serves a pedagogical, rather than practical, purpose.

In a couple year's time, Web Components, Shadow DOM, and Object.observe may very well make application of this size not requiring AngularJS anymore, just like the "no tool at all" document.querySelector replaced jQuery.

I'd be happy to revise the chapter once a suitable polyfill exists for today's browsers — pull requests welcome, too!

Hi, thanks for the feedback! Sorry if it comes across as bragging; the line count is kept minimal both to reduce reader's cognitive burden, and make inline commentary feasible.

Technically, Web Worker is not a library, and Traceur is used to translate ES6 to ES5 while browser support catches on, so AngularJS is the only library used.

The non-Traceur ES5 version at https://github.com/audreyt/500lines/tree/master/spreadsheet/... has exactly the same line count, but with more idiomatic workarounds that's less clear to students new to web development (the audience of this book).

It is possible to replace AngularJS (the only external library) with regular blur/focus/change handler as @xem shows — without affecting the line counts — but the separation of concerns between view, logic and worker would be less clear.

There's http://ethercalc.net/ — the subject of the spreadsheet chapters in two previous volumes of Open Source Architecture series at http://aosabook.org/.

EtherCalc is mostly in maintenance mode at this moment, and the "99 lines" engine described here is an attempt to simplify its core logic both for educational and refactoring purposes.

The work by you, @aemkei et al was the inspiration for this chapter. :-)

Back when it appeared on HN, the first thing I entered was =(function(){for(;;){}})() — which predictably froze the browser.

Trying to find a sufficiently-robust way around this restriction ended up shaping the Web Worker based structure. So, thanks for the inspiration & golfing!

Thanks! The aim for the chapter is indeed to show how ES6 and AngularJS simplify a typical web application like this.

The version at https://github.com/audreyt/500lines/tree/master/spreadsheet/... has exactly the same line count, but with more idiomatic workarounds that's less clear to students new to web development (the audience of this book).

It is possible to replace AngularJS (the only external library) with regular blur/focus/change handler as @xem shows — without affecting the line counts — but the separation of concerns between view, logic and worker would be less clear.

Indeed. https://github.com/audreyt/500lines/tree/master/spreadsheet mentions AngularJS and ES6 upfront, but in retrospect it'd be better to mention them in the title too. Thanks for the reminder!

Part of the motivation behind PgREST is to get a reusable and generic enough upsert implementation as a stored procedure; see https://github.com/pgrest/pgrest/blob/master/test/upsert.ls for details.

Well, http://pgre.st/ was posted 167 days ago here — https://news.ycombinator.com/item?id=6818284 — that's how we do everything in PostgreSQL without having to turn to another language :-)

It's like Kanso/CouchApp for CouchDB, and has support for the functional/object-oriented/new-fangled LiveScript language on top of the v8 engine.

Still working on the homoiconicity part, though!

TL;DR: We refactor Scripts into Programs through sharing reusable Code to build maintainable systems.

We can also refactor Social Scripts into Social Programs through sharing Codes of Conduct to build maintainable communities.

"They" is just me and our wonderful & kind contributors. :)

EtherCalc was, is, and will remain a F/OSS infrastructure project, not a business enterprise.

I'd just like to thank the loomio team for supporting Taiwan's #CongressOccupied activities as chronicled in http://0sdc.tw/en — you played a key part in ensuring a safe and successful process, and will likely help on our future of constitutional reform as well.

http://g0v.today/congressoccupied/https%253A%252F%252Fg0v.ha... has some background information in English.

I've built an app that worked well with Cordova: https://play.google.com/store/apps/details?id=org.audreyt.di... ( Source: https://github.com/g0v/moedict-app/ ; Context: http://g0v.asia/tw/#Q1.2 ).

A dictionary — being text-based, with very few animations, and no background soundtracks — avoided most of mobile-platform-specific issues.

Io and behold — lambic pentameter.

(lo, as in a lota; lambic, as with an Iamb.)

Well, for some, trans* is their preferred gender. That is, the experience of transition forms part of their identity.

Compare, say, people who self-identify as "German-American" instead of simply "American".

One possible solution to introduce threads to JS is to isolate threads from each other and use only message-passing:

https://github.com/audreyt/node-webworker-threads/

The default Lazy IO issue has been addressed in pipes-bytestring:

http://www.haskellforall.com/2013/09/perfect-streaming-using...

The pipes ecosystem ( http://www.haskell.org/haskellwiki/Pipes ) is working well to offer {effects, streaming, composability} without the resource leak issues introduced by lazy IO.

Coco: I'd rather be writing Perl-flavored Ruby.

LiveScript: I'd rather be writing Perl-flavored Ruby, with a Haskell syntax. ( http://livescript.org/ )

Well, limiting the range, commonly associated with a paging (or infinitely scrolling) UI, entails tie-breaking somehow.

A simple tiebreak function — such as lexicographic sorting on keys — means when the user requests "next page" via another range request, the same-scored second value will predictably show up on the beginning of next page, which is how users will expect in the real world.

Hope this helps!

Agreed on all accounts, with one small, specific clarification:

If computation is local to each of many long-running threads, and the two-way messages being passed around is small enough (so the serialization overhead is negligible), then threads do perform better on multi-core machines than alternative models.

EtherCalc.org is one such use case: http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm...

Hi, maintainer of https://github.com/audreyt/node-webworker-threads/ here.

We're using it happily in production, and it's proved to be quite stable, and there's quite a few users — certainly more than the average amount of emails I get from other projects. :-)

It's true that I haven't heard from the earliest adopters (like Uber.com), but it might be a sign of its maturity rather than abandonment.

The last commit was 2 month ago, and only to repair compatibility with the then-just-released V8 version. It will likely require another commit for Node 0.12.0 — pull requests welcome!

Edit: Just released v0.4.8 to npm with references to the http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm... writeup.

Yes, we're certainly inspired by Kanso.

PgREST was originally designed for a large, in-production Postgres app (i.e. Socialtext), so we can get all the model, validation, view & trigger code in one place, getting the benefits of CouchApps while maintaining the underlying data layer.

For new projects, the main difference is likely familiarity with the toolchain (npm+Pg vs Kanso+CouchDB).

... it was, in fact, partly inspired by the Markov chain hack. #BuzzwordBingoButTrue :-)

For authentication (authn) it's quite easy, and in production we do have a separate authn daemon.

For authorization (authz) it's IMHO a bit better to handle it in the DB level, similar with Firebase's ACL lists.

Excellent question! The REST API part should be familiar to any Rails programmer.

The main difference is that back-end models, validation rules, triggers and views are coded in DB level via stored procedures written in Node.js-compatible modules, so it's enforced for both SQL- and HTTP-speaking clients.

As you pointed out, this is simply an instant JSON-over-REST API server on top of existing Pg databases, and is not intended to replace the need for traditional frameworks with server-side templating.

Well, this is more like an open-source (partial) reimplementation of Firebase so anyone can host it... :-)

Firebase++ for an extremely well-thought-out API, though!