Show HN: Theory.js – Abstraction layer for cross-platform JavaScript | Hacker News Reader

Show HN: Theory.js – Abstraction layer for cross-platform JavaScript

github.com

28 pointsmarknadal25 comments

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.

Can you give us a hint about the destination?

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.

Indeed indeed! ;) :D Thanks for the encouragement.

Cool, best of luck!

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.

That sounds a lot like the definition of NIH attitude.

You might like lodash.js if cross-browser consistency is your true goal.

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.

    "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.

I realize this is a nitpick, but the use of "is" after the various types is very counter intuitive.

Suppose I'm thinking, "hmm, is this text?" or "is this a number?"

To do this with the API you have looks like this:

  a.text.is(myVariable); // to check if myVariable is text
  a.num.is(myVariable); // to check if myVariable is a number

But just reading the code makes is backwards with respect to the phrase it represents (my bias). A more intuitive API call might be:

  a.is.text(myVariable); // reads like the phrase
  a.is.num(myVariable); // reads like the phrase

Even better might be:

  is(myVariable).text(); // nearly self documenting this way
  is(myVariable).num(); // ditto

Just some thoughts. Reading the API calls the way they are keeps sounding wrong in my head (clearly a bias).

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).

True true, hmm, what if I tried something like "a(myVariable).is.text()"?

Check out my gist I posted, should be on a comment-branch nearby.

I like that as well. Or, as mentioned by noiv, we could do:

a(myVariable).is.text

a(myVariable).is().text

Either way for me.

I would buy is(myVariable).text within a second. Why calling two functions?

This is a good idea too! Here we go, I made it a tiny module:

https://gist.github.com/amark/6298069 include as a dependency then use as "a.is(myVariable).text"!

Great, that's very readable. Now someone needs to allow .text? to indicate the predicate without 'invalid token ?' :)

yeah, that's good too.

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'

Shameless plug: https://github.com/dclowd9901/lscenery

I was enthusiastic until I got to the part about 1-indexed arrays.

But does it support do-while loops?

I look for this feature in all my libraries.

Reply on news.ycombinator.com