Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 2: What Happens Next

discovermeteor.com

Post reply on HN
Print view View original

131–140 of 153 posts

Re: The State of Meteor Part 2: What Happens Next

#131

Post by neximo4 »

raffomania wrote: post #126
neximo4 wrote: post #118

Meteor started off so brilliantly. I wish the team would focus and just make it great. Many people would complain about SQL and what not but the truth is there's a very large number of people who are quite happy with MongoDB and the fast experience building an app. However there are some really big issues that seem to be ignored: 1) It's nice that its backwards compatible but some essential features are missing such…

I especially agree with 3). I was expecting more people to mention this. Compared with other build systems like wepback or gulp, meteor rebuild times are insane. edit: Just checked out the Meteor Roadmap, and build times are not even mentioned there.

It used to be. The current implementation is the result of the effort in speeding it up.

Re: The State of Meteor Part 2: What Happens Next

#132

Post by hornbaker »

huula wrote: post #106
apalmer wrote: post #16

I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…

+1. Meteor should try to optimize their build time (for example, when I just changed one JS file, there's no point to spend more than 20 seconds to reload a simple page) and be frontend agnostic. The main thing I like Meteor (and also why I'm still sticking around) is how it manages data and the DDP stuff. Never a fan of Blaze, but certainly not sure about this "future vision".

I gave up on Meteor because of 10-20 sec build times. They have to fix that.

Re: The State of Meteor Part 2: What Happens Next

#133

Post by tvararu »

addicted wrote: post #115
Everhusk wrote: post #96

Earlier quoted context omitted.

Meteor fills a need. When a developer starts a new javascript project he/she is stuck with the task of choosing from an array of frameworks, backends, libraries, bundlers, etc. Also, like jQuery, Meteor is doing something in the opposite direction as all of these other frameworks. Rather than being just one piece of the pie and leaving the rest up to the developer, it simplifies development end-to-end (in theory).

I haven't used Meteor but that makes it sound like .Net WebForms. Is that accurate?

I haven't used ASP.NET Web Forms but from giving them a brief look I would say so. Combined with SignalR.

Re: The State of Meteor Part 2: What Happens Next

#135

Post by pacnw »

dfischer wrote: post #76
matthewrudy wrote: post #26

Meteor's best trick has always been data synchronization. That was the magic trick that sold your client. They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up. But that trick is now 4 years old, and nothing else of substance really emerged. As Ember, Angular and React grew, you were never going to want to use their odd looking front end. Their data sync als…

GraphQL and Relay may be the answer but it's too young to make that switch now and Meteor is solving that exact problem. Meteor has the momentum and community to take it further. Maybe it actually adopts the GraphQL standard and unifies it into the ultimate dev UX experience.

Yeah, I went down the Relay/GraphQL rabbit hole for a good 1.5 months last year, but unfortunately there is a tremendous amount of work to set up GraphQL servers to even get your data out to Relay, and it is not real-time at the moment (although the 'community' appears to be work on it. I so wish Meteor would provide a drop-in module for just the DDP, I don't even care if its Mongo, their real-time subscription works.

Re: The State of Meteor Part 2: What Happens Next

#136

Post by rafaquintanilha »

frandroid wrote: post #97
gravity13 wrote: post #95

Earlier quoted context omitted.

The comments in here today are a bit out of touch. >You can't do that with React. You can. Other than React's rather hefty size, there's nothing stopping you. React is just a view layer, is unopinionated about how you get your data to it, and for rendering to a DOM needs nothing other than a DOM node to render into. Try it out. You can have 100 different React components slowly eating your legacy app alive. You just…

> You just gotta be smart about it. They said _no fuss_.

Drop a React component in the middle of a legacy project is IMO less fussy then jQuery code. I say that because components are standalone, so you won't mix logic for that piece.

Re: The State of Meteor Part 2: What Happens Next

#137

Post by oelmekki »

Mootools is not an ancestor of jQuery, it actually was released after jQuery (by a few days).

From what I recall, the success of jQuery was not because it allowed to do more things. It was mainly because developers by then considered javascript as a lower citizen language and wanted to do frontend stuff without having to learn javascript - and jQuery allowed just that.

For (the few) javascript lovers, jQuery main advantage was to be a big decorator, not extending any native, which guaranteed there will be no conflict with other libraries when adding jQuery in a page (quite ironic, when you see how all libraries expect jQuery may be present in the page, nowadays).

Re: The State of Meteor Part 2: What Happens Next

#138

Post by jordanlev »

addicted wrote: post #115
Everhusk wrote: post #96

Earlier quoted context omitted.

Meteor fills a need. When a developer starts a new javascript project he/she is stuck with the task of choosing from an array of frameworks, backends, libraries, bundlers, etc. Also, like jQuery, Meteor is doing something in the opposite direction as all of these other frameworks. Rather than being just one piece of the pie and leaving the rest up to the developer, it simplifies development end-to-end (in theory).

I haven't used Meteor but that makes it sound like .Net WebForms. Is that accurate?

If this is true then no wonder meteor hasn't gained the popularity they were hoping for. Webforms just tries to put this layer of abstraction over the web, which severely limits its flexibility, and means you are developing against webworms as opposed to the web itself. I know some people and companies are willing to make that trade off because they want the rapid development benefits, but I think the majority of experienced developers understand the long-term drawbacks to this scenario.

re: popularity of jquery... jquery makes it easier for you to interact with the DOM. WebForms (and maybe meteor? I don't know) makes it HARDER to interact with the DOM.

Re: The State of Meteor Part 2: What Happens Next

#139

Post by lambdacomplete »

codesuela wrote: post #127
lambdacomplete wrote: post #116

Dove into react and redux and built a couple of small apps. They are amazing not because they add some "fancy" features but because they train you to think with a different, much cleaner and simpler, mindset. Before your brain "clicks" you feel miserable. After it does you think "why on earth isn't everybody using this??" and any problem is solvable by dispatching actions and building reducers (thank you Redux!). Thr…

I don't know if you are aware but there is now an official guide which goes way beyond the scope of the docs. http://guide.meteor.com/

Yes I'm already reading that. Thanks for the hint!

Re: The State of Meteor Part 2: What Happens Next

#140

Post by ufukbay »

incepted wrote: post #51
apalmer wrote: post #16

I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…

jQuery filled a need. It's as simple as that. Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with. Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much…

I wouldn't say that jQuery is something that should be avoided. It depends on your current experience in JavaScript. I remember that our designer at a former company was preparing the HTML markup and CSS styles for us (mainly JavaScript developers) and he was comfortable using jQuery for prototyping animations and other stuff.

The more I learned about frontend technologies the more I started to realize where it makes sense to use jQuery and where not. With increasing knowledge one starts to think more about optimizing code and reducing the amount of libraries used etc. At the current company I'm working now, we also had use cases where we had to use native JavaScript due to some restrictions.

All in all, we still have a fair usage of jQuery and I honestly don't see anything wrong with that.

Post reply on HN