jed_watson

I phrased it badly - I meant the modal scroll handling that was implemented hasn't worked out well, no red flags for React here. position: fixed is a more robust way of positioning modals, the current version watches the scroll event and updates the modal's position which is pretty janky; and it does some not-great things manipulating overflow on the body too, which causes the bug mentioned. We'll be fixing that in the next release.

Not sure if you saw my other comment below but this is a major goal for us with Elemental. We're not there today, because we're working through the best way to componentize the CSS for each module while retaining a common base for variables & customisation (i.e themes).

The most likely outcome will be to go with the "css in components" approach (w/ Radium, I expect) and maybe a base / "foundational" optional stylesheet for typography / etc. Still working it out though - all today's viable approaches have lots of pros and cons.

Thanks for pointing that out - webre using react-router and it works locally, not sure why hosting on github pages breaks it. Will check it out.

It means we've borrowed the css directly from Bootstrap for the grid (as well as some variables and mixins) so, aside from giving credit, if you are familiar with the bootstrap grid it should be easy to get up and running with Elemental.

We're actually developing it first and foremost for use in Keystone's Admin UI - we needed a robust and flexible css + component library for that, which users could extend & build plugins on, so we started building one.

Elemental UI is a competitor, sort of, I guess. But it's not a zero-sum game, and we've learned (and borrowed) a lot from Bootstrap.

More specifically, we're not porting Bootstrap to React but building React-specific components from scratch to fill the same gaps.

Something in particular we're focusing on is building a modular IU toolkit - so you could use all of Elemental, or just our select component / buttons / date picker / etc; all of which would be available as standalone packages on npm, but can leverage a consistent thumbing system and play nicely together.

(And yes - we'll fix that modal issue soon with a pure css approach; a community member wanted to implement it with JavaScript but it hasn't worked out well)

Thanks! We're porting their grid system manually at the moment, the foundations don't really change much and we're quite selective about what's being ported.

We're actually experimenting with deprecating access to classes (i.e exposing components rather than class names as the public API) - will be interesting to see how popular that approach is.

2. LESS has been our favourite pre-processor for a white but we're finding it doesn't play well with packaging modular components on npm. Some real limitations around the @import logic, and the core team refuse to make it to work with node-style require path resolution which is disappointing.

From here I think it's more likely we go with the "styles in components" approach (via Radium or similar) and make variables / themeing available via context. Much easier to package & use "out of the box". Might keep a "base" css include though, or possibly use the Bootstrap 4 "Reboot". The distinction between, and best way to package, component styles and page styles is something we're putting a lot of thought into!

Thanks! that's really great to hear.

Have you heard Pete Hunt's angle on "Separation of Concerns" vs. "Separation of Technologies"?

imo JSX doesn't fall into this trap, it just looks like it should.

His JSConf EU talk is worth a watch if you're interested: http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be... (slides: http://www.slideshare.net/floydophone/react-preso-v2)

I'm not familiar with the benefits of HostGator but how is this better than spinning up a free Heroku dyno to serve your node.js app?

That's also a very effective solution for low-traffic sites with a modest amount of host-side processing and more than enough for one sale a minute.

It's got great options for 3rd-party service integration too (e.g. free MongoDB hosting for < 512mb with MongoLab), and a very node.js friendly environment / deployment workflow.

Not trolling, genuinely curious what the benefit of this would be as an alternative.

Yes - we've already got it working with iOS and android using Cordova, Windows should be straight-forward as well.

There's a Cordova project that builds for iOS in the sample project if you're interested.

We won't be limiting the look to iOS 8, we just started there because it's the platform we're developing some commercial apps for using TouchstoneJS at the moment. At least two of them will end up on Android as well, so we'll get to that.

Down the track it will including a theme capability and a more Android-friendly UI style, I'll add something to the roadmap to make this clearer.

Cheers! We're fans of Ionic ourselves (and use their excellent icon library)

I think the biggest differentiating factor between it and TouchstoneJS will be the platforms they're built on.

Ionic's heavily invested in Angular, which is great, but we're big fans of React and wanted to create a new mobile framework that builds on that.

Thanks! We're stoked with the great feedback this is getting.

We will have more docs + examples up in the coming weeks, aside from that we're currently using it in three commercial apps at Thinkmill so what's there is pretty solid.

The projects we're building with it include a Bitcoin wallet (built on BitcoinJS), a cinema voucher scanning app and another I unfortunately can't talk about yet. It's holding up really well across the different use cases and UI designs.

It is, and the source for the demo is here: https://github.com/Thinkmill/touchstone-starter

Thanks for letting me know. We haven't had a chance to test yet on a wide range of Android browsers, but it shouldn't be like that.

If you could open an issue on the GitHub project (http://github.com/JedWatson/touchstonejs) with details of your OS version and browser I'd really appreciate it!

Nope, I think you're spot on.

You need a lot more control over how the views transition, pass state, etc. in order to create a native-feeling app.

The paradigm of links and parameters falls short, and eventually TouchstoneJS will exert a lot more control over the transitions. Right now we're using CSSTransitionGroup, but I expect we'll move to a JS-based transition method (possibly with tween-state) so you can do controlled or partial transitions (required for things like drawers or swipe-from-left to go back)

We have spent a lot of time looking at react-router though, and are using it on other projects, and are / will be borrowing quite a few things :)

The app framework is structured as a React mixin, everything else (lists, form controls, etc) is just React Components you can drop into your app. So for the most part how you structure your app is up to you (except for the scaffolding necessary for the view transitions). It's inspired by react-router (after the recent changes) in terms of getting out of your way.

Other than that, aside from needing some sort of compilation step for the JSX (our demo project uses browserify and gulp) the rest is up to you.

I haven't used Om or Reagent yet but I don't think there'd be anything preventing them from working with Touchstone.

Thanks! we're putting a lot of detail into the animations to make it feel as native as possible. The touch events too - you'll notice that if you touch a link, and move too far away, it'll un-hilight; then if you move back it activates again, just like on iOS. Or in a scrolling panel, scrolling cancels the touch event.

We've had a great experience building with React, and browserify - it keeps everything organised and modular, and is pretty much perfect for mobile app architecture.

I was just thinking a similar thing. If user agents have evolved to effectively become a way of saying "Our browser supports standards X" (where X is an awkward grouping based on which features vendors and browser versions originally supported the feature / standard), surely the ultimate solution is to provide a header enumerating support on a per-feature basis.

Obviously it would take a while for the standard to be adopted to the point where it was useful, but as a web developer I dream of a time when we receive a header that lists the supported features in the client (similar to the classnames modernizer adds to the document body, and probably eventually versioned) and no longer have to resort to either UA parsing OR javascript-based feature detection, both of which are hacks because this problem hasn't actually been solved properly at the standards level.

I run a web development company in Sydney called Thinkmill (http://www.thinkmill.com.au).

We use Node.js for everything we do, from mobile app backends to websites to web apps. We've been using it for nearly two years, and found it fantastic - compared to technologies we've used previously it's faster to develop in, faster to run, easy to deploy (especially with platforms like Heroku) and the value of npm and the ecosystem of high quality open source packages is hard to overstate.

We have also developed an open source Node.js model-driven CMS / web app framework called KeystoneJS (http://keystonejs.com) which is built on Express and MongoDB and has been getting some great feedback :)

The biggest lesson / gotcha has been getting into the different mindset - especially when we started, there wasn't a lot of 'hand holding' available compared to other languages and frameworks, and there were few established best practices to follow. I think it's easier these days (there's certainly more out there) but I'm very familiar with it now so it's hard to gauge from a beginners point of view.

It's easy to fall into traps with callback patterns and error handling, for example - so you really need to get your head around what's out there (like the async library for example), and how to structure your application and code.

Honestly, I see very few thought-out or backed-up arguments here. The server-level blocking, the unacknowledged writes, silly defaults, etc are not only old news but have been behind mongodb for a while.

You also get comments like 'it still has database level locking' but rarely is there an educated discussion about the work that's been done to yield locks as quickly as possible and the real-world impact of this design.

People seem intent on punishing the platform for old mistakes (or immaturity) rather than providing a balanced view of it today. And comments like "Absolutely no benefit to Mongo. It's even really slow, so there's really no advantage at all." are just misleading without context, because it's at all true as an outright statement.

I spent today at the MongoDB developers conference in Sydney, and heard the CEO speak about when they think mongodb is good vs when you should use RDBMS, heard them speak about their community and target market, and heard a lot of stories and strategies about how to prepare for scale, how to think about schema design, how to monitor and admin the database / clusters, etc.

I'll just say that from hearing them in person, and hearing what people say about both the platform and the "marketing guys", you'd never know they were talking about the same company or product.

My own company has had a lot of advantage from using MongoDB in recent projects over other technologies (we have a largely MSSQL background). No, we don't do 100GB+ "web scale" (yet). Yes, we build solutions to real world problems and make money. No, it's not a silver bullet. Yes, you should know what you're doing and read the docs.

To any hackers / entrepreneurs who are thinking that MongoDB might work for them I'd say do some research, talk to people who've actually used it, and understand the benefits / limitations for yourself.

But stay away from opinions not based in real experience (and anything that mentions problems from before version 2.4, it's nearly a year old people) or you might miss out on something good.

There's also a demo online at http://demo.keystonejs.com - it's very simple but you get the idea of how to structure an app, the source code is on github.

If you want to check out the admin ui, you can sign in to the demo at http://demo.keystonejs.com/keystone with the username demo@keystonejs.com and the password demo.

I'm working on a web app framework / cms for node.js built on express.js and mongo called KeystoneJS, and have been for a few months.

Keystone makes it easier to get a blog / website / web app up and running without a lot of the module research or boilerplate code node.js usually requires. It also provides a beautiful, useful admin UI (think activeadmin for rails).

It's open source (MIT), and cool because...

* There isn't really anything like this for node.js yet (that we've found). There are a so many great modules and you can plug in almost anything, but getting projects off the ground requires a lot of boilerplate compared to frameworks like rails or django.

* It makes sophisticated things trivial by providing drop-in patterns - like session management and auth, and clever fields for your models, e.g. location fields and image fields (which make for a better admin UI but don't abstract too heavily the underlying data the fields represent).

* We're trying to build an "out of the box" system that doesn't keep you in the box. You can use what you like and swap out what you don't. You can use Jade or Handlebars. Plug in any express middleware you like. Use the built in auth system or provide your own.

* It's all based on the best practices my team have come up with in over a year of node.js web app development and we're using it to power several commercial, production projects. So it's got real-world usage and solves real problems.

* Quite a few people have said this is a gap in the node.js ecosystem, and ultimately if Keystone is just useful for us and a handful of others that's fine, but it would be really exciting if we could start something that helps node.js grow or helps other web developers use the platform. Especially for projects where rapid development is important, and having a great admin UI available would be the difference between using node.js and not.

If you're interested check out http://keystonejs.com

The opposing philosophies haven't changed - AngularJS really wants you to live in an AngularJS world and is a framework, whereas Backbone is more of a library and can be used to enhance your app (or parts of it) as well as providing structure.

Subjectively, they're both very popular although Angular seems to be growing faster while Backbone has been mature for a while.

If you're comparing them, remember it's apples and oranges - my company used Backbone recently in a mobile app and we loved the flexibility to use the parts that were helpful (Views, Events) without having any enforced application structure. It feels very light-weight but leaves much of the decisions up to the developer (there are frameworks like Marionette that provide more structure if you want it)

On the other hand Angular (or Ember for that matter) is great when you want to use it to drive your entire UI, and makes a lot of sophisticated behaviour easy to set up.

So I'd say they're very different solutions to client-side MV*, and not really competing. You'd use the one that suits your problem and how you want to build your app.