TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Node.js and the new web front-end

165 点作者 thisisblurry超过 11 年前

25 条评论

mjackson超过 11 年前
&gt; As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example.<p>After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I&#x27;m convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript.<p>There&#x27;s nothing inherently <i>wrong</i> with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter. The main thing that is missing at this point is experience and maturity in the JavaScript community at large, which is quickly changing as more and more developers start embracing the language.
评论 #6510453 未加载
评论 #6510537 未加载
评论 #6510555 未加载
评论 #6514262 未加载
评论 #6510673 未加载
评论 #6511098 未加载
评论 #6511081 未加载
karanbhangui超过 11 年前
I&#x27;ve been thinking about this a lot lately (and in fact probably driving a lot of my friends nuts with my views on this), but I think if you take a look at what Airbnb has done with Rendr and what ex-Google Wave engineers have done with Derby, it becomes immensely clear what the potential here is.<p>Traditionally you&#x27;ve had to maintain two codebases for things related to rendering (think generating URL slugs, or formatting dates). This code duplication is obviously solved by running node layer in the middle. But the benefits go well beyond unifying rendering code and separating &quot;backend&quot; developers from &quot;frontend&quot; developers.<p>My excitement is the ease of building highly interactive apps while staying true to how web pages were meant to be architected. Since your client and server runtime are aware of each other, the framework can handle things like partial rendering, multi-client sync via OT, request caching, incrementally pushing required css&#x2F;js&#x2F;html payloads to the clients as necessary (instead of doing one massive push at the beginning). Right now the client and the server talk to each other through a constricted API layer you have to create endpoints for manually.<p>It&#x27;s exciting to think how much of this can be automatically handled by the framework. I believe this generation of web architecture will finally bridge the gap between &quot;websites&quot; (often progressively enhanced HTML payload) and &quot;webapps&quot; (massive javascript payload, almost no HTML).
评论 #6510766 未加载
ChikkaChiChi超过 11 年前
This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake.<p>Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very optimized echo chamber. Users will be found elsewhere dealing with products that are faster (for them) and teams clamoring for how they can continue to improve the experience with each iteration.
评论 #6509727 未加载
评论 #6510886 未加载
评论 #6510781 未加载
评论 #6511137 未加载
评论 #6510427 未加载
评论 #6510109 未加载
评论 #6513102 未加载
评论 #6510311 未加载
jacques_chester超过 11 年前
OK, dumb question time. How are front-end and back-end defined?<p>To me the distinction was about the location of execution. &quot;Front-end&quot; meant &quot;in a browser&quot; and back-end meant &quot;anywhere else with some surface addressable via HTTP&quot;.<p>Now it seems that &quot;front-end&quot; means &quot;View and Controller&quot; and &quot;back-end&quot; means &quot;Model&quot;, except ... not quite. Sometimes.<p>On the other hand, perhaps I protest too much. It&#x27;s not as though there&#x27;s a High Court of Internet Nomenclature for this.
评论 #6509632 未加载
评论 #6509606 未加载
评论 #6509644 未加载
评论 #6509649 未加载
评论 #6512101 未加载
评论 #6509646 未加载
EGreg超过 11 年前
This is interesting. Basically what I like Node.js for is the evented programming that JS encourages. That and the fact that web developers are already familiar with JS.<p>Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you&#x27;ll need to shard (partition horizontally) your database.<p>An aside -- if you find yourself using an ORM and sharding a lot, then most likely you should have used a NoSQL database such as Riak, instead of a relational DB. But let&#x27;s say you&#x27;ve already gone this route, and used MySQL, which a lot of sites including facebook have done.<p>In this case, anytime you need your query to hit N shards, PHP will take (s1 + s2 + ... + s_n) time to do it. Node.js will take MAX(s1, s2, ... s_n) which is much faster. There is a big difference for latency. (It&#x27;s true that the mysqli driver in PHP does support concurrent queries, but the above comparison isn&#x27;t just for DB but for EVERYTHING. In JS and Go you have the option to do concurrent I&#x2F;O, in PHP you don&#x27;t.)<p>Another difference is in the memory usage. PHP has to create a copy of your environment for every preforked process. It depends on Linux to do copy-on-write, for instance. APC helps a little with shared memory segments, but not much. On a 2GB RAM machine, how many clients can you support with PHP vs Node? Node has just one copy of the code running, and each request costs very little in comparison. Of course, since everything is in the same memory space, you can easily bring down the whole process, so Node.js processes need to be built to survive crashes, unlike PHP scripts which are isolated.<p>And let&#x27;s not forget that Node.js stuff can push to the client, whereas for PHP to do that you need wasteful, long-running sleeping processes sitting in memory, and having some nginx event module to simulate evented programming.<p>In short, Node.js and stuff like that gives you much more flexibility, many more things you can do (such as pushing data in near real time to many different endpoints including the browser), but at the same time you need to code everything in a way that crashes don&#x27;t matter much.
评论 #6509682 未加载
评论 #6510170 未加载
评论 #6509697 未加载
评论 #6509520 未加载
10098超过 11 年前
&gt; I was never a fan of PHP<p>Interesting how the same people who are &quot;not fans&quot; of PHP somehow like Javascript. As if it&#x27;s better.
评论 #6511151 未加载
评论 #6511056 未加载
评论 #6511167 未加载
评论 #6511062 未加载
webjprgm超过 11 年前
Do people really pigeon-hole themselves into being just back-end engineers? Or just front-end? I can imagine a designer-type person picking up HTML, CSS, and eventually JavaScript and calling him&#x2F;herself a front-end engineer in a limited way. But as a programmer I work on all of it, both server-side and client-side portions. (So I&#x27;m a full-stack engineer I guess.)<p>It seems to me that a designer who picked up some JavaScript would still not be a programmer. Lots of apps require advanced JavaScript to run a UI client-side. I would not expect anyone who was a full programmer to be just a front-end engineer and be completely unwilling to learn PHP or Ruby to also work on the back-end. If I met a person like that I would think the person a horrible programmer and not hire him&#x2F;her. (Unable or unwilling to learn, lack of passion for software engineering excellence.) A designer with a few extra skills is one thing, but a restricted programmer is something else entirely.<p>But what do I know? Hence I ask whether this is common.
评论 #6509745 未加载
评论 #6510353 未加载
评论 #6509953 未加载
评论 #6509854 未加载
评论 #6510525 未加载
评论 #6509722 未加载
carsongross超过 11 年前
In as much as the distinction is useful, wouldn&#x27;t node be considered <i>backend</i>?<p>This is what drives me bonkers about the node and JS community: there is so much goddamned noise and &quot;nobody cares!&quot; arrogance in the signal it&#x27;s difficult to know who to take seriously.
评论 #6509656 未加载
评论 #6509737 未加载
hrjet超过 11 年前
I was working in a largish project recently with a three-tiered architecture as described in the article. However, both of the server-side tiers were in Scala, and it was hard to see the advantage in that case.<p>However, using NodeJS in lieu of Scala for the middle tier, suddenly makes a lot of sense. Thanks to the article for showing this path! To be sure, NodeJS can be replaced with something equivalent, such as N2O or JScala (as others have mentioned). But the concept is more clear when expressed in terms of NodeJS.
aufreak3超过 11 年前
I code a lot in JS these days and I find this divide suggestion interesting. Though I&#x27;m proficient in JS, I don&#x27;t trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would rock, typed racket also looks awesome from this perspective.<p>To my main point, I&#x27;m unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the &quot;ui front end at the back end&quot; (whew!) or directly to the &quot;real back end&quot;? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services <i>without</i> going through such a &quot;front end at the back end&quot;?<p>Thoughts&#x2F;suggestions?
评论 #6513146 未加载
badman_ting超过 11 年前
I love JS, but I have trouble with this idea that people are against using Node because they&#x27;re afraid of JS or whatever. EGreg has mentioned some situations like millions of users or pushing data to the client, where Node makes sense. But I&#x27;m not sure what inherent value running JS on the server has.<p>Also, while it may be true that the backend devs don&#x27;t care about the flow of pages that the user browses, the user does care. That means that the services that put together the pages need to work for the user&#x27;s use case. That means that the system needs to be designed for the pages the user looks at. You can&#x27;t escape this, this is bigger than your architecture. It&#x27;s almost like a law of physics.
评论 #6509708 未加载
JacksonGariety超过 11 年前
Can someone explain why the author refers to the nodejs layer as &quot;front-end?&quot;<p>It is a UI-layer, but is it not still back-end?
评论 #6509347 未加载
评论 #6509241 未加载
mtam超过 11 年前
I am struggling to see how this approach would be beneficial outside of large organizations with massive web apps. For most apps, the benefits do not seem to outweigh the drawbacks of having (1) another dependency, (2) another piece of software (node) to install, update, and maintain, (3) another set of code base, (4) an increase in latency, and (5) all the added complexity to troubleshooting, debug, document, etc...
exo_duz超过 11 年前
I&#x27;m quite new to Node.js but I heard that it&#x27;s really good. Does it really solve the need of server side scripting? I&#x27;m thinking of learning it if I can get good justification to.<p>I currently program in PHP for all my websites.<p>Any pointers and comments greatly appreciated. Thanks in advance.
shapeshed超过 11 年前
Isn&#x27;t the point that with a REST interface you can move your UI layer entirely to client-side JavaScript with any of Ember&#x2F;Angular&#x2F;Backbone. Behind the REST interface your tech can be anything and you can swap it at will.
agibsonccc超过 11 年前
I&#x27;m a big fan of using node for an intermediary web stack. It really plays well for handling your web layer with the tools available as well as handling builds with grunt and friends.<p>I think the real potential comes in when you blend it with a heavy lifting API written in go or on the JVM. Easy web layer that&#x27;s agnostic to whatever heavy processing language should you decide to do.<p>Obviously there&#x27;s a bit of complexity that comes with this, but if you need to scale up it&#x27;s right there. Even then, node is pretty powerful on its own, where you might not need a crazy backend.
dmak超过 11 年前
Traditionally, I defined backend as server side programming basically anything that is run on the server before it reaches the browser. Since front-end engineers know JavaScript already, they can just effectively make an abstraction that spits out what they need using Node.js which is technically still in their domain. I never thought of it like that, but that totally makes sense too, wow. Nice read.
pweissbrod超过 11 年前
Unless youre dealing with a large complex app or scalability is a major concern I dont see how adding an extra nodejs vestige is worth all the trouble. Take the coolness of node out of the equation and not much compelling arguments are left from a business value perspective.
heynairb超过 11 年前
Isn&#x27;t this architecture redundant? Why have two application servers in between the database and the browser? Wouldn&#x27;t it be better to serve the page once and have the browser communicate directly with the api? Is this setup common? Is it really the future?
评论 #6510759 未加载
sassyalex超过 11 年前
If you are smart enough you can make every code fit your need and reach the code quality you need.<p>JS weakly typed ? Seriously learn on how to adapt your coding style. I&#x27;ve built more than 20 API&#x2F;Apps and Node is the best thing I ever had to build networked apps. I have a J2EE&#x2F;Spring, Python and RoR background, NodeJS&#x2F;NPM took the best of every stuff created before.<p>In my case, I need to be fast and JS + NodeJS + his awesome community permits me to build stable, innovative solutions and high performance networked app in a very short amount of time.<p>We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself.<p>I need hacker modules to accomplish and solves problems of my current worlds, hacker offers me that.<p>NodeJS is great and lot of thing I read before was old school shit.<p>And BTW, yes a lot of logic must be delegated to the client side. This is a trend and it will not be stopped. Rendering page server side, qu&#x27;est ce que je peux pas entendre comme connerie parfois.
ronreiter超过 11 年前
This is a disaster. Why would you want to create such a complicated system? node.js has a bright future and will be able to replace languages such as Python, Java, C#, etc. But why do two back-ends when you can do one instead?
评论 #6512371 未加载
CmonDev超过 11 年前
If you ever complained about having to refactor a messy ex-outsourced codebase in Java&#x2F;C#, then wait for wider JS adoption. I bet JS not being used for business logic will be advertised as a feature in job listings.
indubitably超过 11 年前
Right, the Chrome icon should represent the user-facing internet.
pjmlp超过 11 年前
Frontend Engineer?!?
评论 #6512942 未加载
thomasreggi超过 11 年前
all javascript everything