What an odd trend. First Netflix moves part of their infrastructure to Node (https://news.ycombinator.com/item?id=8631022) and now Yahoo is doing something similar. Node.js is great but I don't think huge enterprise systems for some of the largest brands in the world are necessarily the best fit. I wish they'd provide some insights on why they're making that particular move.
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.
>...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.
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.
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?
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.
Hey, I'm the developer of ReactJS.NET. Thanks for trying it out!
> Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers.
A while back I worked on a library called [RouteJs](http://dan.cx/projects/routejs) that would expose certain ASP.NET MVC routes to JavaScript. The use case here was to have a way to build URLs client-side rather than hard-coding them (similar to the `Url.Action` helper in Razor) but a similar technique could be used to do client-side routing. That's actually a really good feature request for RouteJs :)
> 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.
Yeah, that's true. I have one page using server-side rendering in production, and it's a page on my site/blog: http://dan.cx/socialfeed.htm. It's also a simple page but I used it for building the original proof-of-concept for server-side rendering. I haven't actually tried using ReactJS.NET to build a single-page app, but I think that would be an interesting use case.
Hi Dan, I think ReactJS.Net is a great project. I've got to say, it was very reassuring to see that it was there when I began exploring React. This is definitely the approach that I will use when not building an SPA. The criticism about routers was not directed at this project. It was a more general criticism of some of the JS routers that I've seen, which are sometimes light on documentation. Cheers!
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.
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.
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.
Yes, that was strange. I noticed it was removed shortly after I posted my comment. I can only assume they want to clean up the examples in the announcement and integrate them into the docs. Here's where I saw the original link:
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.
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?
Highly debatable. I've had great success developing highly dynamic websites using progressive enhancement and directive/web component like approach.
People often smirk when I mention progressive enhancement these days. But the same people often claim that something is "impossible" to do using PE, while it's not only possible, but downwright easy. This makes me think most of them never even tried this approach seriously.
My overall strategy is creating some crude "date model" of the application in pure HTML, then identifying additional behaviors I need to make it look/work the way I really want to. I implement each behavior as separate JS libraries. The libraries are configured by adding additional directives to my markup, so using and re-using them requires no coding per se.
You would be surprised how much you can accomplish this way. Moreover, it forces you to write highly reusable components that are easy to reuse.
CSS3 is a great help in this regard, because (in most cases) you do not have to specify look-and-feel of anything in the library itself. You can simply generate some additional markup that can be styled separately for every app.
This is so true. The greatest gift of the transactional model of HTTP applications, where you submit your action, to receive a page for your next step, was freeing application development out of the bind it was in: heavy client state with a myriad of small transactions triggered by events.
To put it another way, when you design transactional first, you actually design a very good approach to your business layer public interface. If you do that step right, you can do the next two with minimal effort:
1. An application API;
2. Client side javascript for improving the UI of common operations.
Single page applications often smell like the Windows Forms applications of old: A convoluted spaghetti of application states linked by insignificant events and event handlers, where the boundary between business logic and user interface is fuzzy or non-existent.
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.
I used to think the same way, but trying out a non-SPA site really feels jarring now. The intermittent blank screen and the 2 second wait period makes for a shit user experience. I'm much more used to the fluid desktop-grade UI.
My only gripe with SPA was the initial load-time (looking at you Gmail), but with virtual-dom, being able to generate the html on the server gives you the best of both worlds.
You don't have to go SPA to avoid the page reload. AJAX works just fine with regular webpages as well, judiciously applied on the most latency-sensitive actions.
BTW, you're posting this on Hacker News, which is the ultimate in retro Web-1.0 technology. Heck, it even uses tables for layout.
SPAs use Ajax to sync data with the server, but the templates/assets are on the client already. In a regular webpage, Ajax would have to pull the templates for the new components as well.
I think this is what Gmail does, though it still takes forever for the initial load. Anyway, I can see this becoming a complicated mess very quickly, and find Ractive/React to be much simpler solutions.
As for HN, I doubt anyone comes to HN for the design. PG and YC's brand helped create a solid community with good content and good discussions, which is what keeps bringing us back. But let's call a spade a spade - the UI design here is a joke, even more so considering that its target demographic is the tech community.
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.
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:
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.
Yep, node.js is the new PHP. Not by how it works, but by "shit everyone uses". Now, I won't try to convince anyone that it's crap (while I do believe it is), but it's the modern crap technology. Welcome to 1998, we are all "modern".
My point though, is I'm not referring to "bleeding edge startups." I'm talking about almost every major publisher here Conde Nast, Hearst, Wenner Media, Gawker, the list goes on and on. These are massive old and new media publishers that are embracing node, not startups in the valley.
Node is at a tipping point right now, and talking about how "dumb and shitty" it is won't change that. The technology has shortcomings no doubt, but there's just too many advantages to it from the business strategy side for the shortcomings to matter.
NPM chokes for me about 1 time out of 10. The main repo has reliability issues. A lot of the libs install executables that require sudo. Java solved dependency management years ago. I don't know why every language doesn't just rely on a classpath.
I've never had any issues with npm and I started coding about 2 years ago. In fact I didn't have any issues with npm when I first started. Maybe you need to have a friend show you how to do it correctly. I can't imagine what your issue is.
I use several frameworks/libs for different tasks: Webmachine, N2O, Cowboy
I don't believe in RoR type of frameworks. I believe in clear separation between server and client. We are steadily moving towards a web of websockets and "one page JS applications". Won't comment on whether that is nice thing or not. I am not sure for myself. For client we are stuck with JS. Sucks but it's a fact of life.
Erlang (or other things using this model, though, nothing as mature exists) is the only sane way of writing "multi-user" or "mega-user" servers. For me, server side is a solved problem (because of Erlang). And I'm talking about huge, clustered backends. Node.js feels like a child's toy compared to Erlang.
I would suggest that everyone who claims to be a web programmer should at least know how to use Erlang. Otherwise, you aren't really aware of how big the world really is. And what is possible actually. This may sound elitist, and it probably is, and I am probably not a good person for talking like that.
But you can't really argue with things like this: http://blog.whatsapp.com/196/1-million-is-so-2011
Once you have experienced things like this, and once you really understand why it works and how to steadily reproduce it on every project you work on... well, that's why I claim that server side is a solved problem.
As someone who knows their way around Erlang, it needs some work for more 'average joe' programmers to get much done with it. I'm not talking about the syntax, but some set of libraries or a framework or something that gets people up and running quickly. Chicago Boss is interesting, but it's not very Erlangy (it uses compiler magic).
Edit: that said, a big company would certainly have the resources to make Erlang work well for web development, and, yes, it's way more solid than Node.js from an architectural point of view.
So does this mean Erlang only makes sense if you work for a big company or have a large team to implement it properly? (I'm responding in light of davidw's edit which you may not have seen).
You can do web stuff in Erlang. It's just that it's not like Rails, where you start it up and it's easy to do so much with so little code. Since there's not as much infrastructure, you have to do more yourself.
That can still be worth it, given the advantages the run time gives you, but I think you'd really want to know exactly what you're doing.
Thanks for your suggestion, I will definitely look into erlang. I have tried to look into it but I have found it quite unapproachable. You have to be really motivated on your own to learn it.
Everytime someone points a erlang, they bring up whatsapp. And everytime they do that, I tell them facebook the company that owns it is a php shop (Atleast, that was the core driver. Things might be different today with hiphop).
Writing something in PHP made sense in 2004. Although Erlang was around at the time, it wasn't at all well known.
And no, you are not absolutely right, Facebook is not a PHP (only) shop. Their chat backend is in Erlang and that's a much bigger tell-tale than their legacy code.
Also, a lot of us Erlangers speculate that Facebook bought WhatsApp (not only but also) because of their huge infrastructure know-how and (Erlang) talent.
Not true anymore. They switched away from Erlang because of reliability and scaling problems. So saying that mega-user server side is a solved problem because of Erlang feels like a stretch.
Thanks. Sounds like they didn't really figure out what the problem was with the Erlang implementation but instead reimplemented with C++ systems that were existing, built in-house, and better understood. Makes total sense but shouldn't be taken as a point for or against Erlang as much as it's a point for using a stack your team is familiar with (or has a deep motivation to get familiar with).
> Isn't that argument bad for erlang? That you need to pay an atrocious price for erlang know how.
That erlang know-how commands a high price on the market is a good argument for developers to invest in developing that know how, and for organizations to work on fostering it in their staff.
Its only "bad for erlang" if you assume the only way to adopt erlang is for an organization to wake up out of the blue one day and decide "from this day forth, all our work will be in Erlang, and we're going to go out on the market today and hire up Erlang talent to enable that to occur."
Can you make some recommendations for Erlang IDEs?
What's your typical day-to-day setup, and what's your workflow look like?
I love Erlang and its concept, but the lack of friendly developer tools and easy testing put me off after the one successful (commercial) project I completed a couple of years ago.
I'm all geared up to become an Erlang evangelist (particularly for the reasons you give - Node.js really does feel like a toy in comparison), it's just the process of putting the code together feels painful compared to the tools I'm used to. (whether Visual Studio or PHPStorm or...)
If you can spend a few minutes discussing your setup, I would find it immensely useful.
Erlang is great and so is Elixir but node serves a different purpose which really amounts to many different purposes of which none include things like building massive real-time and fault-tolerant messaging services (you could still use node and make it work but it certainly would be a suboptimal choice for that).
Just to follow up on topic of WhatsApp and Erlang, here is a presentation given at Erlang Factory 2014 about their goals with scaling WhatsApp to billions of simultaneous users.
I would argue the discussion is less about which framework and more about the suitability of the language. It's a debate worth having but I struggle to think of good arguments to move infrastructure of this sort of scope to JavaScript over the more "typical" options (Java/Scala, .NET, Python, go, erlang, etc.). JavaScript obviously has a place in web application development, I'm just not convinced that place is on servers in the vast majority of cases.
I've got first hand experience with this at a major airline - node is a surprisingly good fit for Bigco because it is encouraging modularization and has very predictable dependency management but most of all it allows you to fit it into your current systems easily and organically. There is not much convention (also an argument against it in some cases) other than being in many ways a very "unix" kind of environment (streams etc) with the added benefit of having Javascript's functional/event-driven roots.
Most of all to me node is fun which is especially important when you have to conquer problems in un-fun environments (most Bigco systems).
Hmm, those are strange results indeed. I would not be surprised if those measurements were made a year ago. Back then, promises were really slow.
But then bluebird came out and changed everything, and many of the other promise libraries followed suit. Most promise libs are now really lightweight (with the only remaining exception being Q).
For example, bluebird (and most other promise libraries today) have 2 to 3 times lower overhead than caolan's async and are comparable to the most hand-optimized raw callbacks.
I've watched a presentation where (I think) Linkedin talked about their use of node.js. They used it as an API Gateway (http://microservices.io/patterns/apigateway.html). The main requirements for this are making a lot of service calls quickly and transforming several JSON documents into a single JSON response. Node.js is actually pretty reasonable for this.
It's interesting to note despite the memory link, the incredible amount of traffic WalMart was handling with its Mobile apps running on NodeJS. That's what was more impressive to me.
I'd say, more than anything, the benefit it provides is more personnel-related than anything.
While there are definitely dedicated server-side and client side JS people, speaking the "same language" helps within teams and allows for some shared responsibilities.
That's appealing to large organizations with decent turnover.
I think you've touched upon the strongest argument for using JavaScript within a server stack. That said, that argument seems less strong for companies the size of Netflix, Yahoo, and so on. They don't exactly have problems recruiting top engineers. Curious stuff.
Recruiting? No, absolutely not. But maintaining? I mean if you can move in and out of server and front side, that might build some lasting engagement with developers.
It also encourages an ecosystem wherein almost any developer out there can work on either side for you.
I don't think they have mail storage, spooling and sending implemented in node.js. I think they use both PHP before and node.js now as a front tier. And this is okay, it's where node.js shines.
See, this confuses me. From working with Node and understanding its core architectural concept, the single event loop, I find Node's worst use case to be front end development.
Server side rendering takes time, even 10 ms. On an single event loop, that is terrible. You can only server 100 request/second due to the 10 ms limit. While it is nice that you can move a request into the backing queue while waiting for the data, you're capped at 100 requests/second.
Where I think Node shines is low level network management. Netflix could use it to pipe video data from one of its boxes out to a user. It's got that kind of work built right into it. As a result, I think that storage, spooling and possibly even sending would be best in Node. Those are largely I/O bound, schlep data from port to port operations.
My understanding of PHP is that it's really hard to have really global variables. Compare this to Node.js where Javascript naturally does this. I can't find it now, but I remember back when Node was young a guy had an issue with his shopping cart system. People's orders were screwed up. Turns out that he missed a `var` in a function. PHP, I don't think, could do this easily since the widest screw up scope is file. So you're still limited to request scoping.
Well...there is the global operator, and it takes into account the entire running "stack of files" - so include your config.php, lib.php wrappers, which in turn include other files for your application/framework, and then use the global $var tag in every function, and you get a reference to a truly global variable.
Why, it's nice? Throw several worker processes in and you can easily handle 1000 rps per VM.
And no, you don't really need global variables in frontend that much; and backend PHP programs (which you should not do of course) have long-lived global variables.
Not OP, but I'll chime in. Enterprise software has some unique challenges. Enterprises deal with a galaxy of small systems, a mixture of proprietary and purchased software, a mix of IT staff and consultants, leadership who may or not have techology as a core competency, frequently a lot of bureaucracy and compliance rules, lots of long-running maintenance and as a corollary, you may retain a lot of lower-tier talent if you're recruting developers to maintain an 8 year old expense reporting system. All of these scream for safety and risk mitigation more than pushing the envelope. Static typing, schemas, battle tested development tools, lots of vendor support, big pool of talent to recruit from. There's no appetite for risk taking especially when the benefits are so hard for management to understand. As a developer at a consulting company, my peers understand technology very well but clients are 50/50. They mostly standardize on Java or .NET and and I don't think I could even put together a cogent argument of why node would help them at all. Maybe personal bias because I think node is kinda shitty and my limited exposure has been nothing but painful.
Two reasons - mobile and support. Mobile, because everything on the web is moving towards API-based backends decoupled from the presentation layer. Support, because "everyone" knows how to write JavaScript.
