Live data from Hacker News

Isobuild: why Meteor created a new package system

meteor.com

41–50 of 54 posts

Re: Isobuild: why Meteor created a new package system

#41

That website is a prime example for https://news.ycombinator.com/item?id=8237996 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?!

There's a huge .JS file in there, it has the whole site or so it seems. It has content: * the blog * Other pages like Get involved

Re: Isobuild: why Meteor created a new package system

#42
post #25

Earlier quoted context omitted.

Sure, if you control the server. I guess these Meteor packages will only be useful in those contexts. But what if I want to use the Twitter API, for example?

I believe Twitter is trying to kill their API, hence no CORS or JSONP.

The point is that only HTTP.get() inside browser require CORS to be enabled on the server side. On non-browser environment, HTTP.get() can open any cross site web request.

Re: Isobuild: why Meteor created a new package system

#43
post #4

Everything about Meteor reads like a marketing article. 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?

I don't think that's fair at all. 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.

I'm curious, what part of Meteor will be a requirement for future web development? Are we not already building big distributed, interactive web apps without using techniques that Meteor introduced?

Re: Isobuild: why Meteor created a new package system

#44
post #42

Earlier quoted context omitted.

I believe Twitter is trying to kill their API, hence no CORS or JSONP.

The point is that only HTTP.get() inside browser require CORS to be enabled on the server side. On non-browser environment, HTTP.get() can open any cross site web request.

Well the point is any other API will face the same restrictions in the browser. It isn't something JavaScript code can fix directly. If you need to call external services from the browser (and not everybody does), the isobuild APIs certainly don't make the situation worse.

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.

Re: Isobuild: why Meteor created a new package system

#45
I really don't mind about the packaging system, I think that the meteor team should put special emphasis in solving the scalability issues, cos right now (IMO) is the major barrier for adoption.

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

Re: Isobuild: why Meteor created a new package system

#46
post #4

Everything about Meteor reads like a marketing article. 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?

I can't agree. I used Meteor to rewrite an app that I had previously used Clojure and Clojurescript for. 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.

What about when it becomes mildly popular and you have to rewrite it again because it isn't cost effective to scale at all? It isn't time saved, it is time wasted.

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.

Re: Isobuild: why Meteor created a new package system

#47
post #46

Earlier quoted context omitted.

I can't agree. I used Meteor to rewrite an app that I had previously used Clojure and Clojurescript for. 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.

What about when it becomes mildly popular and you have to rewrite it again because it isn't cost effective to scale at all? It isn't time saved, it is time wasted. 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)…

Hello jcrotor. I think that a Meteor app could easily handle hundreds of simultaneous connections on a very small server.

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.

Re: Isobuild: why Meteor created a new package system

#48
post #43

Earlier quoted context omitted.

I don't think that's fair at all. 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.

I'm curious, what part of Meteor will be a requirement for future web development? Are we not already building big distributed, interactive web apps without using techniques that Meteor introduced?

Currently, I don't think Meteor's main advantage is bringing new capabilities, but rather providing a platform for building modern web apps.

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.

Re: Isobuild: why Meteor created a new package system

#49
post #27
post #12

Nitpick: does the term "isomorphic JavaScript" to describe JS that runs on both the client and server annoy anyone? Where's the isomorphism? 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…

Iso = Equal. Morph = Shape. Isomorph = Same shape. 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 cla…

Math and CS are close enough that I think they should be nice neighbors and respect one another's terminology. I use the mathematical term "isomorphism" daily almost hourly while programming.

Re: Isobuild: why Meteor created a new package system

#50
post #49
post #27

Earlier quoted context omitted.

Iso = Equal. Morph = Shape. Isomorph = Same shape. 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 cla…

Math and CS are close enough that I think they should be nice neighbors and respect one another's terminology. I use the mathematical term "isomorphism" daily almost hourly while programming.

> should [...] respect one another's terminology

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?

Post reply on HN