{"id":902,"date":"2013-04-03T23:30:54","date_gmt":"2013-04-03T23:30:54","guid":{"rendered":"http:\/\/garysieling.com\/blog\/?p=902"},"modified":"2013-04-03T23:30:54","modified_gmt":"2013-04-03T23:30:54","slug":"philly-ete-metor-js-talk-summary","status":"publish","type":"post","link":"https:\/\/www.garysieling.com\/blog\/philly-ete-metor-js-talk-summary\/","title":{"rendered":"Philly ETE – Metor.js Talk Summary"},"content":{"rendered":"

I went to a talk at Philly ETE<\/a> on Meteor<\/a>, a Javascript-based webapp development platform. The talk was given by Avital Oliver, one of the core meteor developers, on “smart packages,” which is what meteor calls extensions to their core product. While in it’s infancy, the framework appears to be built around rapid development iteration and consistent, easy to learn APIs. They make use of some clever tricks to aid development, such as auto re-loading HTML pages when any underlying file changes (presumably with a library like socket.io<\/a>). They also support some client-side caching which lets you save a good portion of the app in browser, for disconnected use, part of an HTML5 API<\/a>.<\/p>\n

Meteor uses mongodb for a database, with an API available on both client and server, which handles caching and re-drawing the page when data changes. The server is a wrapper around Node.js, to allow for JS everywhere. Coupled with auto-reloading of pages when the source changes, this looks like it makes for a nice development environment, although it seems like it would be easy to cripple application servers or databases if not handled with care. Their approach seems to be to hide many implementation details to ease the learning curve, which would be risky in a demanding client environment, as it’s nice to know how things work if you have to fix them.<\/p>\n

I suspect these types of tools are driven by firms which do smaller-budget web design projects, as they seem built around building small apps as fast as possible. Surprisingly, the Meteor team made no mention of targeting Phonegap- it would seem like an ideal target for a platform aimed at building Javascript apps everywhere. Some research indicates it is possible to get these two to interoperate, but with some effort. The team behind Meteor is aiming to build a hosting platform for their product, and thus make money – presumably they could also get affiliate commissions setting up bundled services (email, twilio, etc).<\/p>\n

The notion of smart packages as designed is interesting; the idea is to allow you to run a build target which adds a sophisticated feature to your project; e.g. support for single sign-on integration, email, LESS, etc, with appropriate defaults and deep feature-sets. The demo-ed features looked cool, although the Meteor team is working to improve the ecosystem of open packages, to the point of taking ownership of projects that community members start to fill gaps, but can’t maintain.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

I went to a talk at Philly ETE on Meteor, a Javascript-based webapp development platform. The talk was given by Avital Oliver, one of the core meteor developers, on “smart packages,” which is what meteor calls extensions to their core product. While in it’s infancy, the framework appears to be built around rapid development iteration … <\/p>\n

Continue reading “Philly ETE – Metor.js Talk Summary”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[15],"tags":[302,365,369,430,440],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t