神刀安全网

Isomorphic JavaScript, let’s make it easier

Isomorphic Javascript, let’s make it easier.

isomorphici·so·mor·phic (ī’sə-môr’fĭk)
Having a similar structure or appearance but being of different ancestry.

Isomorphic JavaScript, let’s make it easier

Every since the invention of NodeJS people have loved the idea that you could “share” your JavaScript experience across the stack. This (in theory) has many benefits including less context switching between languages, easier transition between frontend and backend, and perhaps the most hopeful benefit was the ability to even share code.

Alright, I can already use my utilities in both places with the help of browserify or webpack … Surely I can do AJAX with a similar api to the browser? Check . And what about moving forms and files around? Check . What about if I need to be able to detect my environment; I’m not using meteor?! It’s covered . Even the DOM can now be made isomorphic with the help of the “Virtual DOM” implemented in libraries such as React , Deku and many others. You can even opt out of the virtual DOM altogether and get right back to writing the simple “static” html with tools such as morphdom , set-dom and diffHTML .

This example, although simple, will batch bend 100 emails at a time to a custom api and can work just fine in NodeJS or the browser.

This is starting to look pretty cool. I can now write an app that uses the same utilities, ajax and templates in both Node an the browser! Well, we’re not quite there. Theres too much missing! I need routing, redirecting, sessions, cookies and more to make an app! In Node I can organize my entire app into middleware, I can isolate features and I can test it easily! It’s a simple, top down, pluggable approach to building html. Why can’t we build DOM in the same way? React brings us close, but it’s still not enough.

Well, my friends, i’ve been working to make isomorphic JavaScript more enjoyable and easy to write. Less boiler plate and less context switches from client to server. Progressive enhancement, faster load times, SEO and best of all a simpler way to think about web apps. There is now a way to share 90% of you’re browser code with node. It’s a framework that has been in development for over a year thanks in part to my gracious employers at Tiller Digital and the countless others who are working on bridging the gap for isomorphic tooling. It’s name… is Rill .

Great. Another framework. What does it do?

Rill is an abstraction over the part of Node we all use most, the HTTP server. However it exposes the http api in an isomorphic way thanks to @rill/http . Routing, redirects, cookies, sessions, refreshes, error handling and even common headers for things like the “user-agent”, “referrer” and “locale”. You can finally access all of the data about a user from the same api, client or server, and it just so happens to be the same as Node.

Rill is a bit more than just this though, @rill/http is only one module. Rill (the main library) is more akin to Express or Koa and shares a fairly similar api. It enables middleware in an isomorphic environment and provides the final piece for any app. A way for data to flow. You can check out the documentation here .

Thats it, the index page is now fully capable of being rendered by the browser, or the node server. But thats not very impressive, what about navigation? What about “/away”?

Now you can navigate back and fourth and the browser will just handle it. Feel free to turn off JavaScript as your server is also perfectly capable! No awkward tiptoeing around your environment, no “server code” or “client code”, just render your views!

This is pretty cool, but if my page was just static content then this is overkill (although it has some benefits). What about my CRUD app? How can users enter in data? Well, the answer is simply another question “How would you do this without front-end JavaScript?”. Rill lets you pretend that your browser is a fully capable node server, it can even handle form submits! Lets add a form!

Awesome. We can program like we are in Node, and progressive enhancement comes easy. Need a search input that searches while you type? Simply use React to trigger the submit button “onClick”. It will just work, and be just as fast as doing it manually. With the added benefit that, if the JavaScript fails, your server knows exactly how to “react”!

This is just the tip of the iceberg. Modules for this style of development are still being worked on and the limit is yet to be reached. Personally I think tools like “ Node Canvas ”, and the “ Node File API ” could open up progressively enhanced image manipulation. For the current list of Rill compatible middleware just click here , or here .

And thats it. You get the expressiveness and simplicity you were once accustom to with your old “server only” solutions with the ability to off-load the bulk your logic to the front-end when available. It’s a lot to take in, and it’s certainly a different way of building front-end applications but it’s also familiar. Write your lovely Node code and have it work in both places. Fast initial render in the server, faster re-renders in the browser. The best of both worlds, the apex of JavaScript web development, the holy grail.

If you have questions about Rill, Isomorphic/Universal JavaScript, or how to build real applications this way please drop by the gitter page .

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Isomorphic JavaScript, let’s make it easier

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址