271–280 of 336 posts
For those saying Meteor is for toy apps, I just launched a fairly complex app written 100% in Meteor (yes, with paying customers): https://properapp.com . Runs like a charm, easy to develop with, and not even 1.0 yet. Don't dismiss the author, Meteor is going to change a lot.
Earlier quoted context omitted.
This is a discussion about a javascript framework. Meteor relys on javascript on the client and the server so how should it work with noscript? If you want to use a javascript tool you´ll have to add an exception for this tool.
There's no reason why server-side javascript cannot generate static HTML.
"You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state".
I don't think the client is going to want to pay for that kind of interop.
EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when working for people. And you have to absolutely discuss them with clients.
When a client asks for 'hey I want it fast like facebook and some of those cool animations I see wasitcalled haych-tee-em-ell five or something right? also it has to work on iphones because my wife has one', there is a hell of a lot of discussion there about tradeoffs. If the project you are building for them is speculative then even more so shit ain't gonna work for some people because they just aren't going to want to spend the money.
The last small job I did, I got a late requirement of "this actually has to work in IE7, 8 and 9", and stupid me, not hammering this down contractually the interop from the get go it ended up taking up nearly 20% of the budget in the end to get this working retroactively, and this was a small project.
This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…
This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with Perl, PHP, ColdFusion, and WebObjects, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Enterprise JavaBeans anytime soon. I wish something would, but nothing at the moment, is even c…
For those saying Meteor is for toy apps, I just launched a fairly complex app written 100% in Meteor (yes, with paying customers): https://properapp.com . Runs like a charm, easy to develop with, and not even 1.0 yet. Don't dismiss the author, Meteor is going to change a lot.
But why. Why does your app need realtime? That's the part I'm missing. I see a Rails/Angular app right there, and in the end you'll feel good because your data is in the capable hands of Postgres/Mysql
My app doesn't need to be realtime, and that's a narrow way to look at Meteor. Real time is just a nice bonus that the framework enables.
Server side routing: a nice thing for APIs and RSS feeds.
Server side template rendering, because running phantom.js to get SEO is kinda crazy.
Can't get access to any kind of request object/info on the server side because you know, maybe HTTP still matters.
Have to do file/io to get reactivity (save to mongo). Try getting webrtc started that way, it's not fun.
Can't get direct access to who is connected without hacks. See above about webrtc.
It uses mongo, because mongo: http://aphyr.com/posts/284-call-me-maybe-mongodb
It erases event listeners on the client side with reactivity, so the vast majority of JavaScript libraries on the internet are incompatible with it.
The javascript globbing system at load time is incompatible with popular ways to manage dependencies like node'js require or require.js. Like having files load in alphabetical order? Meteor.js is for you!
There actually is a package system, which is the new way to do this, but the old system still exists and the new system while easy to use is not yet documented, last I checked, and you have to create packages just to wrap node.js packages.
Meteorite. Was created to easily hack meteor.js to fix some of the issues already listed, but now is the way to grab things from atmosphere. Meteor comes with packages, but those are all official. I never liked the idea of using Meteorite because you couldn't upgrade Meteor until packages you depended on upgraded too. Now though meteorite is this thing you have to use to import to from atmosphere which has turned into a bunch of wrappers for npm.
The built in less can't import recursively.
I love meteor and if I created a list of all the things awesome about it, it would be larger than those issues up there ^^^ and the team is working on it. They're also really smart people.
I'll make an even bolder claim: Meteor doesn't work at all for anything except small toy apps. Meteor is built on the idea of reactiveness between server and clients. That is if the servers view of the data changes, then the clients views' must also change at the same time. It accomplishes that using websockets and letting each client have a full copy of all the servers data in memory. Works great for simple chats an…
1. Removing the local copy of the DB.
2. Removing the need to use MongoDB.
#1 will let you have your responsive clients while #2 will let your application scale. We've got 2.5TB in MongoDB and I can't wait to get away from it for our use case.
I got a white screen on my phone. Had to switch to my laptop.
Here's the thing. You're building a mainly content-driven site (still the bulk of websites).
If you go down the route of some javascript-based 'app' that squirts all the content in dynamically then you might get everything right and end up with a beautiful, fast website that works across a range of devices, is accessibly, doesn't break bookmarking or the back-button and doesn't kill your SEO.
But you've got to get everything right so the odds are that you'll get a part of this wrong. Debugging and testing are also suddenly a much bigger part of the equation.
So what have you gained over plain old HTML and CSS with progressive enhancement? If you want the possible speed advantages of not re-rendering whole pages then techniques such as Pjax can be used to get the best of both worlds.
In short - with an app-based approach over a html-based approach - there are lots of ways to get it wrong and only a few ways to get it right. You're probably not clever enough to get everything right. Gawker weren't.
Earlier quoted context omitted.
But why. Why does your app need realtime? That's the part I'm missing. I see a Rails/Angular app right there, and in the end you'll feel good because your data is in the capable hands of Postgres/Mysql
Simple: I'm a front-end developer by trade and Meteor gave me something I understood (JavaScript) on both the client and server. To build this in Rails would have meant learning both Rails and Ruby. My app doesn't need to be realtime, and that's a narrow way to look at Meteor. Real time is just a nice bonus that the framework enables.
You're going to take a hit learning any framework, no matter the language. I picked up Rails just as fast as I did Play framework, and I had never looked at Ruby before.
The whole NodeJS appeals to front end programmers thing kind of reeks to me. I think it's an irrelevant argument. I maybe wrong, but an end to end JS stack(MEAN) didn't feel any more right then using Rails.
I believe the future of web programming is REST apis(in whatever the hell language/framework you want) and a nice framework such as EmberJS/Angular on the front end.
I may be wrong, but I have history on my side.