121–130 of 301 posts
I was hoping to see a conversation around the points addressed in the slides (e.g. how to handle async data in Flux). Instead, it's a bunch of neckbeards whining about people using Node.
Earlier quoted context omitted.
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could u…
Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bun…
But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it.
And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading.
I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional.
Earlier quoted context omitted.
Disclaimer: I am a full-time Erlang programmer 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. Suck…
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).
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.
Earlier quoted context omitted.
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://react…
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…
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...
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.
Earlier quoted context omitted.
node.js is the new PHP for hip web developers who read HN. It's still a relatively unheard of platform to most people and mocked by a lot as well. I love it though.
Well, if you are like me, who worked with PHP for years, node.js feels nicer to use. Npm alone makes it better than PHP ever was.
Earlier quoted context omitted.
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 (Erl…
Earlier quoted context omitted.
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 ho…
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.…
Boy oh boy do I wish that were the case.
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.
> I don't think huge enterprise systems for some of the largest brands in the world are necessarily the best fit Why??
Earlier quoted context omitted.
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 ho…
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.…
Possible, but not easier.