|
Right now a front end designer and I are building a site with a node server as the template renderer. He's building the lot through standard front end build tools, all static builds in Jade but with template data supplied by JSON files. Meanwhile, I'm building the server stuff on Django because its suitable for this project. When it comes time to port the static builds over to the dynamic website, were just going to run a little node server that accepts PUTs with a JSON body, and returns the requested template rendered with that data. Theory is the template rendering stays with the same tech throughout the entire project (rather than say a buggy implementation of pyJade, ), we can prerender React, yet still avoid having to deal with Node actually talking to the end user. In addition each template render should be cacheable, what with the only element changing being the incoming template JSON. Mainly, we avoid having to use Node for all the server poo poo that its bad/immature at, whilst taking advantage of all the front end tooling written in JS these days. Might crash in a flaming heap, but feels pretty reasonable as a concept.
|
#
?
Feb 26, 2015 21:12
|
|
|
|
| # ? Apr 25, 2024 10:53 |
|
|
Plorkyeran posted:Embedding v8 in your main application server would probably be better, but it certainly wouldn't be easier than using pre-existing solutions. A load-balanced node worker pool that doesn't add hundreds of milliseconds of latency is a rather solved problem, and since it doesn't need to be public-facing you don't even really need to be able to scale the worker pools. embedding javascript in e.g. .net or java is also a solved problem why marshal if you don't have to?
|
|
#
?
Feb 26, 2015 23:56
|
|
|
Maluco Marinero posted:Right now a front end designer and I are building a site with a node server as the template renderer. He's building the lot through standard front end build tools, all static builds in Jade but with template data supplied by JSON files. Meanwhile, I'm building the server stuff on Django because its suitable for this project. This is pretty much exactly what I advocated in my post earlier, except you're actually doing it. It's like a more specialized and thus more efficient version of https://prerender.io/
|
|
#
?
Feb 27, 2015 00:24
|
|
|
Fib posted:Hi guys, great thread! I'm a bit of a Node 'newbie' but I can tell you that if you don't like callbacks, there are blocking versions of all the IO library calls javascript programmers explained.
|
|
#
?
Feb 27, 2015 03:02
|
|
That's what I'm using for my current project, a FreeBASIC to C++ compiler written in Node.js.
|
I've been loving around with it a little bit and it seems neat. Kind of a nice change of pace from the C# stuff I do at work. I don't know how it would be for a serious project though.
|
|
#
?
Feb 28, 2015 05:52
|
|
|
We use Node at my office. It's pretty great for little start-up companies where you only have one developer and you need a back-end and a front-end and why switch context when you can just live in JS all the time? The V8 engine is pretty spectacular, so you can get a lot of mileage out of this setup. You're often doing most of the work on the front-end, and the back-end is just a layer on the database. We've been hitting some Node walls lately, because it's not a good general-purpose back-end choice. There's a much higher number of heavily-used libraries that are dumb than I'm used to. Logging kills it (yes, logging kills all back-ends, but Node goes down faster and with fewer users than anything else). Callbacks are great when the chain is short (take a request, hit a DB, hit another web service, reply to the request), but once you have 10 operations to perform, it's hell. If you have 10 operations to perform and you're not doing callbacks, then you're hosed because it's single-threaded. It's easy to write code, and I'd definitely use Node for prototyping. Beyond that, though, I feel like you either run into trouble or you have to become such a deep expert at the V8 engine and the C libraries that you lose the whole "any dumb programmer can do it" point of Node.
|
|
#
?
Feb 28, 2015 06:43
|
|
|
Mniot posted:We use Node at my office. It's pretty great for little start-up companies where you only have one developer and you need a back-end and a front-end and why switch context when you can just live in JS all the time? The V8 engine is pretty spectacular, so you can get a lot of mileage out of this setup. You're often doing most of the work on the front-end, and the back-end is just a layer on the database. I am, like I said, a neophyte. But isn't this where a promise library would be useful?
|
|
#
?
Feb 28, 2015 08:15
|
|
|
RICHUNCLEPENNYBAGS posted:I am, like I said, a neophyte. But isn't this where a promise library would be useful? If there's little to no complexity, then yes. But if you want to run some async operations in parallel you get nested promises and that can be pretty ugly. And some things like Node.js streams (which are nice) use a callback interface and so you have to do both promises and callbacks. We mostly use Bluebird for promises and there spots where promises make things harder instead of easier. I've heard good things about Async.js for managing callbacks but haven't used it. It's not like you can't do anything you want in JS. But my experience with Node is that it makes a certain class of easy problems a little easier, and makes most hard problems harder. Coming from a server-side Java background, that's not typically the trade-off that I want to be making.
|
|
#
?
Feb 28, 2015 14:05
|
|
|
Mniot posted:If there's little to no complexity, then yes. But if you want to run some async operations in parallel you get nested promises and that can be pretty ugly. Can you explain this comment? I know little about the proposed or planned promise implementation in javascript, but every other implementation of promises or futures that I've used makes it incredibly easy to run async operations in parallel...
|
|
#
?
Mar 1, 2015 00:28
|
|
|
I feel the problem lies not in a lack of capability, but an inability to maintain consistency throughout the stack because many libraries implement asynchronous functionality through convention only, and that tends to result in a lot of glue work to get libraries to play nice whether its streams, promises or node convention callbacks (error, ...arguments) Being convention only, it can be pretty hard to guarantee a poor assumption early in the stack hasn't bubbled up to an error you're experiencing. As per usual, the trivial examples people use to say how great node is never really hit this problem.
|
|
#
?
Mar 1, 2015 02:15
|
|
|
Steve French posted:Can you explain this comment? I know little about the proposed or planned promise implementation in javascript, but every other implementation of promises or futures that I've used makes it incredibly easy to run async operations in parallel... Not really. I'd have to paste 5 pages of our internal code, write 5 pages describing the clients and the other back-end services and what the code is for, and then everyone would pick apart the dumb bits (there are plenty) and suggest alternate libraries and technologies ad nauseam. I don't think "incredibly easy" can ever describe interleaved threads of execution. I'm not claiming "JavaScript can't do complex parallel operations". I'm claiming that when you need to build a complex DAG of forks and joins, languages that expose some thread construct make things easier because you can write some operations serially and trust the language to handle the parallelism but you can also control all the parts that you need to. It's ugly, hard code no matter how you slice it, though. Node.js (with or without promises) adds complexity here because you've got all these operations that must be written async since you don't have threads. Maluco Marinero posted:As per usual, the trivial examples people use to say how great node is never really hit this problem. Yeah, this. And you can write actual money-generating applications that are built out of nothing but trivial pieces and use Node fine. And if you need more, you can become an expert at all the deepest bits of V8 and Node and JavaScript and every library you use. But then you're no longer instantly converting your front-end developers to full-stack.
|
|
#
?
Mar 1, 2015 04:53
|
|
|
This issue is a doozy. https://github.com/joyent/node/issues/7412 I'll quote an excerpt from the best comment: quote:This issue is PHP-like in the absurd brokenness of the implementation, the difficulty of doing a simple thing correctly, and the recalcitrance of the maintainers in fixing or even documenting the problem. It's eerily reminiscent in its use of this three-pronged justification:
|
|
#
?
Mar 6, 2015 00:32
|
|
|
https://github.com/iojs/io.js/issues/1070 it will be interesting to see io.js tracking node.js issues and their different approaches to interfacing with the community. Interesting like a soap opera.
|
|
#
?
Mar 6, 2015 01:29
|
|
|
Deus Rex posted:This issue is a doozy. tjfontaine posted:The way readFile works is to first to stat() the file and then read that size,  So at first I was worried (hoping) they actually do a stat on the file, then open it. But it turns out they were doing it the (kind of) right way from the beginning. Except, if they used to have a "slow", but compatible version of readFile, why did they dump the slow path?
|
|
#
?
Mar 6, 2015 01:39
|
|
|
Hoping this thread isn't too old to bump. I am using my bored time to try and program a simple turn based game in Node.JS and holy poo poo is it tedious. That said, express and socket.io make parts of it ridiculous easy and powerful. It just sucks when you throw a database in the mix. I think I have about 10 nested callbacks at one point.
|
|
#
?
Jun 18, 2015 20:46
|
|
|
I understand that Async is popular if you want to do callbacks, though I haven't used it. At my office, we use Bluebird for promises. Then your 10 nested callbacks turn into 10 chained promises. If it's a straight chain, promises are nice. They often feel easier to wrap your head around, too. On the other hand, whenever I start working with Node's streams (which are quite nice) I need to use callbacks and then I regret the callback/promise mixture that I end up with. Finally you could look into using fibers, which I think would be the most pleasant way to handle a sequence of DB calls.
|
|
#
?
Jun 19, 2015 12:36
|
|
|
Mniot posted:I understand that Async is popular if you want to do callbacks, though I haven't used it. At my office, we use Bluebird for promises. Then your 10 nested callbacks turn into 10 chained promises. I love that there's a major async helper library for a platform whose main advertised feature is that it makes it easy to make asynchronous services out of the box.
|
|
#
?
Jun 20, 2015 06:58
|
|
|
What about Meteor? I've been using it to build a multiplayer word game with timed rounds and rooms and so far it's going well. It runs on Node with Fibers and has reactive sessions.
|
|
#
?
Jun 21, 2015 05:02
|
|
|
Look Around You posted:I love that there's a major async helper library for a platform whose main advertised feature is that it makes it easy to make asynchronous services out of the box. To be fair, IIRC it's more about doing things like running calls in parallel and it does it in ways that are compatible with the standard way Node does callbacks. It's not necessary for doing the basic things.
|
|
#
?
Jun 25, 2015 18:47
|
|
|
As with many topics, Garrett Smith's take on this is an apt summary https://www.youtube.com/watch?v=bzkRVzciAZg&t=138s
|
|
#
?
Jun 25, 2015 20:09
|
|
|
I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. If not node, then what should web applications be built on?
|
|
#
?
Aug 8, 2015 15:33
|
|
|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. Django or Flask are pretty good for Python based web applications, for large large scale web applications then the various big Java frameworks (JEE, Spring, whatever weird enterprise poo poo is here), for smaller scale web applications then Dropwizard for Java, maybe Play on Scala, maybe Clojure has a nice one. One of those is probably good enough. edit: Oh right and C# with ASP.NET MVC or WebApi or whatever that's all called piratepilates fucked around with this message at 16:01 on Aug 8, 2015 |
|
#
?
Aug 8, 2015 15:58
|
|
|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. Laravel
|
|
#
?
Aug 8, 2015 16:23
|
|
|
Trick question: web applications shouldn't be built at all
|
|
#
?
Aug 8, 2015 16:59
|
|
|
Series DD Funding posted:Trick question: web applications shouldn't be built at all Ding ding ding!
|
|
#
?
Aug 8, 2015 18:08
|
|
|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. Anything else really. Fortunately you have a wide choice of languages and platforms, most of them being better than node/javascript on the server. C++, Go, Python, Scala, Java, Groovy, Ruby, JRuby, Haskell even. Anything would do. Just because you don't have a choice on the client, doesn't mean that you should throw away choice on the server.
|
|
#
?
Aug 8, 2015 18:28
|
|
|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. ASP.NET MVC 5
|
|
#
?
Aug 8, 2015 18:52
|
|
|
Volguus posted:Anything else really. Fortunately you have a wide choice of languages and platforms, most of them being better than node/javascript on the server. C++, Go, Python, Scala, Java, Groovy, Ruby, JRuby, Haskell even. Ding, ding. The fact is when you see libraries on other languages, it's a sure bet that they decided it was the best tool for the job. Many, many libraries in Node are just barely filling a gap so they can stay in the JavaScript bubble land, but are half assed in many cases, perpetually in version 0.x, never committed to being production ready. JavaScript is the best tool for front end web because it's the only tool (or a compile down target). Everywhere else there's always something better than what JavaScript can provide, and front-end + back-end code reuse doesn't nearly work out as well as JavaScript people would have you think. Edit: also, there is one aspect of server side work where Node.js has better libraries. Surprise surprise, it's templating, being a front end and back end class of library means you have plenty of needs suiting choices for Node. Maluco Marinero fucked around with this message at 23:43 on Aug 8, 2015 |
|
#
?
Aug 8, 2015 23:05
|
|
|
Is it just me or does Mongoose just kind of suck? Like the last time I used it the TypeScript definitions didn't even fully work, if you attach methods to the schema using schema.method('balls', function(){console.log('fart');}) then you wouldn't be able to access it from an instantiated model, the definition doesn't include the schema types to be on the model.
|
|
#
?
Aug 9, 2015 00:35
|
|
|
Thanks. Can any of you share some examples of projects you've created/worked on that demonstrate your suggestions?
|
|
#
?
Aug 9, 2015 00:39
|
|
|
neurotech posted:Thanks. Can any of you share some examples of projects you've created/worked on that demonstrate your suggestions? See: almost every site on the internet.
|
|
#
?
Aug 9, 2015 02:12
|
|
|
Thermopyle posted:See: almost every site on the internet. I'm more interested in seeing source code for projects that are built to handle the larger scale requirements that node supposedly isn't good at meeting.
|
|
#
?
Aug 9, 2015 02:17
|
|
|
neurotech posted:I'm more interested in seeing source code for projects that are built to handle the larger scale requirements that node supposedly isn't good at meeting. These are almost assuredly commercial sites and the code is proprietary.
|
|
#
?
Aug 9, 2015 02:39
|
|
|
The biggest issue with Node APIs for me was the miserable stack traces but I'm hoping generators or async/await could fix that? It's been a while since I worked on a production Node app...
|
|
#
?
Aug 9, 2015 02:51
|
|
|
Stoph posted:The biggest issue with Node APIs for me was the miserable stack traces but I'm hoping generators or async/await could fix that? It's been a while since I worked on a production Node app... There was always that package 'longjohn' for pretty printing async stack traces, Chrome does the same thing for the client facing stuff now. edit: Too lazy to check but I really doubt that async/await or generators are native in io.js right now, so the only way of doing it would be through Babel or maybe TypeScript, and that would then as far as I know involve lots of state machines that probably just lead to even more confusing stack traces, but I could be wrong about all of this. piratepilates fucked around with this message at 03:42 on Aug 9, 2015 |
|
#
?
Aug 9, 2015 03:36
|
|
|
Generators are native in all npm compatible runtimes. Async is not. I like that generators preserve the stack trace really nice if your application uses them pervasively...
|
|
#
?
Aug 9, 2015 04:27
|
|
|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. piratepilates posted:Django or Flask are pretty good for Python based web applications, for large large scale web applications then the various big Java frameworks (JEE, Spring, whatever weird enterprise poo poo is here), for smaller scale web applications then Dropwizard for Java, maybe Play on Scala, maybe Clojure has a nice one. One of those is probably good enough. I think Java EE is deprecated in favor of Spring and Jetty. They're pretty hella fast and not bad to develop in. Lift/Play appear to be popular, but I wasn't overly fond of the abundance of mandatory structure, last time I tried them. I develop in Django for work and it's generally not too bad, but it has problems when you need to refactor, and sometimes it's nice to have the assumptions assured by a statically typed language. I've used Flask for tiny personal projects and that's especially nice if you don't need any fancy ORM stuff. (I'm a slut for the Django ORM. Fight me.) I rather like it overall, and being able to play in the Django shell is incredibly useful when you want to experiment. While I'm not a frontend developer, I'm familiar with JS + Underscore + jQuery from my last job. It works well enough on the browser, and with jQuery handy it seems to remove a lot of the warts. Perhaps I just don't understand the need that Node satisfies. I mean, sure having a singular language is handy, but I always feel like the difference in dialect/use between what you're doing user side and server side is so different that you might as well use different languages.
|
|
#
?
Aug 9, 2015 22:31
|
|
|
bomb posted:Laravel This but unironically. It's amazing.
|
|
#
?
Aug 12, 2015 13:11
|
|
|
I've avoided Laravel just because I'm focusing on learning more Java and JS. It still looks very cool. This thread has me a bit curious and I'd like input from people with actual experience. I've been learning the MEAN stack. For the first time working with mongodb. What's so wrong with node? Because despite the previous lol in this thread the benchmarks for node are nice. Does it break down on larger production-scale apps? It looks fast, and IS easy. I avoided mongo for a long time because people were having serious doubts about its security, but with recent updates it's apparently a viable choice again. On the other hand I could dedicate myself to learning Spring with Angular on a RESTful API. Spring looks cool, simple, and just as easy. Perhaps with more flexibility than the MEAN stack. Production time is a factor as well, and both seem about equal, simply depending on the size of the project. I've worked with Angular a lot using REST services. It's been more of a front-end adventure than full-stack, so I'm at a point where I'm deciding on where to dedicate my learning time on backend stuff. I've already made full-stack apps with C# MVC5 and (embarrassingly) with a very bad backend that I won't name right now. MVC5 is very cool to work with, I just despite IIS because of its MS requirement. I almost learned Ruby on Rails but stopped myself, because recent articles on Ruby really makes it look like it has a bad future. I'm just looking for options and input; and something Java or JS based seems like the way to go.
|
|
#
?
Aug 13, 2015 21:19
|
|
|
|
| # ? Apr 25, 2024 10:53 |
|
|
pepito sanchez posted:What's so wrong with node? In short, though, JavaScript isn't a very good language. It was an acceptable language in the mid-90s as its design goal of providing "light scripting" for largely static webpages didn't necessitate a more complex language. However, over the past decade it's been pretty clear that it's outgrown its scope as a frontend language for highly-dynamic sites, but folks still use it because it's the one language (or compile target) that all browsers support. But honestly, dragging it into the server-side where we've long had better languages of all sorts, doesn't make sense. Hence, benchmarks are a major selling point of node because, honestly, there's not many others. It's hard to explain (beyond what we've already done) where node falls short in practice. In my opinion, its three biggest flaws are: complicated code (due to forced async with no threading and many callbacks), performance issues (where blocking I/O introduces jitter to the event loop), and a relatively immature community and collection of third party libraries. On the surface, node might look great, but anyone who uses it for large/complicated projects ends up feeling the compounded effects of those flaws. I'm sure there's limited-scope use case for node that are just fine. Prototyping, templating, use as a test framework, simple proxies, can all be done in node quite manageably. But I'd really hesitate to use it as the basis of a large project with a 10+ year expected lifetime.
|
|
#
?
Aug 13, 2015 23:08
|
|