Obligatory CoffeeScript version: http://jsfiddle.net/hYfN3/759/
(Uses a regexp instead of `with` statement as CoffeeScript forbids with).
A spreadsheet in fewer than 30 lines of JavaScript, no library used
251–260 of 274 posts
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#252It's not really comparable, but minimalistic spreadsheet applications always remind me of Dan Piponi's Haskell `loeb` function [0]---a "one-line" "spreadsheet" "implementation". The blog post is very interesting to read, but here's the meat. We're looking for a function with type loeb :: Functor f => f (f a -> a) -> f a and without thinking about the meaning of it, we can implement it as loeb x = fmap (\a -> a (loeb…
Here's a solution to the Twitter waterflow problem with loeb: http://chrisdone.com/posts/twitter-problem-loeb
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#253Really clever hack. Also looked around the original Angular spreadsheet the author offered as a inspiration, the 'hacky' components boiled down to this too parts:
1. Data binding.
Angular: ng-model, ng-controller, relying on Angular's magical $scope
This: custom defined object getter, essentially making the data resides in the DOM input elements (while keeping a copy in localStorage)
2. Expression evaluation
Angular: $parse service
This: 'with' and 'eval' in the same line. Despite its double 'evilness', this is really clever.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#254Neat! Not quite the same thing, but see also this 9-line "spreadsheet" written in Python by Raymond Hettinger: http://code.activestate.com/recipes/355045-spreadsheet/
Very neat.
Thought I'd have a crack at doing something similar in Rebol. Here's my attempt:
Rebol []
; Here's the beef!... the spreadsheet object
spreadsheet: context [
update: func [block /local b] [
b: compose/deep block
bind b self ; so action happens in object context
do b
]
]
; make sheet with following cells
ss: make spreadsheet [
a1: 5
a2: does [a1 * 6]
a3: does [a2 * 7]
]
; simple usage example
print ss/a3 ; => 210
ss/a1: 6
print ss/a3 ; => 252
; use /update method to keep it within the objects context (needed for DOES)
ss/update [a3: does [a1 + a2]]
print ss/a3 ; => 42
; and compose in variables from current context, see (a1)
a1: 1000
ss/update [a3: does [a1 + (a1)]]
print ss/a3 ; => 1006
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#255I am impressed. Its a neat hack, it actually is a real spreadsheet in 30 lines of code, with references fully working (ie =A3+B4 gives expected output. As does =alert("foo") but then nothing is perfect). I think it says something about the browser as a platform - these thirty lines simply assume an enormous amount that excel and visicalc could not - visicalc had to write their own screen refresh routines. It is usefu…
I replied with a blog post, which goes into detail regarding what I believe is the single, critical aspect that is currently holding up innovation in spreadsheet technology: the ability to run untrusted code without compromising security.
http://dbpokorny.blogspot.com/2013/11/the-online-spreadsheet...
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#256Just yesterday there was that Google email from 2010 talking about how JS can not evolve any further. It made me feel a bit wasteful about my time spent with the likes of node and angular. Seeing things like this reminds me how much JS is capable of in today's browsers and also shows me how much more I need to understand about the language. Awesome stuff.
It's important to remember that when someone is justifying the existence of a new project, claims like " can't evolve to meet the needs of " are highly suspect.
[deleted]
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#257Earlier quoted context omitted.
And 80% of perceived functionality is what most users — even people who rely on spreadsheets for their work — need. I'm not saying including the other 20% of functionality isn't a good thing to do, but when you're creating a new product or open source project, you can get by (and thrive) building only the 20% of functionality that's used 80% of the time. Why? Because 1% of functionality is still better than 0% (never…
You missed his point. It doesn't actually work well. It doesn't do basic stuff, which makes it entirely unusable. Like you can't move up/down/left/right using the arrow keys. You can't save it. It crashes if you make basic mistakes. The 80% of perceived functionality is that it looks like a spreadsheet app and actually does some basic calculations. It actually does about 5% of what you'd expect even the most basic of…
I'd say this is to Excel as MongoDB is to any real database.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#258Impressive. This shows how anything that can be written in Javascript will be written; and what cannot UX wise?
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#259[deleted]
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#260Earlier quoted context omitted.
http://jsfiddle.net/sJXE3/
Sure, table layout is how you'd have to do this. To me this shows that half of HTML/CSS happened because of legacy issues and not with deliberate thought. The semantic web is mostly dead other than to help Google parse out their own ads while CSS remains a mess full of hacks like this.
There was never anything wrong with the table layout algorithm, what sucked was that there wasn't any way to apply it without typing your HTML rigidly to that structure. The situation still isn't perfect and flexbox is a strange alternative that I'm not quite happy with yet, but you can't deny that the HTML in my example represents the content you described with almost no extra layout fluff.