- https://github.com/facebook/react-art
- http://stackoverflow.com/questions/21854938/using-mixins-vs-components-for-code-reuse-in-facebook-react
- http://www.slideshare.net/murilasso/the-case-for-reactjs-and-clojurescript
- https://speakerdeck.com/coodoo/why-react-and-flux-rock
- https://medium.com/@tomchentw/why-webpack-is-awesome-9691044b6b8e
- http://www.code-experience.com/avoiding-event-chains-in-single-page-applications/
- http://blog.krawaller.se/posts/a-react-js-case-study/
- http://react-components.com/
- https://speakerdeck.com/fisherwebdev/fluxchat
- https://github.com/spoike/refluxjs
- http://www.techsonian.net/2014/09/from-backbone-to-react-our-experience-scaling-a-web-application/
- immuntiable http://facebook.github.io/react/docs/update.html
- http://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/
- http://snapsvg.io/
- http://facebook.github.io/react/docs/getting-started.html
- http://henleyedition.com/flip-a-reactjs-game/
- http://webdesignporto.com/react-js-an-interactive-tutorial-to-get-started/
Created
September 20, 2014 14:49
-
-
Save changtimwu/1a7f0b1c615dd8ed251d to your computer and use it in GitHub Desktop.
study on svg and reacts
Server side state
細心的讀者也許會發現，這兩個問題的癥結，都是因為伺服器缺乏執行試算表指令的能力。如果伺服器在接收到每個指令時，可以自行更新內部的試算表狀態，它其實根本不需要維護指令的積存紀錄。
transfer server side state to a new client and no history(undo data for it.
每個協作時段都對應到一個沙盒內的 SocialCalc 控制器，即時執行客戶端傳來的指令。當新客戶端加入時，伺服器僅需傳送試算表控制器內的最新狀態，從而徹底解決積存紀錄帶來的效能問題。
server side rendering isn't hard.
所以，我們移除了 RenderSheet 函式，用 20 行 LiveScript 代碼 重新實作了匯出 HTML 所需的極少數 DOM 介面，然後再運行了一次效能分析器：
similar cloud architecture
http://packetbeat.com/deploy
full function but web 1.0 UI
http://www.zabbix.com/
L3 route analysis
http://www.packetdesign.com/
http://www.packetdesign.com/images/solutions-images/Troubleshooting%20Image2.png
http://www.packetdesign.com/images/solutions-images/Network%20Operations%20Image2.png
http://www.packetdesign.com/blog/necessity-analytics-monitoring-in-sdn-era
excellent SVG on browser overview -- Leaving Pixels Behind by Todd Parker
https://docs.google.com/presentation/d/1CNQLbqC0krocy_fZrM5fZ-YmQ2JgEADRh3qR6RbOOGk/pub?start=true&loop=false&delayms=5000#slide=id.g272ed8bf3_017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
important knowhow of replay
然而，我們在 2011 年 6 月實地測試雛型時，卻發現隨著協作編輯的執行時段愈長，就會出現愈嚴重的效能問題。由於試算表是長久存在的文件，因此經過數週的編輯，協作時段可能會累積數千筆的修改紀錄。
在前述的積存紀錄模型下，在新客戶端加入協作時段時，勢必遇上明顯的啟動延遲：它得先重新執行數千個指令，才能進行任何修改。為了減輕這個問題，我們採用了快照機制。每當 100 個指令傳送到協作時段後，伺服器就會調查線上每個客戶的狀態，然後將最新收到的快照儲存在積存紀錄中。新加入的客戶端僅需接收這個快照，以及快照儲存之後新輸入的指令即可。這樣一來，它最多只需要重新執行 99 個指令。