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

A 220b spreadsheet app in HTML/JS

xem.github.io

Post reply on HN
Print view View original

81–90 of 105 posts

Re: A 220b spreadsheet app in HTML/JS

#81

Post by xem »

fiatjaf wrote: post #77
projectant wrote: post #43

I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this?…

Well, this spreadsheet as it is now isn't very much useful. In fact it is annoying at best. Only programmers will find it amusing and precisely because of how small the code is. No one is actually going to use it ever.

good thing we made it just for fun, then

Re: A 220b spreadsheet app in HTML/JS

#82

Post by dheera »

abainbridge wrote: post #78
jahnu wrote: post #37

Earlier quoted context omitted.

I'm more concerned with the use of the symbol `b` to denote bytes instead of `B` :)

Yeah. A 220 bit spreadsheet would be impressive. Particularly the achievement of the source length not being a whole number of bytes.

If you include start and stop bits it works out.

Re: A 220b spreadsheet app in HTML/JS

#84

Post by vidarh »

dannyw wrote: post #64
vidarh wrote: post #55

Earlier quoted context omitted.

Hilariously Chrome offers to pass the c code through Google Translate (with predictably useless results)

Language detection works on language trigrams, and are trained on human language. I bet punctuation is stripped during preprocessing. So it's not surprising that code will have false positives.

Not surprising, but still funny when applied to obfuscated code.

Re: A 220b spreadsheet app in HTML/JS

#85

Post by xem »

xem wrote: post #18

Hello World, I'm xem, author of this mini app, but standing on the shoulders of giants: it's inspired by http://aem1k.com/sheet/ which was inspired by http://jsfiddle.net/ondras/hYfN3/ Cheers to all the JS codegolf team who teached me this noble art and continue to learn new tricks everyday with me! You can find a list of all our mini apps here: https://gist.github.com/xem/206db44adbdd09bac424

NB: as mentioned in the "AMA" page, the whole team also helped a lot to reduce the size of this app after I got into the game, it's not just golfed by me.

Cheers

Re: A 220b spreadsheet app in HTML/JS

#86

Post by xem »

aaln wrote: post #71

This is awesome, are you planning to add more features like complex functions that are minimally sized?

Well, it's a 3 years old app, and we like it in this "minimal" form. We've made a lot of other mini apps, tools and games though, you can find the link on top of xem.github.io/sheet

Re: A 220b spreadsheet app in HTML/JS

#87

Post by nkoren »

darth_mastah wrote: post #83

I hate to say that, but I just seem to have broken it. Here's how: I put 0.1 in A1, 0.2 in A2 and =A1+A2 in B1. Now B1 displays "=A1+A2" instead of the result.

Looks like any decimal place breaks it. Whole numbers only. But hey, whaddaya want for 220 bytes?!?

Re: A 220b spreadsheet app in HTML/JS

#88

Post by ajanuary »

vog wrote: post #59
usrusr wrote: post #46

Earlier quoted context omitted.

Is there really no middle ground? Sanitizers fail because they try to salvage the clean part, only blacklisting some possible inputs. But what if you turn it around? Only send to eval what fits through a matcher for a very small subset of the language. The matcher can even allow invalid inputs if you know that eval will safely reject them (think unbalanced brackets). That matcher will be much easier and safer to impl…

> Only send to eval what fits through a matcher for a very small subset of the language That's exactly what I meant by "dedicated expression parser". (Not sure why you name it "matcher", though. Please be aware that a regex-based matcher will almost certainly fail for that task. You usually want a grammar, i.e. parser, which is more powerful, and shorter, and easier to read and to verify.) EDIT: To those who downvote…

There is a difference between a recogniser, which answers the question "does this belong to the language", and a parser, which outputs a data structure. All you need here is a recogniser, and then pass the string through to eval which will do it's own parsing. Recognisers are smaller than parsers.

If you relax the rules, as the gp said, you can get away with something like a regex to do the job. While regex's are bad at context free grammars [0], if you forgo balancing brackets etc. a regex will do just fine.

All that said, with the crazy things JS lets you do [1] a recogniser for a relaxed language is likely to still let potentially dangerous code though.

[0] Yes, with most regex engines you can parse CFGs, but it's not nice, and at that point you _do_ want a grammar based parser

[1] http://www.jsfuck.com/

Re: A 220b spreadsheet app in HTML/JS

#89

Post by debacle »

warent wrote: post #6

Judging by some of the comments one can regularly find on HN about the size of apps, this may be considered a pinnacle internet technology to be standardized mainstream Tongue in cheek aside, very creative code. Thank you for sharing

There's intrinsic value in doing more with less, especially when it comes to the malleability of code.

Re: A 220b spreadsheet app in HTML/JS

#90

Post by [deleted] »

ajanuary wrote: post #88
vog wrote: post #59

Earlier quoted context omitted.

> Only send to eval what fits through a matcher for a very small subset of the language That's exactly what I meant by "dedicated expression parser". (Not sure why you name it "matcher", though. Please be aware that a regex-based matcher will almost certainly fail for that task. You usually want a grammar, i.e. parser, which is more powerful, and shorter, and easier to read and to verify.) EDIT: To those who downvote…

There is a difference between a recogniser, which answers the question "does this belong to the language", and a parser, which outputs a data structure. All you need here is a recogniser, and then pass the string through to eval which will do it's own parsing. Recognisers are smaller than parsers. If you relax the rules, as the gp said, you can get away with something like a regex to do the job. While regex's are bad…

[deleted]
Post reply on HN