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

71–80 of 274 posts

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

#71

Post by jcampbell1 »

timje1 wrote: post #33
lifeisstillgood wrote: post #22

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

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.

I am a bit lost as to why cycles are handled the way they are. Part of the problem, is cycles seem to crash chrome's developer tools.

If you put =A1 in A1, and =A2 in A2, it crashes the web inspector for me.

I am lost as to why putting =A1 in A1 doesn't cause an infinite loop. Why doesn't eval (DATA.A1) not trigger the getter and hence an infinite loop?

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

#72

Post by [deleted] »

jcampbell1 wrote: post #71
timje1 wrote: 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.

I am a bit lost as to why cycles are handled the way they are. Part of the problem, is cycles seem to crash chrome's developer tools. If you put =A1 in A1, and =A2 in A2, it crashes the web inspector for me. I am lost as to why putting =A1 in A1 doesn't cause an infinite loop. Why doesn't eval (DATA.A1) not trigger the getter and hence an infinite loop?

[deleted]

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

#74

Post by mattmanser »

dictum wrote: post #62
racbart wrote: post #41

This is truly great as proof of concept and also as a reminder that in software development building 80% of perceived* functionality usually takes only tiny fraction of total development time which is required to build final product. * - this app looks and feels like “almost complete spreadsheet” yet it provides much less than 1% features of even a basic spreadsheet.

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 spreadsheets to do. And all the polish of even the most basic functionality is missing, which is what takes most of the time.

Which is why you should always avoid putting a pretty looking but barely functional mockup in front of the pointy hairs. They then think it's almost done.

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

#75

Post by tracker1 »

thatthatis wrote: post #48
lifeisstillgood wrote: post #22

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

A 30 line javascript spreadsheet is similar for me to when I first saw Norvig's 21 line python spelling corrector ( http://norvig.com/spell-correct.html ): this language is more powerful and expressive than I thought. I'm increasingly believing that HTML/CSS/JS in a browser is a viable common runtime. This demo does quite a lot to solidify that belief.

I've felt that way for 16+ years.. of course, 2/3 of that time most developers never took the time to understand/learn JS the language, and then separate that from the horrible browser DOMs in the late 90's. NN's Layers vs IE document.all ... Starting with IE5/6 (and later Phoenix/Firebird/Firefox) it actually got a lot better.

It's definitely nothing like IE4/NN4 days, and it looks like IE8 is finally falling off the radar, with IE9 to follow in the next couple years. It's only getting better. IE8 was really the last relatively bad browser imho. IE9 has some quirks, and IE10/11 are actually pretty nice (though IE11 is the most buggy browser MS has released since IE6, possibly more so).

Yes, there are still browser compatibility issues.. but they are so few and far between for day to day use. Except for WebRTC and WebAudio, things are really solid.

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

#76

Post by ondras »

jcampbell1 wrote: post #71
timje1 wrote: 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.

I am a bit lost as to why cycles are handled the way they are. Part of the problem, is cycles seem to crash chrome's developer tools. If you put =A1 in A1, and =A2 in A2, it crashes the web inspector for me. I am lost as to why putting =A1 in A1 doesn't cause an infinite loop. Why doesn't eval (DATA.A1) not trigger the getter and hence an infinite loop?

The getter impl should prevent this. Firefox, for instance, throws an exception...

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

#79

Post by nmat »

jokeofweek wrote: post #66

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.

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

#80

Post by angersock »

timje1 wrote: post #33
lifeisstillgood wrote: post #22

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

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.

I'm a bit slow this morning...would anyone mind explaining how that and the defineProperties stuff makes a parse happen?
Post reply on HN