|
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
|
|
|
|
| # ¿ May 10, 2024 21:45 |
|
|
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
|
|
|
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
|
|
|
Yeah. Facebook is basically the case in point for digging in on a technology no matter what.
|
|
#
¿
Aug 14, 2015 22:06
|
|
|
Yeah ugh. Shrink wrap your dependencies and release as a .tar.gz otherwise you can face that pain so easy. Semantic versioning is good in theory but so many libraries don't respect it. (lol at the underscore library authors reaction to being called out on breaking semver)
|
|
#
¿
Aug 16, 2015 04:39
|
|
|
Yeah, QA and Prod should be subject to the exact same configuration management, and deployment should be build once, deploy twice, with all packages pulled down into the build. That way the build artifact (whatever it is) can be rolled back to with absolutely zero dramas.
|
|
#
¿
Aug 16, 2015 05:27
|
|
|
Yeah, the issue is today's prototype is tomorrow's production. PayPal essentially transitioned from prototyping in node.js to deploying production in node.js. Whether this choice holds up in the long term remains to be seen, but we've seen the consequences of such a choice before in Rails applications. Facebook gets by with PHP via a furious case of digging up (optimisations, compilers and what not). Also, as said there are far better languages to do these prototypes in, with far healthier ecosystems for back end tech. I have no idea when a decent SQL Statement Mapper will come existence, maybe follow a relation or two. Prototypes are best built with stable reliable libraries & frameworks, not a house of cards that sends you error chasing all the time.
|
|
#
¿
Aug 23, 2015 02:33
|
|
|
You'll have to qualify narrowly bounded I'm afraid. Turns out I do use node in production, however I try to restrict that to what it's best at, rendering templates, forming the basis of a front end build system, sharing the render code for client and server code. In cases where I have worked beyond that I find its error handling disappointingly leaky, it doesn't lend itself well to larger teams because of that, and the libraries it's built upon are immature, meaning wheel reinvention is often needed, including downright bizarre behaviours in even simple cases like trying to set a cookie in express + passport. (passport would override what I sent previously and change parameters on it). Of course, everyone's development scenario is different, but there's a lot of things that are taken for granted in more mature languages that just can't be in Node. Anything can be used in production if you spend enough time papering over the problems to avoid abandoning your existing code, but that doesn't mean it's a good foundation to build new stuff on.
|
|
#
¿
Aug 23, 2015 04:19
|
|
|
Hegel posted:but the overbearing problems from things like a Java server-side application or the downright deplorable hell of maintaining inherited templates in Django are enough to convince me that any judicious dev team can deploy node effectively with greater efficiency than other pieces of tech for particular problems. That seems like a kind of bizarre conclusion to draw, as we can easily use the same 'well they're doing it wrong' response as you're using to defend node as a technical choice. You seem to be in some confusion as to what developer I am and dismissing my views because of it so: I'm a front end developer who focusses on client side web applications backed by thin application servers. Tech I've used to write the backend include Python & Django, Scala, dabbled in Haskell, brief stopover in Ruby & Rails, and yes, Node & Express too. (Oh and Node & Sails) The majority of which were my decision to use, except for one Node app where the decision was made before I came in to work front end. In the cases where I've decided to use Node, it has specifically been for its ability to share render tech via React, and in that role it is very effective. In the instances where node is responsible for all application logic, I have found the benefits touted, like shared code between client/server, or performance, or ease of writing, to be thoroughly overrated. Couple the fact that the benefits don't deliver, with immaturity of the libraries upon which you depend, and it doesn't actually end up being a solid choice for prototyping or production. Put simply, my opinion is Node has a place in the stack, but not as all of it. This is all opinion mate, but it's the same on your side of the fence, we only have our experiences to draw from and we argue our opinions as best we can. I don't believe anything I'm saying here is particularly outlandish - as for Rails, it's been a fair while since I've done work with it (mainly during 1.8-1.9), and the ecosystem felt an absolute mess at that point, poor documentation, unwieldly Unicode behaviour, a love of monkey patching and DSLs, a heavily coupled framework that makes for great business for Rails consultants, but leaves you up poo poo creek if you don't have the resources to write your way out of it. If you're measurement for tech is that SOMEONE has made it work, every framework and language is good. Maybe things are much better in Ruby land these days, just like PHP frameworks have come a long way, but there are a lot of little things in every language that will likely never change. There is no reason why you have to accept those problems in a technology for a greenfields project, so just because someone chose one way and made it work, doesn't make it a good choice for the rest of us.
|
|
#
¿
Aug 23, 2015 07:38
|
|
|
|
| # ¿ May 10, 2024 21:45 |
|
|
As I've said earlier I've used node like that. Actually works pretty well, our front end tooling lines up with our final 'view-layer' server, and the API for that server is just a route per template with JSON as the data. The proper server handles everything other than templating, right at the end it just calls the node server to render a JSON payload to a template and then returns the result in the response. Always gives us the option to render some views client side or server side without writing much if any new code, and we still keep a proper backend framework so all the stuff you take for granted 'just works'.
|
|
#
¿
Aug 30, 2015 12:21
|
|