5 ms·

Isomorphic JavaScript is not the Answer

48 points by cyberpanther 12y ago

michaelchisari 12y ago
Although I love this idea for load times, it doesn't necessarily solve the issue of SEO. I don't think that's an impossible issue to solve, though.
- guntars 12y ago
  And it's still slower since the JS needs to be requested after the first chunk of html is parsed.
  - michaelchisari 12y ago
    For most use cases, the difference is going to be negligible, though. If everything is packed properly. Most use cases. Not all.
  - cyberpanther 12y ago
    Using standard minification techniques and making your JS asynchronous you can probably overcome a lot of that wait.
- cyberpanther 12y ago
  So officially Google says it can crawl these kinds of sites; however, from experience this is not the case. So until the future comes there is https://prerender.io/ https://prerender.io/.
  - hamburglar 12y ago
    As far as I'm concerned, until we can see what a JavaScript-enabled googlebot sees with our own eyes (and debug it), "Google can run JavaScript now" is just wishful thinking.
emmab 12y ago
> The separation of frontend and backend in web development makes a really clean separation that I would hate to combine again. This was the only complaint made about isomorphic JavaScript, and seems to be a straw man. We can still isolate frontend and backend code even if the frontend code is being run on a server. There is still a strong incentive to avoid mixing frontend and backend code so as to avoid exposing secret business logic to the client.
- cyberpanther 12y ago
  I think you could still have a lot of your business logic on the backend and probably be best this way. You just call your API to do backend jobs which return results. Your probably not going to do big task processing on the frontend unless that is where the data is stored.
- Untit1ed 12y ago
  Exactly - when I read that sentence I wasn't sure the author even knew what isomorphic javascript was. Pulling business logic into the front-end is admittedly a bad habit that isomorphic javascript encourages, but it's certainly not a core part of the concept. Generally you'll have a central API used by iOS, Android, Web etc - isomorphic javascript is a way to make your web app better, not an invitation to create a monolith.
- spamizbad 12y ago
  What I want to know is why will isomorphic JS work where other attempts at isomorph-isation have failed. Both the Java and .NET ecosystems have made attempts as this and yet their contemporary development practices for both are back to fully-segregated client and server code. Also I don't really understand the performance argument. Was that just a strawman on the part of the author?
platz 12y ago
This is called bootstrapping I believe. Before I heard it called that I just called it server globals or something to that effect
emidln 12y ago
The point isn't to dynamically render it on user request on the server. If you're rendering something that is primarily static and progressively enhancing it with user-specific input, you can render the vast majority of the html ahead of time and serve it statically. Your template can be initialized on push when the source content changes and then initialized again dynamically in the browser if content needs to be updated/customized. You're sharing templates along with context processing logic. This lets you perform SEO optimizations and dramatically decrease page load times while not suffering many drawbacks when it comes to your live frontend.
shittyanalogy 12y ago
"isn’t there a better way to speed up client side loads times without having to mix server side and client side code?" You're not mixing them, you're using a javascript engine serverside to pre-run your client side js. There is still code separation and your back end doesn't have to be written in JS to accomplish this. Separately the notion of "isomorphic javascript" if that's what it's called, is not to "mix" client and server code. It's 2 fold: 1 to take down the boundary between client and server code so that there is much re-use and code can just be "marked" as server or client only. 2) So that you can re-use many of your tools like libraries, testing, and language best practices across your whole project.
- cyberpanther 12y ago
  I think that boundary is important though. If you design your app correctly there won't be the need to rewrite code over the front and back. Also if your building an Android or iOS app you have to build that boundary. So why build the web frontend differently? They should all consume the same backend. Of course there will probably be repeat code but I'd rather minimize that than try to make universal code.
  - williamcotton 12y ago
    You're thinking of the wrong boundary. You should definitely have a boundary for your data that is agnostic of the view code. However, a web application is not like an iOS or Android application. It has a server-side that sends pre-rendered view code and it has a client-side that renders view code on the fly. It still makes sense to share the view code between the server and the client and it still allows for a separate data backend. These systems are surprisingly easy to create and maintain with React. In essence three things are supplied to a client. A pre-rendered view, raw data, and the code to turn the raw data in to the pre-rendered view.
    - cyberpanther 12y ago
      OK that is where we diverge, i'm thinking no pre-rendered view. Ideally your frontend would be serving statically from lets say Amazon S3 and your api from another domain. Treat your frontend as if it were a mobile app. Now if you apply the data bootstrapping technique this can't happen totally but the only thing to do dynamically is insert some initial API data.
laurencerowe 12y ago
Embedding the API data in the initial bootstrap HTML to avoid an extra round trip does help a little. Waiting for the Javascript to download, execute and render will easily dwarf that. Implementing server-side rendering with React brought the time to content being readable on our site down from ~3 seconds to ~0.5 seconds. It still takes a couple of seconds for the JS to kick in, but that happens in the background and the site visitor doesn't notice.
- cyberpanther 12y ago
  How much of that 3 seconds was rendering?
  - laurencerowe 12y ago
    From memory, from js downloaded to rendered html in DOM was about 1.5-2 seconds. Rendering when the JIT has warmed takes 25-250ms depending on the complexity of the page. First run maybe 10x that.
zachrose 12y ago
Is this is the same idea as "bootstrap data"? E.g. just a script tag that you fill with some JSON and render along with the page, and then your MVC JavaScript dancing monkey absorbs that data and renders before calling APIs?
iamleppert 12y ago
Isomorphic javascript doesn't mean that you HAVE to run all your code interchangeably. It's more about organization than a hard and fast rule. It means using the same package manager for frontend code as server side code (npm) -- tools like browserify and libraries that provide for design patterns that can be used with a DOM, or without one. It means treating javascript as javascript, not having separate repo's for frontend code and backend code. You still have to logically organize your application and make good choices about your code organization, as well as separation of concern. Interaction should always happen on the client. Also, the technique mentioned in the article about bootstrapping data into the initial page load is quite old and known about, and not a revelation. It does save one request round trip, which could potentially speed up your application by that one request (usually session data or user bootstrap data), but is not the silver bullet in solving all performance problems as the OP implies.
- cyberpanther 12y ago
  I think having a separate repo for the frontend and backend is important. It is the same separation I want for my Android and iOS code. If they were mixed with the backend it becomes messy. So the frontend is just another client like other platforms.
  - X-Cubed 12y ago
    The idea here is that the frontend as rendered on the client is the same as the frontend rendered on the server. This isn't about putting the API and service code in with the UI.
  - Romoku 12y ago
    I think isomorphic JavaScript applications are going to replace the current frontend paradigm. Microservices are becoming more popular, so imagine an isomorphic JavaScript application as a frontend consumer of many backend microservices. Plus there are a slew of security considerations that cannot be solved with current frontend JavaScript. For instance, how do I call a protected API without leaking the API credentials to the consumer? Currently you can do this with trusted hardware or the traditional server side rendering. An isomorphic JavaScript application can solve this problem using server side rendering without needing a separate backend.
carsongross 12y ago
I'm amazed at the lengths people will go to in order to avoid admitting that Single Page Apps are not always, or even usually, a good thing. Of the web apps I use regularly, the more SPA-ish they are, the less I enjoy using them.
- cyberpanther 12y ago
  Excellent, next SPA I make I know who I need to impress to make it acceptable.
- overgard 12y ago
  Yeah, unless you're literally making an app where the concept of pages does not make sense (ie -- a lot like a desktop application), I think single page apps are usually just not that necessary. And single page apps are WAY more complicated to write. There's so much more state management.
- CmonDev 12y ago
  That's because they are pretending that a document markup framework is a GUI framework. I mean DIVs, really? Also "isomorphic" practically means that developers have to use the horrible legacy language on server as well (at least on client there is no choice). It is some form of madness.
azmenak 12y ago
I've been using isomorphic rendering with ReactJS for some websites that are primarily static (static enough for me to build .html files using React as kind of template-language which get rendered on deploy) and I've found that it's been the best in terms of performance and SEO benefit. I'm enjoying being able to write my react render function once and everything just working.
ryanisinallofus 12y ago
How do you keep reading past THIS statement? "It was created to solve the problem of single page web apps running slowly."
- ryan-allen 12y ago
  I used my eyes and plain ol' comprehension.
- todd3834 12y ago
  I came here to say something similar. This was never the reason for my interest in isomorphic JavaScript.
knappador 12y ago
Shipping with the API calls pre-loaded helps unless you need to fetch additional view code. There's a lot more potential usually for multiple round trips than just API calls. Iso JS frameworks seek to solve the whole range of problems and provide structure for clean implementation. They're greatly aided by the portability of JS. Injecting local-fetched API results as JSON into the page solves one of many potential causes for multiple RTT on fat clients.
wwweston 12y ago
It probably depends on what you're doing. Are you serving something that's pretty much a straightforward hypermedia document with minimal interaction enhancements? Pushing markup generation down the line to the client probably doesn't make a ton of sense, particularly for mobile. In this case "isomorphic" JS isn't going to gain you a lot, given that you don't have to do much on the client, but it does let you do most of the work on the back end, which is nice if JS is your language of choice (and I like it enough I have no quarrel with you, though you could probably do as well with any other language on the back end and a bit of progressive enhancement). If you're serving an app that isn't really a hypermedia document anymore... well, first you should ask yourself if your app really needs to not be a hypermedia document (and if so, maybe consider some of the tradeoffs between web/native to boot). But assuming you've made those thoughtful considerations, then yeah, the idea to send an initial payload of API call results along with any non-cached essential app code makes a lot of sense. There's an odd in between place that some apps get to where what you're managing is still a hypermedia document but it's got a lot of independent subsections that may have their own specialized interactions (Hi, Facebook!). If this is your app... well, first you should probably be asking yourself if you might improve experience by moving from the "everything and the kitchen sink" model into a few more targeted document endpoints. But assuming you've done that, having the ability to selectively generate document fragments on the server or the client is probably helpful. And that seems like a good use case for an isomorphic JS approach.
megaman821 12y ago
How much response time improved in the typical case? If you serve your html, JavaScript, and CSS through a CDN, the user should get those lightning quick. A dynamic API response should be returned faster than a dynamic full page response. Then the client-side rendering will take place, but JavaScript is pretty fast now-a-days. Surely, this will be slower than a server rendered page, but how much slower than your typical RoR site?
- EugeneOZ 12y ago
  Actually sometimes it's noticeable slower. Solution for this can be entry point detached from SPA (when index.html is not part of SPA, renders on the server side and load SPA in background, while user enjoying first 2-3 seconds of reading index.html), or it can be just hidden (white page) body of document, while everything is not ready. Second variant is poor copy of usual sites loading, so detached index.html or cached data in template or even isomorphic option - they are better.
totemizer 12y ago
blogs telling us what's NOT the answer are NOT the answer
- steego 12y ago
  Comments telling us blogs telling us what's NOT the answer are NOT the answer are NOT the answer. (Sentence verified: http://nlp.stanford.edu:8080/parser/index.jsp http://nlp.stanford.edu:8080/parser/index.jsp)
rjurney 12y ago
This is how I've always done web development. If you care about performance, instead of having an AJAXy API load JSON, you just load the data all in the page's controller and stuff it into a template. Nothing about this seems new or novel in any way. I have no comment on isomorphic javascript, I haven't figure it out yet. But this doesn't seem relevant. Am I curmudgeon?
the_cat_kittles 12y ago
i love how the word is "isomorphic" instead of symmetrical or some less mathy word. it seems like a forced nomenclature.
xtrumanx 12y ago
This is not the solution I need. The biggest problem I face with single page applications is that I'm usually on a slow internet connection and I've gotten using a page while scripts are still being downloaded. This solution will still make the user wait while scripts are being downloaded (and then run). Not to mention the SEO implications. If isomorphic javascript isn't the answer, this isn't the answer either.
- EugeneOZ 12y ago
  Concatenate them into 1 file and problem solved (not the SEO one).
ffn 12y ago
It's kind of hard to say Isomorphic js isn't the answer when we're not even answering the same question. Granted server side JS probably might not be the best answer for slow client load times, but it certainly is a pretty decent answer for rendering the site for tin-foil users who surf the web with Javascript turned off (you find these guys when you write sites whose initial market base is found on 4chan/g/, IRC, tor, etc.). Also, with regard to the slow client load times, I've personally found an interactive now-loading page (which you can achieve without any js using :focus and css3 animation) works wonders with user experience (unless you're build an ultra-professional-suit-and-tie-no-fun-allowed-you-have-the-right-to-remain-silent website).
dasil003 12y ago
> It was created to solve the problem of single page web apps running slowly. Wait a second, is this premise in any way true? Admittedly I don't do isomorphic JS so maybe I'm out of touch, but in my mind the primary driver of the development of isomorphic JS is simply the pain of seeing repetition of code across the front and back ends. Obviously there is an appealing symmetry and reduction in toolchain complexity from isomorphic JS, and it's certainly an idea worth exploring, but I don't see it as holding any kind of dramatic promise. At the end of the day servers and clients are very different beasts that are not fundamentally served by attempting to make them look the same; there are probably a lot of incidental gains when focusing on small details of the code, but I don't see how it translates into a paradigm shift. Not that I dislike the idea, but is the article setting up a big strawman?
- cyberpanther 12y ago
  Straw Man Concept = build it up, knock it down, and create a solid final solution I'd be happy with that.
- nailer 12y ago
  Exactly. Everyone I know who's built isomorphic apps has mainly done it for: - SEO - having a static ver of a single page app for Google - Efficency, delivering a rendered view to browsers when they're not transitioning from another rendered view. I've never heard 'single page apps are slow' being the primary reason before. The load time of a JS binding is pretty low. Most people don't generally realise they're in a single page app until they move around the app atand in those cases the user perception is of speed.
  - cyberpanther 12y ago
    So officially Google says it can crawl these kinds of sites; however, from experience this is not the case. So until the future comes there is https://prerender.io/ https://prerender.io/.
bigethan 12y ago
I manage a large isomorphic app (m.trulia.com), and it's wonderful for our specific use case: Mobile website offering an app-like UI. All our node layer does is route requests, make API calls to our non-javascript business logic / data layer, and render the backbone app into HTML on the initial request. So there's a nice clean separation of UI and business logic, in different repos even. But as other posters have mentioned, it's only right for you if a single page app experience is right for you AND site performance (and SEO) is really important.
davydog187 12y ago
http://bloomberg.com http://bloomberg.com just launched a new site using the isomorphic javascript framework Brisket, and its pretty damn fast. https://github.com/bloomberg/brisket https://github.com/bloomberg/brisket
gonvaled 12y ago
I think the author is confused: isomorphic javascript's goal is not to run the same code on server and client - that is just a (minor) side effect, for some components. The main goal is to split the UI generation at a more clear boundary, going down to the server if necessary (http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new...)
jonathancreamer 12y ago
React + express rendering initially on the server and bootstrapping on the client is awesome.

48 points by cyberpanther 12y ago

Although I love this idea for load times, it doesn't necessarily solve the issue of SEO. I don't think that's an impossible issue to solve, though.

guntars 12y ago
And it's still slower since the JS needs to be requested after the first chunk of html is parsed.
- michaelchisari 12y ago
  For most use cases, the difference is going to be negligible, though. If everything is packed properly. Most use cases. Not all.
- cyberpanther 12y ago
  Using standard minification techniques and making your JS asynchronous you can probably overcome a lot of that wait.
cyberpanther 12y ago
So officially Google says it can crawl these kinds of sites; however, from experience this is not the case. So until the future comes there is https://prerender.io/ https://prerender.io/.
- hamburglar 12y ago
  As far as I'm concerned, until we can see what a JavaScript-enabled googlebot sees with our own eyes (and debug it), "Google can run JavaScript now" is just wishful thinking.

emmab 12y ago

> The separation of frontend and backend in web development makes a really clean separation that I would hate to combine again. This was the only complaint made about isomorphic JavaScript, and seems to be a straw man. We can still isolate frontend and backend code even if the frontend code is being run on a server. There is still a strong incentive to avoid mixing frontend and backend code so as to avoid exposing secret business logic to the client.

cyberpanther 12y ago
I think you could still have a lot of your business logic on the backend and probably be best this way. You just call your API to do backend jobs which return results. Your probably not going to do big task processing on the frontend unless that is where the data is stored.
Untit1ed 12y ago
Exactly - when I read that sentence I wasn't sure the author even knew what isomorphic javascript was. Pulling business logic into the front-end is admittedly a bad habit that isomorphic javascript encourages, but it's certainly not a core part of the concept. Generally you'll have a central API used by iOS, Android, Web etc - isomorphic javascript is a way to make your web app better, not an invitation to create a monolith.
spamizbad 12y ago
What I want to know is why will isomorphic JS work where other attempts at isomorph-isation have failed. Both the Java and .NET ecosystems have made attempts as this and yet their contemporary development practices for both are back to fully-segregated client and server code. Also I don't really understand the performance argument. Was that just a strawman on the part of the author?

platz 12y ago

This is called bootstrapping I believe. Before I heard it called that I just called it server globals or something to that effect

emidln 12y ago

The point isn't to dynamically render it on user request on the server. If you're rendering something that is primarily static and progressively enhancing it with user-specific input, you can render the vast majority of the html ahead of time and serve it statically. Your template can be initialized on push when the source content changes and then initialized again dynamically in the browser if content needs to be updated/customized. You're sharing templates along with context processing logic. This lets you perform SEO optimizations and dramatically decrease page load times while not suffering many drawbacks when it comes to your live frontend.

shittyanalogy 12y ago

"isn’t there a better way to speed up client side loads times without having to mix server side and client side code?" You're not mixing them, you're using a javascript engine serverside to pre-run your client side js. There is still code separation and your back end doesn't have to be written in JS to accomplish this. Separately the notion of "isomorphic javascript" if that's what it's called, is not to "mix" client and server code. It's 2 fold: 1 to take down the boundary between client and server code so that there is much re-use and code can just be "marked" as server or client only. 2) So that you can re-use many of your tools like libraries, testing, and language best practices across your whole project.

cyberpanther 12y ago
I think that boundary is important though. If you design your app correctly there won't be the need to rewrite code over the front and back. Also if your building an Android or iOS app you have to build that boundary. So why build the web frontend differently? They should all consume the same backend. Of course there will probably be repeat code but I'd rather minimize that than try to make universal code.
- williamcotton 12y ago
  You're thinking of the wrong boundary. You should definitely have a boundary for your data that is agnostic of the view code. However, a web application is not like an iOS or Android application. It has a server-side that sends pre-rendered view code and it has a client-side that renders view code on the fly. It still makes sense to share the view code between the server and the client and it still allows for a separate data backend. These systems are surprisingly easy to create and maintain with React. In essence three things are supplied to a client. A pre-rendered view, raw data, and the code to turn the raw data in to the pre-rendered view.
  - cyberpanther 12y ago
    OK that is where we diverge, i'm thinking no pre-rendered view. Ideally your frontend would be serving statically from lets say Amazon S3 and your api from another domain. Treat your frontend as if it were a mobile app. Now if you apply the data bootstrapping technique this can't happen totally but the only thing to do dynamically is insert some initial API data.

laurencerowe 12y ago

Embedding the API data in the initial bootstrap HTML to avoid an extra round trip does help a little. Waiting for the Javascript to download, execute and render will easily dwarf that. Implementing server-side rendering with React brought the time to content being readable on our site down from ~3 seconds to ~0.5 seconds. It still takes a couple of seconds for the JS to kick in, but that happens in the background and the site visitor doesn't notice.

cyberpanther 12y ago
How much of that 3 seconds was rendering?
- laurencerowe 12y ago
  From memory, from js downloaded to rendered html in DOM was about 1.5-2 seconds. Rendering when the JIT has warmed takes 25-250ms depending on the complexity of the page. First run maybe 10x that.

zachrose 12y ago

Is this is the same idea as "bootstrap data"? E.g. just a script tag that you fill with some JSON and render along with the page, and then your MVC JavaScript dancing monkey absorbs that data and renders before calling APIs?

iamleppert 12y ago

Isomorphic javascript doesn't mean that you HAVE to run all your code interchangeably. It's more about organization than a hard and fast rule. It means using the same package manager for frontend code as server side code (npm) -- tools like browserify and libraries that provide for design patterns that can be used with a DOM, or without one. It means treating javascript as javascript, not having separate repo's for frontend code and backend code. You still have to logically organize your application and make good choices about your code organization, as well as separation of concern. Interaction should always happen on the client. Also, the technique mentioned in the article about bootstrapping data into the initial page load is quite old and known about, and not a revelation. It does save one request round trip, which could potentially speed up your application by that one request (usually session data or user bootstrap data), but is not the silver bullet in solving all performance problems as the OP implies.

cyberpanther 12y ago
I think having a separate repo for the frontend and backend is important. It is the same separation I want for my Android and iOS code. If they were mixed with the backend it becomes messy. So the frontend is just another client like other platforms.
- X-Cubed 12y ago
  The idea here is that the frontend as rendered on the client is the same as the frontend rendered on the server. This isn't about putting the API and service code in with the UI.
- Romoku 12y ago
  I think isomorphic JavaScript applications are going to replace the current frontend paradigm. Microservices are becoming more popular, so imagine an isomorphic JavaScript application as a frontend consumer of many backend microservices. Plus there are a slew of security considerations that cannot be solved with current frontend JavaScript. For instance, how do I call a protected API without leaking the API credentials to the consumer? Currently you can do this with trusted hardware or the traditional server side rendering. An isomorphic JavaScript application can solve this problem using server side rendering without needing a separate backend.

carsongross 12y ago

I'm amazed at the lengths people will go to in order to avoid admitting that Single Page Apps are not always, or even usually, a good thing. Of the web apps I use regularly, the more SPA-ish they are, the less I enjoy using them.

cyberpanther 12y ago
Excellent, next SPA I make I know who I need to impress to make it acceptable.
overgard 12y ago
Yeah, unless you're literally making an app where the concept of pages does not make sense (ie -- a lot like a desktop application), I think single page apps are usually just not that necessary. And single page apps are WAY more complicated to write. There's so much more state management.
CmonDev 12y ago
That's because they are pretending that a document markup framework is a GUI framework. I mean DIVs, really? Also "isomorphic" practically means that developers have to use the horrible legacy language on server as well (at least on client there is no choice). It is some form of madness.

azmenak 12y ago

I've been using isomorphic rendering with ReactJS for some websites that are primarily static (static enough for me to build .html files using React as kind of template-language which get rendered on deploy) and I've found that it's been the best in terms of performance and SEO benefit. I'm enjoying being able to write my react render function once and everything just working.

ryanisinallofus 12y ago

How do you keep reading past THIS statement? "It was created to solve the problem of single page web apps running slowly."

ryan-allen 12y ago
I used my eyes and plain ol' comprehension.
todd3834 12y ago
I came here to say something similar. This was never the reason for my interest in isomorphic JavaScript.

knappador 12y ago

Shipping with the API calls pre-loaded helps unless you need to fetch additional view code. There's a lot more potential usually for multiple round trips than just API calls. Iso JS frameworks seek to solve the whole range of problems and provide structure for clean implementation. They're greatly aided by the portability of JS. Injecting local-fetched API results as JSON into the page solves one of many potential causes for multiple RTT on fat clients.

wwweston 12y ago

It probably depends on what you're doing. Are you serving something that's pretty much a straightforward hypermedia document with minimal interaction enhancements? Pushing markup generation down the line to the client probably doesn't make a ton of sense, particularly for mobile. In this case "isomorphic" JS isn't going to gain you a lot, given that you don't have to do much on the client, but it does let you do most of the work on the back end, which is nice if JS is your language of choice (and I like it enough I have no quarrel with you, though you could probably do as well with any other language on the back end and a bit of progressive enhancement). If you're serving an app that isn't really a hypermedia document anymore... well, first you should ask yourself if your app really needs to not be a hypermedia document (and if so, maybe consider some of the tradeoffs between web/native to boot). But assuming you've made those thoughtful considerations, then yeah, the idea to send an initial payload of API call results along with any non-cached essential app code makes a lot of sense. There's an odd in between place that some apps get to where what you're managing is still a hypermedia document but it's got a lot of independent subsections that may have their own specialized interactions (Hi, Facebook!). If this is your app... well, first you should probably be asking yourself if you might improve experience by moving from the "everything and the kitchen sink" model into a few more targeted document endpoints. But assuming you've done that, having the ability to selectively generate document fragments on the server or the client is probably helpful. And that seems like a good use case for an isomorphic JS approach.

megaman821 12y ago

How much response time improved in the typical case? If you serve your html, JavaScript, and CSS through a CDN, the user should get those lightning quick. A dynamic API response should be returned faster than a dynamic full page response. Then the client-side rendering will take place, but JavaScript is pretty fast now-a-days. Surely, this will be slower than a server rendered page, but how much slower than your typical RoR site?

EugeneOZ 12y ago
Actually sometimes it's noticeable slower. Solution for this can be entry point detached from SPA (when index.html is not part of SPA, renders on the server side and load SPA in background, while user enjoying first 2-3 seconds of reading index.html), or it can be just hidden (white page) body of document, while everything is not ready. Second variant is poor copy of usual sites loading, so detached index.html or cached data in template or even isomorphic option - they are better.

totemizer 12y ago

blogs telling us what's NOT the answer are NOT the answer

steego 12y ago
Comments telling us blogs telling us what's NOT the answer are NOT the answer are NOT the answer. (Sentence verified: http://nlp.stanford.edu:8080/parser/index.jsp http://nlp.stanford.edu:8080/parser/index.jsp)

rjurney 12y ago

This is how I've always done web development. If you care about performance, instead of having an AJAXy API load JSON, you just load the data all in the page's controller and stuff it into a template. Nothing about this seems new or novel in any way. I have no comment on isomorphic javascript, I haven't figure it out yet. But this doesn't seem relevant. Am I curmudgeon?

the_cat_kittles 12y ago

i love how the word is "isomorphic" instead of symmetrical or some less mathy word. it seems like a forced nomenclature.

xtrumanx 12y ago

This is not the solution I need. The biggest problem I face with single page applications is that I'm usually on a slow internet connection and I've gotten using a page while scripts are still being downloaded. This solution will still make the user wait while scripts are being downloaded (and then run). Not to mention the SEO implications. If isomorphic javascript isn't the answer, this isn't the answer either.

EugeneOZ 12y ago
Concatenate them into 1 file and problem solved (not the SEO one).

ffn 12y ago

It's kind of hard to say Isomorphic js isn't the answer when we're not even answering the same question. Granted server side JS probably might not be the best answer for slow client load times, but it certainly is a pretty decent answer for rendering the site for tin-foil users who surf the web with Javascript turned off (you find these guys when you write sites whose initial market base is found on 4chan/g/, IRC, tor, etc.). Also, with regard to the slow client load times, I've personally found an interactive now-loading page (which you can achieve without any js using :focus and css3 animation) works wonders with user experience (unless you're build an ultra-professional-suit-and-tie-no-fun-allowed-you-have-the-right-to-remain-silent website).

dasil003 12y ago

> It was created to solve the problem of single page web apps running slowly. Wait a second, is this premise in any way true? Admittedly I don't do isomorphic JS so maybe I'm out of touch, but in my mind the primary driver of the development of isomorphic JS is simply the pain of seeing repetition of code across the front and back ends. Obviously there is an appealing symmetry and reduction in toolchain complexity from isomorphic JS, and it's certainly an idea worth exploring, but I don't see it as holding any kind of dramatic promise. At the end of the day servers and clients are very different beasts that are not fundamentally served by attempting to make them look the same; there are probably a lot of incidental gains when focusing on small details of the code, but I don't see how it translates into a paradigm shift. Not that I dislike the idea, but is the article setting up a big strawman?

cyberpanther 12y ago
Straw Man Concept = build it up, knock it down, and create a solid final solution I'd be happy with that.
nailer 12y ago
Exactly. Everyone I know who's built isomorphic apps has mainly done it for: - SEO - having a static ver of a single page app for Google - Efficency, delivering a rendered view to browsers when they're not transitioning from another rendered view. I've never heard 'single page apps are slow' being the primary reason before. The load time of a JS binding is pretty low. Most people don't generally realise they're in a single page app until they move around the app atand in those cases the user perception is of speed.
- cyberpanther 12y ago
  So officially Google says it can crawl these kinds of sites; however, from experience this is not the case. So until the future comes there is https://prerender.io/ https://prerender.io/.

bigethan 12y ago

I manage a large isomorphic app (m.trulia.com), and it's wonderful for our specific use case: Mobile website offering an app-like UI. All our node layer does is route requests, make API calls to our non-javascript business logic / data layer, and render the backbone app into HTML on the initial request. So there's a nice clean separation of UI and business logic, in different repos even. But as other posters have mentioned, it's only right for you if a single page app experience is right for you AND site performance (and SEO) is really important.

davydog187 12y ago

http://bloomberg.com http://bloomberg.com just launched a new site using the isomorphic javascript framework Brisket, and its pretty damn fast. https://github.com/bloomberg/brisket https://github.com/bloomberg/brisket

gonvaled 12y ago

I think the author is confused: isomorphic javascript's goal is not to run the same code on server and client - that is just a (minor) side effect, for some components. The main goal is to split the UI generation at a more clear boundary, going down to the server if necessary (http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new...)

jonathancreamer 12y ago

React + express rendering initially on the server and bootstrapping on the client is awesome.