this is interesting so Javascript can now be used for server-side which removes the need for Ruby on Rails and Django basically? can someone summaries this article, time is of the essence.
Isomorphic JavaScript: The Future of Web Apps
21–30 of 123 posts
Re: Isomorphic JavaScript: The Future of Web Apps
#22one man's isomorphic javascript is another man's text file...
Re: Isomorphic JavaScript: The Future of Web Apps
#23You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
Whoa old man quarterto, who said the word ever belonged to math people in the first place? I could argue that math people have a bad habit of squeezing English words into strange contexts that corrupt the original meaning. Take "manifold" for instance, or "curl", or even something as harmless as "mode". They all meant perfectly fine things until the math people claimed them as their own. According to M-W "isomorphic"…
He has a point. The system they are describing in the article isn't even isomorphic. If it WAS, it wouldn't depend on node.
To clarify, if it was a true example of isomorphism it wouldn't be contingent on a single runtime environment or language.
A better example of isomorphism in computing would be two modules of code that perform the same function and have the same abstract interface but that are written in DIFFERENT languages.
Re: Isomorphic JavaScript: The Future of Web Apps
#24You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!
I just assumed it meant the opposite of polymorphic, but no it's not even related to that..
That's "monomorphic". Really!
Re: Isomorphic JavaScript: The Future of Web Apps
#25For those interested in GWT, I've got a similar library I'm working on for GWT, but I call it "PoA" for Page-Oriented-Architecture. The idea is to have the best of both worlds from both an SPA (Single-Page-Application) standard point, while preserving the fundamental webby-ness of URLs/pages. Of course, since it is Java, a lot of code is shared between server and client, running full performance in the JVM, plus globally optimized JS on the client.
It works by authoring all pages in HTML/CSS/WebComponents with basic MDV-style two-way databinding as separate stand-alone pages. These are then globally optimized together as a monolithic SPA application, and then code-split back into separate pieces. A servlet then processes the template on the server, does the data binding, and sends back a fully rendered bit of HTML + inlined JSON data within a single HTTP request. The JS code starts up and binds to the template and model, and then launches async loads of the rest of the compiled templates.
You get URL addressability, crawlability, fast initial page load, plus SPA-style fast switches, global aggressive optimization, offline, sharing of heap objects between pages, etc.
Initial hacked up draft of what I'm prototyping http://goo.gl/ZNpxTk
Re: Isomorphic JavaScript: The Future of Web Apps
#26this is interesting so Javascript can now be used for server-side which removes the need for Ruby on Rails and Django basically? can someone summaries this article, time is of the essence.
This isn't anything new...
Re: Isomorphic JavaScript: The Future of Web Apps
#27I'm curious to see how this shared rendering between client/server plays out for non JS based frameworks such as Django, Rails, etc.
I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.
Re: Isomorphic JavaScript: The Future of Web Apps
#28I'm curious to see how this shared rendering between client/server plays out for non JS based frameworks such as Django, Rails, etc. I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.
(OP here) Probably your best bet is to create a small Node web service that takes a template name and data and returns HTML. Then your (Rails, Python, PHP) app can call out to that in the request cycle.
Instagram.com does something similar; it's a Django app.
Re: Isomorphic JavaScript: The Future of Web Apps
#29We do this sort of thing on the site I work on, Google+. Initial page-loads are rendered on the server, subsequent page-loads are rendered on the client. Really good for performance. It's just the templating system that's common code, though, the server is still Java.
(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?
Re: Isomorphic JavaScript: The Future of Web Apps
#30A great thing about the web is that a multitude of server side languages can be used. While I don't ever want to have to write the same template twice, having everything converge on nothing but Javascript doesn't seem like a very inspiring future to me.
If you are building a service or API, then you can do that in whatever language you like. The natural language for writing client side apps is JS (ok, the only language, for now).
Correct. If you're already writing a bunch of JavaScript for the client-side, then just think about this approach as migrating some of that client, UI logic to the server.