Hey HN, this is the first of several libraries I will be open sourcing, and they will all be building off each other and culminating into something epic. So please, by all means, I'd love to hear your thoughts and ideas.
It is thoroughly tested: IE6-10, FF3.6-23, Opera 11+, Safari 5+, Android 2.3.4+, iOS 6.1.3+, Windows 8phone, Chrome, and Node.
Sure! Thanks for asking. I'm laying a solid foundation with all the primitives of Javascript, then I'm building ontop some really elegant controls - so the libraries won't have any assumption, but you still get some powerful features. I eventually hope to create a tactile-spatial programming language with it.
All code is just three things: Data, Manipulation, and Communication. Theory represents having good control over data, with strong type checking.
>I eventually hope to create a tactile-spatial programming language with it.
Do you mean that figuratively or literally? I can't tell if you're working towards some super OOP magic or good support for like 3D vectors and events.
However you mean, I like the sound. Looking forward to seeing what else shakes out!
EDIT: I am now noticing your myojs stub and thinking that you mean "tactile-spatial" quite literally.
I was working on something that has a lot of overlap, but is more focused on scaffolding html from json structure. Mine also allows wildcard get and set :)
ex: obj.get('a.*.b') -> returns all b's in objects that are of the array 'a'
You can always do "a.text(myVariable).is()". I like your last version though, it seems clean. Your first variation was confusing for me, though. I was trying to keep all type operators neatly packaged in their respective type, though - isn't that cleaner than having dangling types?
It was confusing for me because it's using English words, but reading the code is the opposite of how you'd say it in English. I wouldn't ask/think "text myVariable is" (some languages would, I know), which is how "a.text(myVariable).is()" reads. Rather, I would say, "is myVariable text", which would correspond to "is(myVariable).text()", which reads that way in English (I know, a bias).
"a reliable yet tiny library (at 7KB gzipped) that would
normalize everything so any code written would literally
work everywhere"
I felt the same way about needing to normalise client and server side, but the goal seems forever ambitious, considering not even IE8 can handle an extra trailing comma. This is not the only universal solution you will be using.
It already works on IE8! :) From my experience, IE isn't as bad as what people complain about (with js, it is horrid with rendering though), and a few tweaks of code makes it work, which generally makes the code even better on other browsers. People really don't need as many shims and polyfills as they think. Rendering though? Gosh that is a nightmare.
You realize, I assume, that you're making a lot of quixotic choices in this library, many of which appear to be different for personal (and, in some cases, I would say dubious) reasons. 1-indexed arrays? Arrays are no longer objects? An 'each' function that uses it's own way of combining what countless languages before you have split into 'map', 'filter' and 'each' functions? Etc etc.
I'm going to hazard a guess that your work has been predominately if not exclusively as a solo dev. This is effectively your personal utility library. That's cool. The problem is that virtually all software eventually ends up being a team effort, if nothing else than by the guy/gal who has to work on it after you. You may not like how JS does some things (like zero-indexing), but that guy already knows JS, he doesn't know your library. By revamping core semantics of JS, you're forcing him to learn your opinions. Are you so sure of your opinions that you can confidently say it's worth everyone else undergoing that effort? Are your opinions really so important as to break compatibility with every other piece of JS?
I gather from your comments that you intend this library as the base of a larger project. I'd encourage you to base that project on more widely known foundations -- pick your favorite module system, and use underscore.js or one of the other widely vetted and tested utility libraries.
Yes, it is the base for a lot more. Unfortunately I have tried and used countless other libraries for the last 3 years, and they always wind up breaking - in fact even underscore failed to pass some of my tests, and I had to patch a bug with it.
The only library I have been able to consistently trust is jquery. At a certain point as a developer you have to decide what is best for you and your code, and in my case it is relying on this library, because I know I can trust it.
I would love to use other libraries, unfortunately I wasted too much time (years) trying to fix them up for what I needed and they still become unmanageable. I am glad your projects are simpler and don't push the limits of existing libraries, but don't dismiss my goals or act like you know what they are just because yours are not as intense.
Generally I have found that the libraries that are loud and popular wind up performing inferior to more obscure libraries which I use. Not that the loud ones are bad, they just can't handle my specific projects.
24 comments
[ 2.7 ms ] story [ 27.6 ms ] threadIt is thoroughly tested: IE6-10, FF3.6-23, Opera 11+, Safari 5+, Android 2.3.4+, iOS 6.1.3+, Windows 8phone, Chrome, and Node.
All code is just three things: Data, Manipulation, and Communication. Theory represents having good control over data, with strong type checking.
Do you mean that figuratively or literally? I can't tell if you're working towards some super OOP magic or good support for like 3D vectors and events.
However you mean, I like the sound. Looking forward to seeing what else shakes out!
EDIT: I am now noticing your myojs stub and thinking that you mean "tactile-spatial" quite literally.
ex: obj.get('a.*.b') -> returns all b's in objects that are of the array 'a'
Shameless plug: https://github.com/dclowd9901/lscenery
Suppose I'm thinking, "hmm, is this text?" or "is this a number?"
To do this with the API you have looks like this:
But just reading the code makes is backwards with respect to the phrase it represents (my bias). A more intuitive API call might be: Even better might be: Just some thoughts. Reading the API calls the way they are keeps sounding wrong in my head (clearly a bias).Check out my gist I posted, should be on a comment-branch nearby.
a(myVariable).is.text
or
a(myVariable).is().text
Either way for me.
https://gist.github.com/amark/6298069 include as a dependency then use as "a.is(myVariable).text"!
I'm going to hazard a guess that your work has been predominately if not exclusively as a solo dev. This is effectively your personal utility library. That's cool. The problem is that virtually all software eventually ends up being a team effort, if nothing else than by the guy/gal who has to work on it after you. You may not like how JS does some things (like zero-indexing), but that guy already knows JS, he doesn't know your library. By revamping core semantics of JS, you're forcing him to learn your opinions. Are you so sure of your opinions that you can confidently say it's worth everyone else undergoing that effort? Are your opinions really so important as to break compatibility with every other piece of JS?
I gather from your comments that you intend this library as the base of a larger project. I'd encourage you to base that project on more widely known foundations -- pick your favorite module system, and use underscore.js or one of the other widely vetted and tested utility libraries.
The only library I have been able to consistently trust is jquery. At a certain point as a developer you have to decide what is best for you and your code, and in my case it is relying on this library, because I know I can trust it.
You might like lodash.js if cross-browser consistency is your true goal.
Generally I have found that the libraries that are loud and popular wind up performing inferior to more obscure libraries which I use. Not that the loud ones are bad, they just can't handle my specific projects.