Isobuild: why Meteor created a new package system
meteor.com
meteor.com
How about:
- It defines global variables. - The documentation is full of red warning messages and "this will be easier in the future" - The code is pretty unorganized and has some wild pieces in there. - do any of your friends use/heard of meteor?
The whole point of Meteor is to play with different approaches to web development that will be required in the future (if you want to build big distributed, interactive web apps). It's not finished yet, and they're pretty upfront about that.
So it is different than any one javascript framework in that it's goal is to bring together a complete set of technologies that are needed to build an app, rather than the developer joining different pieces themselves.
Currently many developers work with separate multiple frameworks, and Meteor brings them together into a cohesive, power, clean API.
Meteor is amazing, and even with the rough edges, and evolving API, it is still a joy to work with. They are thinking about the big picture and it really allows the developer to focus more on the creative aspects of your app. I am excited to see Meteor evolve over time.
It is faster to rewrite an app having written it once already, but still: it took half the time, had better user login/auth, and had sort-of real time multi-user support.
Meteor is very nice. Try it on a small project. The learning curve is easy.
People that don't or haven't tried to understand node.js or express like meteor. Picking up meteor is easier, but its not all that useful at the moment. There are other frameworks that are better than meteor and allow you to achieve the same end (realtime).
Don't get me wrong, it is neat, and I am glad they are exploring a new area of development, but promoting it as anything other than a pet project is misleading.
Meteor is for writing highly interactive/reactive applications and I don't know if it is even meant for massive scaling.
There is a sweet spot for Meteor for apps that will not have millions of users.
When I think of isomorphism I think of two things that look different but have the same structure. If you had a set of functions that are synchronous and a set that are async, then maybe you can call the sets isomorphic. Or if you have a Python library that mimics a command line tool, then they could be isomorphic.
Isomorphic JavaScript = JavaScript that takes the same shape [in multiple environments].
You're thinking isomorphism as math terminology but it isn't. It's just borrowed from Greek. From a quick search it means "same shape" in regular English too!
Your nitpick would be akin to being annoyed by the use of "group" to mean "a number of people or things considered or classed together" because it has a specific meaning in math.
I see your point, but IMHO isomorphic is a word, not math terminology. Math borrows words from regular languages, but it can't expropriate words!
The first thing I think when reading "isomorphic" is "same shape" even though I know what a math isomorphism is.
Just notice how function means something completely different in programming and math, but we're so used that nobody nitpicks on HN.
Math permeates everything, borrows and loans words. More examples:
- Electrical Engineers use finite ground planes even if a plane is by definition infinite and has no thickness.
- Music is pretty much math, but their chords are not segments inside circles.
- We use braces {} to delimit blocks, not sets.
- We flip bits in a non-geometrical sense.
- The DOM has events even though there are no statistics involved.
- We compress files even though they're not geometric objects.
- We use domain names.
And so on. It's the beauty of language! Our libraries are full of functions instead of books. If there's no chance of ambiguity, who cares?
And the use of "function" in computer science for things which are hardly at all functions is a source of massive confusion and pain in the interface between the two fields. I believe personally that it leads to an enormous amount of improper education and broken intuition.
Let me provide another example—variable. This one is far worse than "function" in the confusion caused by its poor appropriation into computer science. The concept of variable is extremely well-designed in mathematics crafted over hundreds of years of philosophical and mathematical debate... and then it also become a mutable slot in Algol and stuck to every mathematician's chagrin.
It's not a good idea to copy technical words and abuse them in similar fields. It'd be as though people in the airplane industry started calling propellers "rockets" all over. Rocket comes from Italian "rocchetto" meaning bobbin/cylinder and so the shape of a propeller engine fits that definition and words are just words right?
Certainly, but that's just unnecessarily confusing. The person who popularized that terminology would be rightfully considered a fool.
So you love silly arguments too! :P
Perhaps our "disagreement" stems from how used we are to isomorphic as a common word. My mother language is full of greek and latin loanwords/particles in common speech. If I had to guess it's not as pervasive in yours. Or maybe you've been exposed to a lot more math than me! Who knows.
I still can't help but read iso+morph separately (as equal+shape) in "isomorphic javascript".
New words are not a common occurrence, especially when existing words fit the concept (such as isomorphic = same shape; variable = its value can vary; etc.) or parallels can be drawn (function = takes arguments and computes a value; chord = probably because there is a _circle_ of fifths in music where you can draw literal chords).
I see how it can be confusing on tech fields though, but that's just how language works. You could argue there are better alternatives to "isomorphic JavaScript", but to date it's been the only proposal.
That said, I'll try to keep my linguistic creativity to a minimum in tech ;)
I think there's a lot of room for creativity in technical fields (étale morphism comes to mind) but typically once a word has a technical definition it is made off-limits within relevant fields. Terminological blurriness is nice sometimes, but often technical terms are incredibly concrete.
To me "isomorphism" means exactly "a pair of arrows, called witnesses, (f, g) in a category such that fg = id and gf = id" and it confers many properties. If you find a category where {Server Javascript} and {Client Javascript} are two objects and exhibit an isomorphism then I will gladly let you call that object "isomorphic javascript" all day long. Frankly I'm already feeling "isomorphism" fails to capture the nature of this relationship, though.
And to be honest, I still don't get why this requires a new package manager. NPM (with a utility library, perhaps) could perform most of these functions.
You can still use exactly the same code in the browser and on the server. Allowing stuff like server-side rendering on old browsers and JS rendering for the majority of users from a single piece of code.
If you are in a client browser (any client browser, no matter how old) and try to do HTTP.get('http://www.google.com') it will fail because of CORS restrictions. If you do that on the server or in a native app, it will succeed (because they do not have CORS restrictions).
if anything, isn't this a great argument for a client/server package manager? you could write a library that knows to use and create a proxy if a specific client type tries to fetch cross domain.
Working around CORS is just a matter of server configuration. With the same API you only fix the servers, with different APIs you have to fix both the servers and the code.
Also HTTP.get() may be smart enough to detect cross-domain call failure and try to automatically proxy the call. Meteor has a server-side component that can act as a proxy.
I suppose it's nice that they bundle some functionality in like `camera`, but I don't see why that would be an "isopack" thing and not just an external library.
And anyway, doesn't building a framework-specific package disregard the "isometric" ideal: write once, run anywhere?
(as long as "anywhere" means that it's using meteor.)
Coupling the goal of building isomorphic apps with the need for a new way of managing packages to accomplish that goal doesn't make any sense. How you install packages and manage dependencies has absolutely no bearing on what you can or cannot do with those packages.
In other words, you can write fully isomorphic apps using npm as your package manager. We're already doing it.
"If you think about it, if we tried to build all of the above on top of npm, it would be npm in name only. Even if Meteor packages were in npm, you wouldn't use the npm tool to find or install packages (you'd use a wrapper that implemented the 'release snapshots', 'curation', 'repeatability' considerations), nor could you drop them directly into existing npm applications (per 'client vs server' and 'asset bundling')."
With Isobuild and Cordova, you'll be able to add a camera package
to your app and use one simple Camera.takePicture() API to take a
photo, and then type one command to build your app not just for the
browser, but for the iOS and Android app stores too.When I just started with Cordova, I went to a HTML5DEVCONF talk where the speaker tried to install (just install) Cordova in a 20m slot. He failed, his slides had all the ingredients (Xcode, jdk, ant, maven, npm, cordova, ios-sim, etc) but on the live demo his new machine failed because some of the many steps wasn't satisfied.
About using Cordova: again, for newcomers, it is so non-obvious: what do you do when your build fails? How do I debug this objective-c code again? Why the heck Cordova doesn't give me all the logs by default? ios-sim is an npm module that is compiled with a C compiler and the build process is navigated by rake - ruby-based make clone.
I find really useful all the features they're launching but there's no way I'm going to pay for a 8Gb and quadcore server just for supporting 100 concurrent visitors...
I started building a real-time webapp with meteor and had to switch to express + primus which was a much more efficient solution (orders of magnitude).
I really hope they do something about it ASAP... I really enjoyed working with meteor and still use for small projects, but for a medium/big app? not yet...
It's really just text and a few images, nothing fancy, an ordinary blog post - yet it freezes my browser for what feels like half a minute while it uses 100% CPU for rendering. What the fuck?!