81–90 of 336 posts
I can't read the site (there's nothing in HTML) but is this a framework that doesn't produce pages viewable without JavaScript? If it is against HTML, my vote is against it.
http://docs.meteor.com/#spiderable Could this could be used if the browser does not support JS?
It depends on your definition of kill. If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java. Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter). I do agree that using one language…
Earlier quoted context omitted.
Definitely not today when the tools, the best practices, the state of the libraries are still below average and the developers have varying skill sets. Who knows 5-10 years down the line...
I'm sure 10 years down the line someone will be raving about how the latest NinjaScript based framework is going to be the death of Foo#, and anyone who doesn't think so should go back to their crusty old enterprise Ruby legacy code.
Enterprises use Java or .Net.
It depends on your definition of kill. If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java. Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter). I do agree that using one language…
Ruby is the worst language ever, because I do not know how to use it.
It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net. - Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa. - Both tout the ability to do all your development in a single language - Both claim impressive gains for RAD ASP.Net had some impressive demos for its t…
If this guys is going off about how it shaves a week or so off a 5 week project, problems that appear on bigger apps might not be high on his priority list.
I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)
I still have the hope for a unified platform. But I'd much prefer it to be on a solid language that compiles down to JS. I'm not sure it's an unattainable goal. I think you nailed it with "seamless" and "invisible" - abstracting major things like client versus server, or local versus network, can really end up biting developers.
Earlier quoted context omitted.
Care to elaborate? I'm a Java developer, but I'd guess you're referring to browser fragmentation, not the JS language.
No, I'm referring to the languages themselves. JS does a very few things better than Java, but it is simply chock full of bizarre type coercion rules, strange semantics, and other "hall of mirrors" gotchas which make it much harder to learn and work with than other dynamic languages. And yes, Java has some of these too, but they occupy a much smaller share of the language base, and are often a side-effect of useful f…
While I was reading this post, the page automatically reloaded to something that said "oops, this page can't be found", and then a few seconds later loaded back to the original. This is while I was simply reading the text, not interacting with the page at all. Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
Earlier quoted context omitted.
Insert mis-attributed Henry Ford quote about customers wanting faster horses
So, now you agree with what carsongross originally asked? The client does just want an app and you believe you know better and foist a broken javascript app on them?
Why do people put so much effort in comparing tool A to tool B when either of those tools only cover 5% of all the work that goes into any serious application, and the time saved by any advantage tool A has over tool B is pretty much negligible? I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites. It's always the same story, a shiny…
That's what makes these frameworks popular with HN: startup founders are not in the business of executing on a known business model (which might be viably accomplished even through a waterfall process and code written in C); rather, we're in the business of searching for a business model by building MVP after MVP, as quickly as we can.
MVPs don't need to be able to be evolved into stable, well-engineered products. They just need to prove product-market fit. Once you've got your traction, your proof, your intent-to-buy, you can use that to get the loans or capital, to hire the talent, to build the Well-Engineered Version. Until then, "engineering" is not even a consideration.
It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net. - Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa. - Both tout the ability to do all your development in a single language - Both claim impressive gains for RAD ASP.Net had some impressive demos for its t…