7 ms·

Speaking from personal experience, I'm reluctantly moving from my favorite stack (C# MVC) to Node.js in order to be able to build an isomorphic SPA in the most

by Todd 12y ago

Speaking from personal experience, I'm reluctantly moving from my favorite stack (C# MVC) to Node.js in order to be able to build an isomorphic SPA in the most straightforward way. Node is the stack of choice for JS and the obvious choice if you want to render on the client and the server using as much shared code as possible. That said, you're still free to develop your API using your favorite technologies. To be honest, this is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level.

remon 12y ago
Fair point. I suppose the debate should be about API and "lower" tiers mostly.
xtrumanx 12y ago
As a C# developer, I too am building isomorphic apps currently in NodeJS (with ReactJS). Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts? [0] http://reactjs.net/ http://reactjs.net/
- Todd 12y ago
  I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router. Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared. The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery). The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router. I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.
  - xtrumanx 12y ago
    I haven't really given the routing issue too much thought regarding ReactJS.NET. I assumed it would work just as well as my isomorphic apps in NodeJS; one route in server-side land that handles all URLs and returns a View that contains the server-side rendered React app. I maybe missing something for why that wouldn't work in ASP.NET land but like I said, I haven't worked with it that much. react-router is all right and they've got server-side rendering working but it's still missing one very important facet that is required for most isomorphic apps; the initial server-side render should be capable of fetching whatever data is needed is fully render the page. Right now the best you could do is deliver a page with a spinner if the page requires some data on the initial render. Andrey Popp's react-router-component solved this issue by using react-async which uses fibers to allows for getInitialState to work asynchronously. The react-router guys think the "fibers stuff is stupid"[0] but they're still working on their own solution to the problem. The only reason I'm still keeping tabs on react-router instead of abandoning it for react-router-component is that it doesn't look like Andrey Popp's is going to be maintaining react-router-component and react-router seems like the only other game in town when it comes to routing in React. [0] https://github.com/rackt/react-router/issues/57#issuecomment-49193293 https://github.com/rackt/react-router/issues/57#issuecomment... P.S. I don't know that much about node and fibers to understand why fibers is stupid but it solves the problem and from what I read about fibers, it seems like the node community just don't like it because it resembles threads and they don't like threads in node.
    - Todd 12y ago
      It looks like they may have recently solved the issue with async rendering on the server (4 days ago): https://github.com/rackt/react-router/wiki/Announcements#whats-the-deal-with-the-new-api https://github.com/rackt/react-router/wiki/Announcements#wha... One of the exciting things about React, and Node.js more generally, is how quickly it is moving. This usually means that there are sharp edges and rough patches and that's been my experience so far. I'll take that any day over a backwater that gets no attention. I am going to spend some time with react-router, since it looks like the one that is gaining the most traction. To my comment above, they do support nested views, which appears to solve the layout issue for me.
- hokkos 12y ago
  I feel that if you go the whole react and SPA route you should use the tool mostly used with that : grunt/gulp, npm/bower, browserify/webpack. Even MS is going this route the VS 2015 projects will use grunt/npm/bower in the starting template, don't expect to have updated Nugget package for all those JS lib you will use for so long. And the is no Nugget packages for most lib you will have to use with React. The only thing that make it interesting is for the initial render but I don't know if it is easy to set up.
eric_bullington 12y ago
>...your API...is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level. I've had the opposite experience with the SPA projects I've worked on, one of them pretty large. With the possible exception of authorization/authentication, the API for all my projects has been pretty straightforward, whereas the client-side app has been where I've missed stronger typing and rich data types most acutely, to the point where I've been actively evaluating compile-to-js alternatives with a better/safer type system. However, with the advent of Facebook's Flow, I might just stick with JS.
- empthought 12y ago
  Seems like the classic tension between SPA and ROCA.[1] [1]: http://roca-style.org http://roca-style.org
- Todd 12y ago
  I guess what I meant was that there can be significant data manipulation at the API level, and this calls for more language and runtime support. Agreed that client code can become very complex. It's one of the reasons I avoided doing too much on the client in the past. My solution to this has been to use TypeScript, which is fantastic for solving this sort of problem. Yes, it moves away from prototypal inheritance. It also doesn't play nice with JSX. It's still hugely worth it for me. I haven't tried Flow but it looks like it addresses the same problems.
romaniv 12y ago
You're moving to an entirely different stack simply to make a web app searchable? After you chose to use an architecture (I mean SPA paradigm) that doesn't work with search engines very well? I just don't get it. No, really. I know that's what many people do, but I still don't get it. It is possible to build extremely dynamic websites that are not SPAs. It is possible to do it in a relatively straightforward fashion. (Using something similar to web components.) So why move?
- csallen 12y ago
  Probably because he really wants to build an SPA and believes that it provides the best experience for his users. Which might be true.
  - romaniv 12y ago
    The notion that SPA automatically gives you better user experience is a fallacy. Better UI design gives you better user experience, and good UI design is possible using the classic approach to web development. As an added bonus, you get searchability for free and you don't have to move away from your existing server-side stack.
    - csallen 12y ago
      Single page applications allow for more flexible UI design, and that flexibility allows for lots of potential improvements. Forcibly re-drawing the canvas during transitions is quite limiting, and I don't know any visual or interaction designers who couldn't do a better job without that artificial constraint. Now, whether the benefits of getting rid of that constraint are worth the costs depends entirely on what you're building.
      - romaniv 12y ago
        You do not have to re-draw the canvas during transitions. Believe it or not, it is possible to do AJAX declaratively and with progressive enhancement. My approach is to develop forms normally, then add a directive that intercepts them via AJAX, "cuts" certain pieces of the target page and "pastes" it into the current page. It is a very simple, generic and flexible approach. The markup looks like this: <form action="/something" submit-to="#x, #y"></form> <div id="x" /> <div id="y" /> Normally, the only thing I need to add to go from non-AJAX to AJAX is submit-to="[CSS Selector Here]". Possibly, some IDs. Everything else works automatically. The library adds a certain attribute to the "pasted" parts, so I can add visual transitions via CSS3. I can use form's action URL to rewrite current URL via push state.
syntern 12y ago
If you are a C# developer, you'd probably find a Dart-based stack much better.

by Todd 12y ago

remon 12y ago

Fair point. I suppose the debate should be about API and "lower" tiers mostly.

xtrumanx 12y ago

As a C# developer, I too am building isomorphic apps currently in NodeJS (with ReactJS). Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts? [0] http://reactjs.net/ http://reactjs.net/

Todd 12y ago
I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router. Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared. The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery). The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router. I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.
- xtrumanx 12y ago
  I haven't really given the routing issue too much thought regarding ReactJS.NET. I assumed it would work just as well as my isomorphic apps in NodeJS; one route in server-side land that handles all URLs and returns a View that contains the server-side rendered React app. I maybe missing something for why that wouldn't work in ASP.NET land but like I said, I haven't worked with it that much. react-router is all right and they've got server-side rendering working but it's still missing one very important facet that is required for most isomorphic apps; the initial server-side render should be capable of fetching whatever data is needed is fully render the page. Right now the best you could do is deliver a page with a spinner if the page requires some data on the initial render. Andrey Popp's react-router-component solved this issue by using react-async which uses fibers to allows for getInitialState to work asynchronously. The react-router guys think the "fibers stuff is stupid"[0] but they're still working on their own solution to the problem. The only reason I'm still keeping tabs on react-router instead of abandoning it for react-router-component is that it doesn't look like Andrey Popp's is going to be maintaining react-router-component and react-router seems like the only other game in town when it comes to routing in React. [0] https://github.com/rackt/react-router/issues/57#issuecomment-49193293 https://github.com/rackt/react-router/issues/57#issuecomment... P.S. I don't know that much about node and fibers to understand why fibers is stupid but it solves the problem and from what I read about fibers, it seems like the node community just don't like it because it resembles threads and they don't like threads in node.
  - Todd 12y ago
    It looks like they may have recently solved the issue with async rendering on the server (4 days ago): https://github.com/rackt/react-router/wiki/Announcements#whats-the-deal-with-the-new-api https://github.com/rackt/react-router/wiki/Announcements#wha... One of the exciting things about React, and Node.js more generally, is how quickly it is moving. This usually means that there are sharp edges and rough patches and that's been my experience so far. I'll take that any day over a backwater that gets no attention. I am going to spend some time with react-router, since it looks like the one that is gaining the most traction. To my comment above, they do support nested views, which appears to solve the layout issue for me.
hokkos 12y ago
I feel that if you go the whole react and SPA route you should use the tool mostly used with that : grunt/gulp, npm/bower, browserify/webpack. Even MS is going this route the VS 2015 projects will use grunt/npm/bower in the starting template, don't expect to have updated Nugget package for all those JS lib you will use for so long. And the is no Nugget packages for most lib you will have to use with React. The only thing that make it interesting is for the initial render but I don't know if it is easy to set up.

eric_bullington 12y ago

>...your API...is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level. I've had the opposite experience with the SPA projects I've worked on, one of them pretty large. With the possible exception of authorization/authentication, the API for all my projects has been pretty straightforward, whereas the client-side app has been where I've missed stronger typing and rich data types most acutely, to the point where I've been actively evaluating compile-to-js alternatives with a better/safer type system. However, with the advent of Facebook's Flow, I might just stick with JS.

empthought 12y ago
Seems like the classic tension between SPA and ROCA.[1] [1]: http://roca-style.org http://roca-style.org
Todd 12y ago
I guess what I meant was that there can be significant data manipulation at the API level, and this calls for more language and runtime support. Agreed that client code can become very complex. It's one of the reasons I avoided doing too much on the client in the past. My solution to this has been to use TypeScript, which is fantastic for solving this sort of problem. Yes, it moves away from prototypal inheritance. It also doesn't play nice with JSX. It's still hugely worth it for me. I haven't tried Flow but it looks like it addresses the same problems.

romaniv 12y ago

You're moving to an entirely different stack simply to make a web app searchable? After you chose to use an architecture (I mean SPA paradigm) that doesn't work with search engines very well? I just don't get it. No, really. I know that's what many people do, but I still don't get it. It is possible to build extremely dynamic websites that are not SPAs. It is possible to do it in a relatively straightforward fashion. (Using something similar to web components.) So why move?

csallen 12y ago
Probably because he really wants to build an SPA and believes that it provides the best experience for his users. Which might be true.
- romaniv 12y ago
  The notion that SPA automatically gives you better user experience is a fallacy. Better UI design gives you better user experience, and good UI design is possible using the classic approach to web development. As an added bonus, you get searchability for free and you don't have to move away from your existing server-side stack.
  - csallen 12y ago
    Single page applications allow for more flexible UI design, and that flexibility allows for lots of potential improvements. Forcibly re-drawing the canvas during transitions is quite limiting, and I don't know any visual or interaction designers who couldn't do a better job without that artificial constraint. Now, whether the benefits of getting rid of that constraint are worth the costs depends entirely on what you're building.
    - romaniv 12y ago
      You do not have to re-draw the canvas during transitions. Believe it or not, it is possible to do AJAX declaratively and with progressive enhancement. My approach is to develop forms normally, then add a directive that intercepts them via AJAX, "cuts" certain pieces of the target page and "pastes" it into the current page. It is a very simple, generic and flexible approach. The markup looks like this: <form action="/something" submit-to="#x, #y"></form> <div id="x" /> <div id="y" /> Normally, the only thing I need to add to go from non-AJAX to AJAX is submit-to="[CSS Selector Here]". Possibly, some IDs. Everything else works automatically. The library adds a certain attribute to the "pasted" parts, so I can add visual transitions via CSS3. I can use form's action URL to rewrite current URL via push state.

syntern 12y ago

If you are a C# developer, you'd probably find a Dart-based stack much better.