4 ms·
I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Gr
by bsimpson 12y ago
I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.)
Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together could very well be the future of web development. Unfortunately, it's still a bit immature to use commercially.
Hence, I chose React. It's idempotent, which is a fancy way of saying the markup it outputs is a strict function of the inputs it's given - no side effects, no externally-mutable state. This means you can live-edit your markup in your favorite editor without having to reload the browser on every save (using a tool called the Webpack Dev Server with the react-hot package). Using Webpack also means your dependencies are explicitly declared with `require` statements. It has all the benefits of Angular's Dependency Injector without all the boilerplate.
Finally, and perhaps most importantly, it has 0 dependency on the DOM. This means you can render your initial request on the server, and pass markup down to the client that's indistinguishable from what you'd traditionally get from Flask/Django/Rails/PHP. There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots, which is in turn safer for SEO. It also means your view is already rendered when it reaches the client, which is important in a world where many clients are phones with underpowered JS capabilities. You get both the benefits of a single-page-app (slow client rendering is still faster than slower network requests, and network requests are smaller if you don't have to also send down the template every time) and those of a server-side one (SEO is maintained, and the client can display your page without waiting to execute the JS first).
I should disclaim that I haven't seriously considered Ember since it's been rebranded from SproutCore; however, I have worked on a few Angular apps; and even forgoing the above benefits, React is just easier to work with.
- al_the_x 12y agoBeen meaning to look into React, so thanks for the review. Polymer is really not an option until Web Components are more broadly accepted by the browsers and better specified. One of the things I like about Angular JS is that it represents, IMO, a "baby-step" towards Web Components (which Polymer is built atop) through Directives.
- bsimpson 12y agoReact is also elemental, but in a different sort of way. Your elements effectively become substitutions: // When I say <IconButton link-to = "home" src = "home.svg /> // give me <a class = "IconButton" href = "/" > <img src = "home.svg" /> </a> It doesn't show up as custom elements in the DOM (hence you have to manually specify the class name in your substitution). It's also idempotent, so no fancy data binding. Otherwise, same idea.
- someone13 12y agoIf you don't mind sharing, have you done any research on data layers for React? From what I can see, there seems to be three major schools of thought: the Flux architecture, using Backbone's models, or just writing something custom.
- juriga 12y agoI'm currently using Fluxxor[1] which reifies the Flux architecture with Stores and a central dispatcher. I did some research into Backbone.Model bindings but eventually decided to go "full Flux". I've yet to regret my decision even though my app has grown quite complex. The best part is, thanks to React & Flux I'm building a large scale web app without jQuery for the first time in my life :) [1] http://fluxxor.com/ http://fluxxor.com/
- bsimpson 12y agoStill working on the data layer, but I think I'm going to use Reflux. One of the things I was initially skeptical of React about is its lack of support for custom event bubbling (which is the technique I like to use to keep my components decoupled). Flux lets you cheat around that: Since you're using require statements, you can make an action and `require()` it in both the component it's dispatched from and the one that's listening to it. // Traditional event bubbling child.dispatchEvent(...) ----> parent.addEventListener(...) // Reflux child:action() ----> store.listenTo(action) ----> store.trigger(data) ----> parent.listenTo(store) The store is an extra layer of abstraction, so you can assimilate data from different sources (user interaction, server events, etc) into one format before passing them into your datastream. Facebook's Flux has yet another layer of abstraction called the Dispatcher. Honestly, I'm murky on the utility of the Store and even less confident in the utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and I'm still tempted to skip the store and just listen to my actions from the parent component.
- basch 12y agoWhat are your thoughts on polymer vs famo.us. Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us? >This means you can render your initial request on the server, and pass markup down to the client That's how derby works too.
- phpnode 12y agofamo.us is shockingly bad IMHO. It breaks many common user interactions and goes through a load of hoops to enable "native performance" and then doesn't even get that right, I really don't understand the hype.
- prodigal_erik 12y ago>There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots Thanks for pointing this out, I'm always glad to see people taking responsibility for the quality of their contributions to the web and finding tools that enable good work.
- findjashua 12y agoThe thing that I don't like about web components is that it's a browser specific technology. With React, I can render the first page on the server, so the user doesn't have to wait 3 seconds for the initial page load. So I'm not a huge fan of anything that's browser specific and can't be rendered on the server. I see why Google is pushing for it - web components would mean crawlers not having to execute Javascript, which translates to significant savings on crawling infrastructure. But it'd make for a shitty user experience.