|
Plorkyeran posted:I like the idea of using node to pre-render JS frontend stuff on the server. Having two different sets of view rendering code sucks, and so does serving a blank page that turns into an actual page five seconds later. this is a genuine use case for javascript on the server - but it might still not count for node. using node for ssr, you have the overhead of process creation and startup on every web request - or at best, serialised ipc.. to a manually managed pool of processes since they're each single threaded. that's a good way to waste hundreds of milliseconds and hit scaling bottlenecks. it's easier just to embed v8 or some other javascript engine in-process of whatever you're using for the server.
|
#
¿
Feb 26, 2015 08:18
|
|
|
|
| # ¿ May 10, 2024 07:17 |
|
|
search engines are also a big fan of crawling pages with actual content, rather than an empty <div id="react-mount">
|
|
#
¿
Feb 26, 2015 14:48
|
|
|
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
|
|
|
let i hug posted:I don't understand why everyone ITT is insisting that all web apps be written in statically typed languages from the start. My experience is that if you're starting from scratch on something you're not going to understand your end product/the business domain well enough to build anything that you won't want to totally replace after you start gaining momentum. If you know you're going to want to start over again when your app hits ~40k lines of code, why would you spend that time writing in verbose, clunky languages? Better just to code it Ruby/Python/even Node, get it out the door, and then when it starts to get too big on you, just move to microservices in Java/.NET/whatever. in the line of business industry, which is pretty huge, the expectation is that some company or organisation pays to have a project delivered; there's an implementation phase, they pay a bunch of money, then it's done. then they want to keep *using* the system for as long as possible. sometimes there's a followup support contract or internal support devs; in either case these are like, part time people with little experience in the system, who have to touch it once every 18 months and want change to be as easy and reliable as possible. if an IT system can serve its business purpose for 5-10 years, why not build it that way?
|
|
#
¿
Aug 15, 2015 10:10
|
|