Nút chạy javascript như thế nào?

Là một thời gian chạy JavaScript hướng sự kiện không đồng bộ, Node. js được thiết kế để xây dựng các ứng dụng mạng có thể mở rộng. In the following "hello world" example, many connections can be handled concurrently. Upon each connection, the callback is fired, but if there is no work to be done, Node. js will sleep

const http = require('http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

This is in contrast to today's more common concurrency model, in which OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. Furthermore, users of Node. js are free from worries of dead-locking the process, since there are no locks. Almost no function in Node. js directly performs I/O, so the process never blocks except when the I/O is performed using synchronous methods of Node. js standard library. Because nothing blocks, scalable systems are very reasonable to develop in Node. js

If some of this language is unfamiliar, there is a full article on Blocking vs. Non-Blocking

Node. js is similar in design to, and influenced by, systems like Ruby's Event Machine and Python's Twisted. Node. js takes the event model a bit further. It presents an event loop as a runtime construct instead of as a library. In other systems, there is always a blocking call to start the event-loop. Typically, behavior is defined through callbacks at the beginning of a script, and at the end a server is started through a blocking call like EventMachine::run(). In Node. js, there is no such start-the-event-loop call. Node. js simply enters the event loop after executing the input script. Node. js exits the event loop when there are no more callbacks to perform. This behavior is like browser JavaScript — the event loop is hidden from the user

HTTP is a first-class citizen in Node. js, designed with streaming and low latency in mind. This makes Node. js well suited for the foundation of a web library or framework

Node. js being designed without threads doesn't mean you can't take advantage of multiple cores in your environment. Child processes can be spawned by using our child_process.fork() API, and are designed to be easy to communicate with. Built upon that same interface is the cluster module, which allows you to share sockets between processes to enable load balancing over your cores

Node. js shines in real-time web apps that employ push technology over WebSocket. Node’s real-time, two-way connections—where the client and server can each initiate communication—enable the freer exchange of data

By

Tomislav Capan

Tomislav is an AWS Certified Solution Architect, developer, and technical consultant with more than 10 years of experience. Tomislav has a master’s degree in computing

CHIA SẺ

CHIA SẺ

Read the Spanish

Editor’s note. The English version of this article was updated on 10/03/2022 by our editorial team. It has been modified to include recent sources and to align with our current editorial standards

Sự phổ biến của JavaScript đã kéo theo rất nhiều thay đổi. Những điều chúng ta làm trên web ngày nay thật khó tưởng tượng chỉ vài năm trước

Trước khi chúng tôi tìm hiểu về Node. js (“Node”), hãy xem xét việc áp dụng JavaScript trên toàn bộ ngăn xếp để thống nhất ngôn ngữ và định dạng dữ liệu (JSON), sẽ tạo điều kiện thuận lợi cho việc sử dụng lại tài nguyên của nhà phát triển một cách tối ưu. Vì đây là một lợi ích của JavaScript hơn là Node. js cụ thể, chúng tôi sẽ không giải thích thêm

Với tất cả những ưu điểm của mình, Node. js đóng một vai trò quan trọng trong kho công nghệ của nhiều công ty nổi tiếng, những người phụ thuộc vào lợi ích độc đáo của nó. nút này. js giải quyết cách nhận ra những lợi thế này và lý do tại sao bạn có thể—hoặc có thể không—sử dụng Node. js

nút là gì. js?

Nút. js bao gồm công cụ JavaScript V8 của Google, lớp trừu tượng nền tảng libUV và thư viện cốt lõi được viết bằng JavaScript. Ngoài ra, Nút. js dựa trên ngăn xếp web mở (HTML, CSS và JS) và hoạt động trên cổng tiêu chuẩn 80

Nút. js cung cấp cho các nhà phát triển một công cụ toàn diện để làm việc trong mô hình I/O không chặn, hướng sự kiện. Ryan Dahl, người tạo ra Nút. js được “lấy cảm hứng từ các ứng dụng như Gmail” và—trong việc tạo Node. js—nhằm mục đích tạo các trang web thời gian thực với khả năng đẩy

Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng ta cũng có các ứng dụng web với kết nối hai chiều, thời gian thực

Tại sao nên sử dụng nút. js?

Nút. js tỏa sáng trong các ứng dụng web thời gian thực sử dụng công nghệ đẩy qua WebSocket. Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng ta cũng có các ứng dụng web với kết nối hai chiều, thời gian thực, trong đó cả máy khách và máy chủ đều có thể bắt đầu giao tiếp, cho phép chúng trao đổi dữ liệu tự do hơn. Điều này hoàn toàn trái ngược với mô hình phản hồi web điển hình, nơi khách hàng luôn bắt đầu giao tiếp

Người ta có thể lập luận rằng chúng ta đã có công nghệ này trong nhiều năm dưới dạng Flash và Java Applet. Tuy nhiên, trên thực tế, đó chỉ là những môi trường hộp cát sử dụng web làm giao thức vận chuyển để gửi đến máy khách. Ngoài ra, các Applet Flash và Java được chạy độc lập và thường hoạt động trên các cổng không chuẩn, có thể yêu cầu thêm quyền

Nút như thế nào. js Công việc?

Node thực sự tỏa sáng trong việc xây dựng các ứng dụng mạng nhanh, có khả năng mở rộng. Điều này là do khả năng xử lý một số lượng lớn các kết nối đồng thời với thông lượng cao

Nút. js sử dụng I/O không chặn, theo sự kiện để duy trì trọng lượng nhẹ và hiệu quả khi đối mặt với các ứng dụng thời gian thực sử dụng nhiều dữ liệu chạy trên các thiết bị phân tán

Nút. js là một nền tảng đáp ứng một nhu cầu cụ thể và hiểu điều này là vô cùng cần thiết. Ví dụ, bạn sẽ không sử dụng Node. js để thực hiện các hoạt động sử dụng nhiều CPU. Gần như tất cả các lợi thế của Node sẽ bị hủy bỏ nếu nó được sử dụng để tính toán nặng

Nút. js là một nền tảng đáp ứng nhu cầu cụ thể. Nó không phải là viên đạn bạc hay nền tảng sẽ thống trị thế giới phát triển web

tiếng riu ríu

Làm thế nào nút. js hoạt động bí mật thật thú vị. So với các kỹ thuật phục vụ web truyền thống trong đó mỗi kết nối (yêu cầu) tạo ra một luồng mới (chiếm RAM hệ thống và cuối cùng sử dụng tối đa dung lượng RAM có sẵn), Node. js hoạt động trên một luồng đơn, sử dụng lệnh gọi I/O không chặn. Điều này cho phép Node hỗ trợ hàng chục nghìn kết nối đồng thời được tổ chức trong vòng lặp sự kiện

Theo bài viết năm 2011 của Michael Abernethy “Node là gì. js?”, lấy một chuỗi có bộ nhớ 2 MB đi kèm, chạy trên hệ thống có RAM 8 GB và cung cấp tối đa theo lý thuyết là 4.000 kết nối đồng thời. Thêm vào đó là chi phí chuyển đổi ngữ cảnh giữa các luồng và bạn sẽ có một kịch bản phổ biến trong các kỹ thuật phục vụ web truyền thống. Nút. js tránh được tất cả điều này, đạt được mức khả năng mở rộng cao

Tất nhiên, có câu hỏi về việc chia sẻ một luồng duy nhất trong số tất cả các yêu cầu của khách hàng, một cạm bẫy tiềm ẩn khi viết Node. ứng dụng js

Đầu tiên, tính toán nặng nề có thể làm tắc nghẽn luồng đơn của Node và gây ra sự cố cho tất cả các máy khách, vì các yêu cầu đến bị chặn cho đến khi quá trình tính toán nói trên hoàn tất

Thứ hai, các nhà phát triển cần cảnh giác và ngăn chặn các ngoại lệ xuất hiện ở nút lõi (trên cùng). js, vì điều này sẽ khiến Node. js để chấm dứt, làm hỏng chương trình một cách hiệu quả

Để ngăn dòng ngoại lệ, chúng tôi chuyển lỗi trở lại trình gọi dưới dạng tham số gọi lại (thay vì "ném", như chúng tôi làm trong một số môi trường khác). Nếu một ngoại lệ chưa được xử lý xuất hiện, chúng ta có thể sử dụng mô-đun Forever hoặc các công cụ bên ngoài như upstart và monit và just upstart để theo dõi Nút. js và thực hiện khôi phục cần thiết cho một phiên bản bị lỗi. Lưu ý rằng những công cụ này không giải quyết việc khôi phục trạng thái hiện tại của phiên người dùng

npm. Trình quản lý gói nút

Hỗ trợ tích hợp để quản lý gói bằng npm được bao gồm trong mọi Nút. cài đặt js. Ý tưởng đằng sau các mô-đun npm tương tự như của Ruby Gems. Nó là một tập hợp các thành phần có sẵn công khai, có thể tái sử dụng, dễ dàng cài đặt thông qua kho lưu trữ trực tuyến, với quản lý phiên bản và phụ thuộc

npm Inc. chia sẻ danh sách các mô-đun được đóng gói cũng có thể truy cập thông qua công cụ npm CLI của nó. Hệ sinh thái mô-đun mở cho tất cả mọi người xuất bản mô-đun của riêng họ, mô-đun này sẽ được thêm vào kho lưu trữ npm

Một số mô-đun npm hữu ích bao gồm

thể hiện, thể hiện. js hoặc đơn giản là Express

Khung phát triển web lấy cảm hứng từ Sinatra cho Node. js và tiêu chuẩn thực tế cho phần lớn Node. ứng dụng js

hapi

Khung tập trung vào cấu hình mô-đun và dễ sử dụng để xây dựng các ứng dụng web và dịch vụ

liên kết

An extensible HTTP server framework for Node. js, providing a collection of high performance plugins known as middleware; serves as a base foundation for Express

ổ cắm. io và sockjs

Một thành phần phía máy chủ của hai thành phần WebSocket phổ biến

pug (trước đây là Jade)

Công cụ tạo khuôn mẫu lấy cảm hứng từ HAML, mặc định trong Express. js

mongodb và mongojs

Trình bao bọc MongoDB để cung cấp API cho cơ sở dữ liệu đối tượng MongoDB trong Node. js

làm lại

Thư viện máy khách Redis

lodash, gạch dưới, lười biếng. js

Vành đai tiện ích JavaScript. Underscore bắt đầu trò chơi nhưng bị lật đổ bởi một trong hai đối tác của nó, chủ yếu là do lười biếng. js' hiệu suất tốt hơn và triển khai mô-đun

mãi mãi

Một tiện ích để đảm bảo rằng tập lệnh nút đã cho chạy liên tục; . js xử lý trong quá trình sản xuất khi đối mặt với bất kỳ lỗi không mong muốn nào

chim xanh

Triển khai Promise/A+ đầy đủ tính năng với hiệu suất đặc biệt tốt

chốc lát. js

Thư viện ngày JavaScript để phân tích cú pháp, xác thực, thao tác và định dạng ngày

Where to Use Node. js

Chat

Chat is a typical real-time, multi-user application—from IRC (back in the day)—to modern implementations in Node. js with WebSocket

The chat application is lightweight, high traffic, and data intensive (but low processing/computation). It runs across distributed devices and is the sweet-spot example for Node. js

Simple, yet covering most of the paradigms you’ll ever use in a typical Node. js application, chat is a great use case for learning

Let’s depict how chat works. Say we have a single chat room where users can exchange messages in one-to-many (actually all) fashion. Let’s also say there are three users connected to our message board

On the server side, a simple Express. js application implements

1. A GET / request handler which serves the webpage containing a message board and a ‘Send’ button to initialize new message input, and
2. A WebSocket server that listens for new messages emitted by WebSocket clients

On the client side, we have an HTML page with a couple of handlers set up

1. A handler for the ‘Send’ button click event, which picks up the input message and sends it down the WebSocket
2. A handler that listens for new incoming messages on the WebSocket client (i. e. , user-originated messages that the server wants the client to display)

When a client posts a message, here’s what happens

1. The browser catches the ‘Send’ button click through a JavaScript handler. It picks up the value from the input field (i. e. , the message text), and emits a WebSocket message using the WebSocket client connected to our server (initialized on web page initialization)
2. The server-side component of the WebSocket connection receives the message and forwards it to all other connected clients, using the broadcast method
3. All clients receive the new message as a push message, via a WebSocket client-side component running within the web page. The clients then pick up the message content and update the web page in place, by appending the new message to the board

Here is a simple example of real-time chat with NodeJS, Socket. io and ExpressJS

For a more powerful solution, you might use a simple cache based on the Redis store. Or in an even more advanced solution, use a message queue to handle the routing of messages to clients, and a more robust delivery mechanism. The queue may cover for temporary connection losses or store messages for registered clients while they’re offline

Regardless of the solution you choose, Node. js operates under the same basic principles. reacting to events, handling many concurrent connections, and maintaining fluidity in the user experience

API on Top of an Object DB

Node. js is a natural fit for exposing the data from object DBs (e. g. , MongoDB). JSON-stored data allows Node. js to function without impedance mismatch and data conversion

For instance, if you’re using Rails, you would convert from JSON to binary models, then expose them back as JSON over the HTTP when the data is consumed by Backbone. js, Angular. js, etc. —or even plain jQuery AJAX calls. With Node. js, you can expose JSON objects with a REST API for the client to consume

If you are using MongoDB, you needn’t worry about converting between JSON and whatever else when reading or writing from the database. Thus, you can avoid the need for multiple conversions by using a uniform data serialization format across the client, server, and database

Đầu vào xếp hàng

Nút cho phép bạn linh hoạt đẩy việc xóa sổ cơ sở dữ liệu sang một bên. Nhưng thậm chí còn có nhiều lý do hơn để sử dụng Node. js

Nếu bạn đang nhận một lượng lớn dữ liệu đồng thời, cơ sở dữ liệu của bạn có thể trở thành nút cổ chai. Nút. js có thể dễ dàng xử lý các kết nối đồng thời. Bởi vì—trong trường hợp này—việc truy cập cơ sở dữ liệu là một thao tác ngăn chặn, nên chúng tôi gặp rắc rối. Giải pháp là thừa nhận hành vi của khách hàng trước khi dữ liệu thực sự được ghi vào cơ sở dữ liệu

Cách tiếp cận này cho phép hệ thống duy trì khả năng phản hồi khi tải nặng. It is particularly useful when the client doesn’t require firm confirmation of a successful data write, when logging or writing user-tracking data, processed in batches, to be used at a later time, or for operations that don’t need to be reflected instantly, like updating a Facebook “likes” count

Dữ liệu được xếp hàng đợi thông qua một số loại bộ nhớ đệm hoặc cơ sở hạ tầng xếp hàng tin nhắn như RabbitMQ hoặc ZeroMQ. Sau đó, nó được tiêu hóa bởi một quy trình ghi hàng loạt cơ sở dữ liệu riêng biệt hoặc dịch vụ phụ trợ xử lý tính toán chuyên sâu, được viết trên một nền tảng hoạt động tốt hơn cho tác vụ như vậy

In short. Với Node, bạn có thể đẩy việc ghi cơ sở dữ liệu sang một bên để xử lý sau

Data Streaming

Tại sao không sử dụng Nút. js trong truyền dữ liệu? . Chúng ta có thể sử dụng quan sát này để xây dựng một số Node thú vị. tính năng js

Ví dụ: chúng tôi có thể xử lý tệp trong khi chúng vẫn đang được tải lên. As data comes in through a stream, we can process it in parallel during that upload process. This is true for real-time audio or video encoding and proxying between various data sources

Proxy

Node. js is easily employed as a server-side proxy, where it can handle a large amount of simultaneous connections in a nonblocking manner. It’s useful for proxying different services with varying response times, or collecting data from multiple source points

As an example, let’s consider a server-side application communicating with third-party resources, pulling in data from different sources, or storing assets (like images and videos) to third-party cloud services

Using Node in place of a dedicated proxy server might be helpful if your proxying infrastructure is non-existent, or if you need a solution for local development. By this, I mean that you could build a client-side app with a Node. js development server for assets and proxying/stubbing API requests. In production, you’d handle such interactions with a dedicated proxy service (like nginx or HAProxy)

Brokerage/Stock Trader’s Dashboard

At the application level, brokers’ trading software is another example where desktop software dominates, but could be easily replaced with a real-time web solution. Brokers’ trading software tracks stock prices, performs calculations and technical analysis, and renders graphs and charts

Why not use Node. js to write a real-time web-based solution for brokers? Then, brokers could easily switch workstations or work locations. We may soon meet our brokers on the beach in Florida or Ibiza or Bali

Application Monitoring Dashboard

Imagine how you could grow your business if you could see what your visitors were doing in real time. With Node’s real-time, two-way sockets, you can gain this ability

Node with WebSocket fits perfectly for tracking website visitors and visualizing their interactions in real time

Reasons to use Node. js for a monitoring dashboard include gathering real-time stats from users, or introducing targeted interactions with your visitors by opening a communication channel at a specific point in your funnel. CANDDi productizes this idea

System Monitoring Dashboard

Now, let’s visit the infrastructure side of things. Imagine, for example, a SaaS provider that wants to offer users a service monitoring page, like GitHub’s status page. With Node. js’s event-loop, we can create a powerful web-based dashboard that checks services’ statuses in an asynchronous manner, pushing data to clients using WebSocket

Both internal (intracompany) and public services’ statuses can be reported live and in real time using this technology. Push a little further and try to imagine a network operations center (NOC) that monitors the applications of a telecommunications operator, cloud/network/hosting provider, or some financial institution. The applications would run on the open web stack backed by Node. js and WebSocket

Don’t try to build hard real-time systems in Node (i. e. , systems requiring consistent response times). Erlang is probably a better choice for that class of application

Where to Use Node. js, but Cautiously

Server-side Web Applications

With Node. js with Express. js, you can create classic web applications on the server side. While possible, this request-response paradigm in which Node. js would carry rendered HTML is not an ideal use case. There are arguments to be made for and against this approach. Here are some facts to consider

Pros

• You can significantly ease the development of an application that does not require CPU-intensive computation, by using Javascript to build it top to bottom, even down to the database level—if you use JSON storage Object DB (e. g. , MongoDB)
• Crawlers receive a fully rendered HTML response, which is far more SEO friendly than, say, a Single Page Application or a WebSocket app that runs on top of Node. js

Cons

• Any CPU-intensive computation will block Node. js responsiveness, so a threaded platform is a better approach. Alternatively, you could try scaling out the computation
• Using Node. js with a relational database can be painful. If you’re trying to perform relational operations, consider going with an environment such as Rails, Django, or ASP. Net MVC

An alternative to CPU-intensive computations is to create a highly scalable MQ-backed environment with back-end processing to keep Node as a front-facing “clerk” to handle client requests asynchronously

Where Not to Use Node. js

There are situations where Node may not be the best tool for the job

Server-side Web Application With a Relational Database Application

Ruby on Rails was once the clear choice as a tool to access relational databases like PostgreSQL, MySQL, and Microsoft SQL Server. This was because relational DB tools for Node. js were still in their early stages while, in contrast, Rails automatically provided data access setup right out of the box, together with DB schema migrations support tools, and other Gems (pun intended). Rails and its peer frameworks have mature and proven Active Record or Data Mapper data access layer implementations

It’s possible and not uncommon to use Node solely on the front end, while keeping your Rails back end with its easy access to a relational DB

But things have changed. Sequelize, TypeORM, and Bookshelf have come a long way toward becoming mature ORM solutions. It might also be worth checking out Join Monster if you’re looking to generate SQL from GraphQL queries

Heavy Server-side Computation and/or Processing

Node. js is not the best platform to handle heavy computation. No, you definitely don’t want to build a Fibonacci computation server in Node. js

In general, any CPU-intensive operation annuls all the throughput benefits Node offers with its event-driven, nonblocking I/O model. This is because incoming requests are blocked while the thread is occupied with your number-crunching—assuming you’re trying to run computations in the same Node instance used to respond to requests

Since Node. js is single-threaded and uses only a single CPU core, it would require considerable effort to develop a cluster module in order to deliver concurrency on a multicore server. Alternatively, you can run several Node. js server instances pretty easily behind a reverse proxy via nginx

With clustering, you should still offload all heavy computation to background processes. Ensure that you use an appropriate environment for the background processes, and that they communicate via a message queue server like RabbitMQ

While you may run background processes on the main server, this approach may not scale well once the load increases. You may distribute background processing services to separate worker servers without the need to configure the loads of front-facing web servers

With Node. js—as opposed to most other platforms—you enjoy that high reqs/sec throughput we talked about, as each request is a small task that Node handles quickly and efficiently

Why Choose Node. js?

We discussed Node. js from theory to practice, beginning with its purpose, and ending with its sweet spots and pitfalls

Các vấn đề với Node hầu như luôn bắt nguồn từ thực tế là các hoạt động ngăn chặn là gốc rễ của mọi tội ác—và 99% việc lạm dụng Node là hậu quả trực tiếp

Trong Node, các hoạt động ngăn chặn là gốc rễ của mọi tội ác—99% việc lạm dụng Node là hậu quả trực tiếp

tiếng riu ríu

Nếu trường hợp sử dụng của bạn không chứa các hoạt động sử dụng nhiều CPU, cũng như không truy cập các tài nguyên bị chặn, thì bạn có thể khai thác các lợi ích của Node. js and enjoy fast and scalable network applications. Chào mừng bạn đến với web thời gian thực

Understanding the basics

What is Node. js?

Node. js is a server-side, open-source, JavaScript runtime environment. Nút sử dụng công cụ V8 của Google---libUV---để cung cấp khả năng tương thích đa nền tảng và thư viện cốt lõi. Đáng chú ý, nút. js không hiển thị đối tượng cửa sổ chung vì nó không chạy trong trình duyệt

nút là gì. js dùng để làm gì?

Bởi vì nút. js là một luồng, chúng tôi sử dụng nó chủ yếu cho các máy chủ hướng sự kiện, không chặn. Chúng ta cũng có thể sử dụng Nút. js cho các trang web truyền thống và dịch vụ API back-end, vì nó được thiết kế với kiến ​​trúc dựa trên đẩy, thời gian thực

một khuôn khổ web là gì?

Các khung web như Angular và React là các thư viện giúp tổ chức và tạo mã mặt trước chạy trong trình duyệt web. Các khung web tái sử dụng mã cho các hoạt động chung, do đó giảm thời gian phát triển. Một số khung web là ngăn xếp đầy đủ

là nút. js là một khuôn khổ?

Không, nút. js là một môi trường. Các khung công tác back-end chạy trong Node. js. Các khung phổ biến, tương thích bao gồm Express. js (còn được gọi là Express) cho máy chủ HTTP và Socket. IO cho máy chủ WebSocket

là nút. js một ngôn ngữ lập trình?

Node. js không phải là ngôn ngữ lập trình. Các ". js" ở cuối tên của nó cho biết JavaScript là ngôn ngữ lập trình được liên kết với nó. Bất cứ thứ gì có thể dịch sang JavaScript---như TypeScript, Haxe hoặc CoffeeScript---cũng có thể được sử dụng với Node. js

Tại sao là nút. js phổ biến?

Bên cạnh hiệu quả cao, Node. js phổ biến vì hệ sinh thái dựa trên JavaScript khổng lồ, năng động, mã nguồn mở của nó

Sự khác biệt giữa nút là gì. js và Góc/AngularJS?

nút. js thực thi mã JavaScript trên máy chủ, trong khi đó Angular là một khung JavaScript được thực thi trên máy khách (i. e. , trong trình duyệt web)

Tại sao là nút. js xấu?

Nút. js không tệ. Công nghệ của nó được sử dụng rộng rãi cho nhiều loại máy chủ. Tuy nhiên, vì là đơn luồng nên Node. js không lý tưởng cho các máy chủ web gấp đôi máy chủ tính toán---việc tính toán nặng như vậy sẽ cản trở khả năng phản hồi của máy chủ

Thẻ

Người làm việc tự do? Tìm công việc tiếp theo của bạn.

Công việc lập trình viên JavaScript

Xem thông tin đầy đủ

Tomislav Capan

Kiến trúc sư giải pháp đám mây và nhà phát triển chính

Giới thiệu về tác giả

Tomislav là kỹ sư phần mềm, nhà tư vấn kỹ thuật và kiến ​​trúc sư giải pháp, người bắt đầu làm đối tác kỹ thuật cho một doanh nghiệp truyền thông trực tuyến, phát triển nó từ con số 0 lên hơn 100.000 độc giả hàng tháng. Sau nhiều năm làm việc trong lĩnh vực công nghệ phần mềm, giờ đây, anh ấy đảm nhận vai trò lãnh đạo kỹ thuật thông qua tư vấn và kiến ​​trúc các giải pháp đám mây năng động, đáng tin cậy và có thể mở rộng để hỗ trợ tăng trưởng kinh doanh và tối ưu hóa các kiến ​​trúc phức tạp bị trục trặc. Là người lãnh đạo cơ sở hạ tầng, anh ấy làm cho đám mây trở thành một nơi thân thiện

Thuê Tomislav

Bình luận

Chuột Anonymous

Đối với các DB quan hệ trên Nút, tôi thích http. // giá sáchjs. org/

Chuột Anonymous

Đối với các DB quan hệ trên Nút, tôi thích http. // giá sáchjs. org/

Adin Scannell

Awesome article. I definitely agree that node. js has some really perfectly suited use cases. However, I do want to comment on something that is a bit of a pet peeve of mine -- I wish you wouldn't contrast it with a non-existent straw-man "traditional" system in "how it works". 1) No server spawns a thread per request (they use thread pools or process pools). 2) You say "cost of context switching" as if it only applies to OS threads. Userspace frames need to be saved and loaded in the same way. Plus the OS does it with a few instructions, leveraging specialized support from the hardware -- which userspace can't do. 3) Similarly, userspace threads (I. e. frames or closures if you don't want to talk threads) take memory resources in the same way kernel threads do. It's not as if each system thread has it's full stack limit allocated, so that's an unfair analysis. Normal systems regularly have more than 4000 without coming anywhere near where you've pegged it. 4) The BIG problem with single-thread concurrency is the lack of parallelism. Sure, you can handle thousands of requests per second, but only one CPU on your 40 core server is going to doing ANY work. Anyways, all the above is in regard to a pretty minor paragraph in your excellent post. Node isn't really guilty of this, it's just that there's a lot of FUD out there around threads and processes which people often use to justify insane designs (and avoid threads when they are completely the right approach for the majority of situations)

Adin Scannell

Awesome article. I definitely agree that node. js has some really perfectly suited use cases. However, I do want to comment on something that is a bit of a pet peeve of mine -- I wish you wouldn't contrast it with a non-existent straw-man "traditional" system in "how it works". 1) No server spawns a thread per request (they use thread pools or process pools). 2) You say "cost of context switching" as if it only applies to OS threads. Userspace frames need to be saved and loaded in the same way. Plus the OS does it with a few instructions, leveraging specialized support from the hardware -- which userspace can't do. 3) Similarly, userspace threads (I. e. frames or closures if you don't want to talk threads) take memory resources in the same way kernel threads do. It's not as if each system thread has it's full stack limit allocated, so that's an unfair analysis. Normal systems regularly have more than 4000 without coming anywhere near where you've pegged it. 4) The BIG problem with single-thread concurrency is the lack of parallelism. Sure, you can handle thousands of requests per second, but only one CPU on your 40 core server is going to doing ANY work. Anyways, all the above is in regard to a pretty minor paragraph in your excellent post. Node isn't really guilty of this, it's just that there's a lot of FUD out there around threads and processes which people often use to justify insane designs (and avoid threads when they are completely the right approach for the majority of situations)

Eric Elliott

All your advice about computation heavy apps could not be more wrong. It's certainly true that attempting heavy computation inline with the request-response cycle, is a bad idea, but the same could be said of threaded environments. If you have CPU bound operations, it's a good idea to handle them with worker processes. JavaScript, and Node in particular are actually very well suited to handle distributed computation - especially with the good support for functional style programming. If you write your algorithms using pure functions and distribute workload to workers, you can easily distribute your workload over networked clusters. Node's great support for networking makes it an ideal environment both for computing and orchestration tasks, and it's orders of magnitude faster than Ruby at both

Eric Elliott

All your advice about computation heavy apps could not be more wrong. It's certainly true that attempting heavy computation inline with the request-response cycle, is a bad idea, but the same could be said of threaded environments. If you have CPU bound operations, it's a good idea to handle them with worker processes. JavaScript, and Node in particular are actually very well suited to handle distributed computation - especially with the good support for functional style programming. If you write your algorithms using pure functions and distribute workload to workers, you can easily distribute your workload over networked clusters. Node's great support for networking makes it an ideal environment both for computing and orchestration tasks, and it's orders of magnitude faster than Ruby at both

jim thomas

Very helpful. Cảm ơn rất nhiều

jim thomas

Very helpful. Cảm ơn rất nhiều

Roland

You certainly don't want to block any Node. js process that is handling server requests, but that doesn't mean you shouldn't do heavy computations behind a Node. máy chủ js. So long as the process doing the heavy computations is spawned asynchronously from your server process. Still you could end up blocking your Node. js process if you overdue it, but that is also true with the traditional threaded server

Roland

You certainly don't want to block any Node. js process that is handling server requests, but that doesn't mean you shouldn't do heavy computations behind a Node. máy chủ js. So long as the process doing the heavy computations is spawned asynchronously from your server process. Still you could end up blocking your Node. js process if you overdue it, but that is also true with the traditional threaded server

Danny Machal

This is going to make me out to be a giant noob but can you give me an example of a "blocking operation" ?

Danny Machal

This is going to make me out to be a giant noob but can you give me an example of a "blocking operation" ?

irneb

Any such hybrid system? I'm thinking. Use Node. js to process a request by simply placing it onto a to-process queue, return a message to the client stating something like "calculating. ". Then Node. js is free to continue with the next request. The to-process queue can then be run through using a difference thread (or even multiple threads). As and when these complete, they send their results to Node. js's queue which will then relay it back to the original client? Of course this means some ID key needs to accompany each item in this queue to ensure the correct data is returned to the correct client. Anything like this possible? Or even already implemented?

irneb

Any such hybrid system? I'm thinking. Use Node. js to process a request by simply placing it onto a to-process queue, return a message to the client stating something like "calculating. ". Then Node. js is free to continue with the next request. The to-process queue can then be run through using a difference thread (or even multiple threads). As and when these complete, they send their results to Node. js's queue which will then relay it back to the original client? Of course this means some ID key needs to accompany each item in this queue to ensure the correct data is returned to the correct client. Anything like this possible? Or even already implemented?

zivkovic_milan

Great article, thanks . )

zivkovic_milan

Great article, thanks . )

Gerd Jungbluth

Tomislav, thanks for this very well written and concise article. We 've been using MongoDB and Node. js (in combination with AngularJS for the user facing part) for > 2 years now and couldn't imagine to ever, ever, ever switch back to Flash (after 10 years of experience) or JEE / RDMS. So it boils down to just one programming language (JS), one data format (JSON) and one programming paradigma (Async), wow

Gerd Jungbluth

Tomislav, thanks for this very well written and concise article. We 've been using MongoDB and Node. js (in combination with AngularJS for the user facing part) for > 2 years now and couldn't imagine to ever, ever, ever switch back to Flash (after 10 years of experience) or JEE / RDMS. So it boils down to just one programming language (JS), one data format (JSON) and one programming paradigma (Async), wow

chad

That's by far the best explanation out there about Node. js. I finally understood that it is very useful (in certain scenarios) and not just a hype. Thanks a lot this was very informative

chad

That's by far the best explanation out there about Node. js. I finally understood that it is very useful (in certain scenarios) and not just a hype. Thanks a lot this was very informative

ellisgl

Node works well with relational databases, just don't use an ORM. SQL isn't that hard to learn. =)

ellisgl

Node works well with relational databases, just don't use an ORM. SQL isn't that hard to learn. =)

Tomislav Capan

True that, but I thought we as an industry got over the idea of writing all the SQL manually. Tools are good for common operations, tools that just get out of the way when needed to write some specifics manually, otherwise reducing the possibility of errors and security issues (that happens with more junior developers whether we want it or not)

Tomislav Capan

True that, but I thought we as an industry got over the idea of writing all the SQL manually. Tools are good for common operations, tools that just get out of the way when needed to write some specifics manually, otherwise reducing the possibility of errors and security issues (that happens with more junior developers whether we want it or not)

Tomislav Capan

Hi Adin, let me comment back 1) same scenario happens, there's a limitid amount of threads serving limited amount of clients. 2/3) Referenced presentation shows some measurements and numbers, you may be quite right on the internals but the common rough overview still stands as a general comparison of how things work between those two worlds. 4) parallelization options are also discussed within the article - as background worker processes, or several node processes behind a reverse proxy, or with Node clustering API (which is still in Experimental, but will be there eventually). Thanks for the great comments and the quality feedback on the article with that additional info, I appreciate it

Tomislav Capan

Hi Adin, let me comment back 1) same scenario happens, there's a limitid amount of threads serving limited amount of clients. 2/3) Referenced presentation shows some measurements and numbers, you may be quite right on the internals but the common rough overview still stands as a general comparison of how things work between those two worlds. 4) parallelization options are also discussed within the article - as background worker processes, or several node processes behind a reverse proxy, or with Node clustering API (which is still in Experimental, but will be there eventually). Thanks for the great comments and the quality feedback on the article with that additional info, I appreciate it

Tomislav Capan

Yes, you can have multiple worker processes, even communicating through Message Queue (MQ). Those workers can be separate Node processes (as node is single-threaded, unless you experiment with clustering API - I haven't tried yet as the API is very early and probably immmature), but can be any other language. I've worked on such a system which ran C# on Mono for background processing in a distributed CQRS architecture

Tomislav Capan

Yes, you can have multiple worker processes, even communicating through Message Queue (MQ). Those workers can be separate Node processes (as node is single-threaded, unless you experiment with clustering API - I haven't tried yet as the API is very early and probably immmature), but can be any other language. I've worked on such a system which ran C# on Mono for background processing in a distributed CQRS architecture

Tomislav Capan

Any calculation that keeps the CPU busy until the calculation is finished. Imagine some operation that requires 2 seconds to perform the calculation. Hit that with 100 clients - you get a 200-sec delay. Note the article I have referenced, which explains the blocking of the event loop. http. //zef. me/4561/node-js-and-the-case-of-the-blocked-event-loop

Tomislav Capan

Any calculation that keeps the CPU busy until the calculation is finished. Imagine some operation that requires 2 seconds to perform the calculation. Hit that with 100 clients - you get a 200-sec delay. Note the article I have referenced, which explains the blocking of the event loop. http. //zef. me/4561/node-js-and-the-case-of-the-blocked-event-loop

Tomislav Capan

Yes, that falls under the idea of having 'backend worker processes' in a distributed system. As the system is distributed, those workers can use any language/platform, including Node

Tomislav Capan

Yes, that falls under the idea of having 'backend worker processes' in a distributed system. As the system is distributed, those workers can use any language/platform, including Node

Tomislav Capan

Thanks for your feedback. I agree on that completely, for worker processes you could use JS when it fits, and that implies Node. js as that's what runs JS on the server, but you can also use other languages that do the particular work at hand fast

Tomislav Capan

Thanks for your feedback. I agree on that completely, for worker processes you could use JS when it fits, and that implies Node. js as that's what runs JS on the server, but you can also use other languages that do the particular work at hand fast

ellisgl

For ORMs in general, I just see them as a tool that can get something done quick for a newbie, but end up really gumming up the works later on. The closest thing I use for an ORM is a PDO wrapper (which I borrowed and rewrote from an old co-worker), that helps with writing PDO statements. https. //github. com/ellisgl/GeekLab-XPDO

ellisgl

For ORMs in general, I just see them as a tool that can get something done quick for a newbie, but end up really gumming up the works later on. The closest thing I use for an ORM is a PDO wrapper (which I borrowed and rewrote from an old co-worker), that helps with writing PDO statements. https. //github. com/ellisgl/GeekLab-XPDO

Adin Scannell

Apologies for the wall of text. Excellent discussion. 1) Agreed. But threads and processes are powerful tools. That's why a hybrid of threads/processes and event systems typically does best in the real world. Like the much beloved nginx . ) 2/3) Sorry, I may not have been clear. When I said FUD regarding threads and processes, I *meant the referenced presentation*. It's just a bunch of specifically tailored microbenchmarks designed to prove a certain point. (Which is fair, given that it's a lightning fair and can be a bit polemic. In fact, it's a great talk. But these synthetic micro-benchmarks are not the basis for a fair and through comparison. ) To say the difference between nginx and apache benchmarks is purely because of context switching is an extreme oversimplification. Nginx is specifically designed to serve HTTP requests really, really quickly in common circumstances (IMO generally by a tight coupling with the latest OS event systems, etc. ). You could specifically measure the overhead of context switching, and I would wager it's trivial. 4) But then aren't you at the mercy of the horrible "process overhead" the referenced presentation talks about -- can't have it both ways . ) (To be clear, my position using threads/processes or whatever is not in and of itself a problem. There are way more important design factors there, the OS overhead of those entities is pretty trivial. Hence I hate it when people adopt a silly design based on the idea thread-are-bad or processes-are-bad or some other such nonesense)

Adin Scannell

Apologies for the wall of text. Excellent discussion. 1) Agreed. But threads and processes are powerful tools. That's why a hybrid of threads/processes and event systems typically does best in the real world. Like the much beloved nginx . ) 2/3) Sorry, I may not have been clear. When I said FUD regarding threads and processes, I *meant the referenced presentation*. It's just a bunch of specifically tailored microbenchmarks designed to prove a certain point. (Which is fair, given that it's a lightning fair and can be a bit polemic. In fact, it's a great talk. But these synthetic micro-benchmarks are not the basis for a fair and through comparison. ) To say the difference between nginx and apache benchmarks is purely because of context switching is an extreme oversimplification. Nginx is specifically designed to serve HTTP requests really, really quickly in common circumstances (IMO generally by a tight coupling with the latest OS event systems, etc. ). You could specifically measure the overhead of context switching, and I would wager it's trivial. 4) But then aren't you at the mercy of the horrible "process overhead" the referenced presentation talks about -- can't have it both ways . ) (To be clear, my position using threads/processes or whatever is not in and of itself a problem. There are way more important design factors there, the OS overhead of those entities is pretty trivial. Hence I hate it when people adopt a silly design based on the idea thread-are-bad or processes-are-bad or some other such nonesense)

Tomislav Capan

Everything always needs to be put in the right context. I have presented possible situations, to analyze each one deeply I'd need a book . -) Still, I really appreciate your comments and insights, they are valuable addition to the article. Thank you for those

Tomislav Capan

Everything always needs to be put in the right context. I have presented possible situations, to analyze each one deeply I'd need a book . -) Still, I really appreciate your comments and insights, they are valuable addition to the article. Thank you for those

Aaron Wang

When use node. js as api server, and the back-end db is the bottleneck, if the clients are the other applications, not user interface, can we just let these client requests hang there waiting for db operation complete(sine node. js can handle massive concurrent connections easily)? Is a MQ necessary in this scenario? In my opinion, node. js is right the queue

Aaron Wang

When use node. js as api server, and the back-end db is the bottleneck, if the clients are the other applications, not user interface, can we just let these client requests hang there waiting for db operation complete(sine node. js can handle massive concurrent connections easily)? Is a MQ necessary in this scenario? In my opinion, node. js is right the queue

Ethan

ORM does not exist to make query languages "easier", it's a tool used to encapsulate database concerns, isolating them from the application. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. Excuse the tangent, nothing to do with node

Ethan

ORM does not exist to make query languages "easier", it's a tool used to encapsulate database concerns, isolating them from the application. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. Excuse the tangent, nothing to do with node

Eric Elliott

Yes, you could, but Ruby would be a poor choice if your aim is performance. =)

Eric Elliott

Yes, you could, but Ruby would be a poor choice if your aim is performance. =)

Vedran

thank you for a great article. By using the node. js child process http. //nodejs. org/api/child_process. html - would you be able to overcome the high computational blocking Fibonacci issue?

Vedran

thank you for a great article. By using the node. js child process http. //nodejs. org/api/child_process. html - would you be able to overcome the high computational blocking Fibonacci issue?

nene odonkor

any real life examples?

nene odonkor

any real life examples?

nene odonkor

What of the Facebook example you used. When a user clicks on the like button there is an immediate acknowledgement but the data is written later. Cant that be an example of node used with relational db? Anyway what makes up the message queue?

nene odonkor

What of the Facebook example you used. When a user clicks on the like button there is an immediate acknowledgement but the data is written later. Cant that be an example of node used with relational db? Anyway what makes up the message queue?

Moch Lutfi

Maybe go-lang is alternative choice. . )

Moch Lutfi

Maybe go-lang is alternative choice. . )

Anthony Hildoer

This article is great, except for the part where it says don't use NodeJS for computation because it doesn't have threads. Since when do we need threads? Run child processes. Ưu điểm duy nhất để chạy các luồng trên các tiến trình con là bộ nhớ dùng chung. Lần trước tôi đã kiểm tra, bất kỳ hệ thống nào đủ lớn để toàn bộ cuộc tranh luận này có liên quan dù sao cũng sẽ trải rộng trên nhiều máy chủ, bằng cách vô hiệu hóa bất kỳ lợi ích nào của các luồng. So, get it out of your head that NodeJS can't do CPU intensive work. And, if you can't, contact BlueRival. com, and we can fix all the stuff you built wrong with NodeJS

Anthony Hildoer

This article is great, except for the part where it says don't use NodeJS for computation because it doesn't have threads. Since when do we need threads? Run child processes. Ưu điểm duy nhất để chạy các luồng trên các tiến trình con là bộ nhớ dùng chung. Lần trước tôi đã kiểm tra, bất kỳ hệ thống nào đủ lớn để toàn bộ cuộc tranh luận này có liên quan dù sao cũng sẽ trải rộng trên nhiều máy chủ, bằng cách vô hiệu hóa bất kỳ lợi ích nào của các luồng. So, get it out of your head that NodeJS can't do CPU intensive work. And, if you can't, contact BlueRival. com, and we can fix all the stuff you built wrong with NodeJS

RiggerTheGeek

One application that few people use, but could be really fanastic, is using NodeJS to build a desktop application. There's plenty of packages out there - personally, I favour Node-Webkit https. //github. com/rogerwang/node-webkit

RiggerTheGeek

One application that few people use, but could be really fanastic, is using NodeJS to build a desktop application. There's plenty of packages out there - personally, I favour Node-Webkit https. //github. com/rogerwang/node-webkit

hfuti

Hi, nice article. However I would like to point one thing, NodeJS is not running in a single thread. The programmer doesn't have to spawn new threads, they are handled by node itself on event basis. NodeJS is evented, each function call per event will run in a separate thread. That approach encourages writing lighter functions. If your function does a lot of computation, reactor it into smaller ones and they all will run in separate threads. Think about the example where you process file while streaming. That is possible thanks to threads

hfuti

Hi, nice article. However I would like to point one thing, NodeJS is not running in a single thread. The programmer doesn't have to spawn new threads, they are handled by node itself on event basis. NodeJS is evented, each function call per event will run in a separate thread. That approach encourages writing lighter functions. If your function does a lot of computation, reactor it into smaller ones and they all will run in separate threads. Think about the example where you process file while streaming. That is possible thanks to threads

Matthew Keas

This is very well written. Thank you for this

Matthew Keas

This is very well written. Thank you for this

Matti Schneider

> The technique used to avoid exceptions bubbling up to the surface is passing errors back to the caller as callback parameters Excuse me, but that seems misled. In my understanding, [“Node-style callbacks”](http. //nodeguide. com/style. html#callbacks) (i. e. the pattern of passing errors as the first param to callbacks) are a side-effect of the event queue (returning control as soon as possible to allow for “concurrency”) itself rather than a design to avoid interrupting flow. The fact that exceptions do not bubble are actually quite often a source of errors, especially to newcomers

Matti Schneider

> The technique used to avoid exceptions bubbling up to the surface is passing errors back to the caller as callback parameters Excuse me, but that seems misled. In my understanding, [“Node-style callbacks”](http. //nodeguide. com/style. html#callbacks) (i. e. the pattern of passing errors as the first param to callbacks) are a side-effect of the event queue (returning control as soon as possible to allow for “concurrency”) itself rather than a design to avoid interrupting flow. The fact that exceptions do not bubble are actually quite often a source of errors, especially to newcomers

kyoukhana

Great Article. Wondering who made the beautiful diagrams . )

kyoukhana

Great Article. Wondering who made the beautiful diagrams . )

TZ

Great article, thanks . ) BTW, which tool do you use to draw the images?

TZ

Great article, thanks . ) BTW, which tool do you use to draw the images?

Matthew Keas

+1 for that

Matthew Keas

+1 for that

Matthew Keas

For those that are curious, it seems the images were created with Adobe Photoshop CC. I checked this by looking at the EXIF data of one of the images. http. //exifdata. com/ File Size – 61 kB File Type – PNG MIME Type – image/png Image Width – 624 Image Height – 600 X Resolution – 72 Y Resolution – 72 Color Space – sRGB Color Mode – 3 Compression – Deflate/Inflate Orientation – Horizontal (normal) XMP Toolkit – Adobe XMP Core 5. 5-c014 79. 151481, 2013/03/13-12. 09. 15 Creator Tool – Adobe Photoshop CC (Macintosh)

Matthew Keas

For those that are curious, it seems the images were created with Adobe Photoshop CC. I checked this by looking at the EXIF data of one of the images. http. //exifdata. com/ File Size – 61 kB File Type – PNG MIME Type – image/png Image Width – 624 Image Height – 600 X Resolution – 72 Y Resolution – 72 Color Space – sRGB Color Mode – 3 Compression – Deflate/Inflate Orientation – Horizontal (normal) XMP Toolkit – Adobe XMP Core 5. 5-c014 79. 151481, 2013/03/13-12. 09. 15 Creator Tool – Adobe Photoshop CC (Macintosh)

Juan G. Nuño

Also, the fact that javascript is not able to check type compliance introduces dificulty in expontaneous organization of huge number of coders updating the same codebase simultaneously

Juan G. Nuño

Also, the fact that javascript is not able to check type compliance introduces dificulty in expontaneous organization of huge number of coders updating the same codebase simultaneously

Juan G. Nuño

mmmm. disagree, if you use correctly a good ORM (take a look at Mature ORMs) you get also a distributed cache of your Relational Database that allows you more performance for the same bucks and more scalability of your sistem. ORM is not just for easing the life to newies. It is non sense to use a non-blockin sistem such as node. js, if at the end you get blocked at your Database. But using a ORM that way, is not for newbies

Juan G. Nuño

mmmm. disagree, if you use correctly a good ORM (take a look at Mature ORMs) you get also a distributed cache of your Relational Database that allows you more performance for the same bucks and more scalability of your sistem. ORM is not just for easing the life to newies. It is non sense to use a non-blockin sistem such as node. js, if at the end you get blocked at your Database. But using a ORM that way, is not for newbies

geniium

Glad you mention, most people don't mention this

geniium

Glad you mention, most people don't mention this

Tracker1

For that matter, since you can do an async shell to a console application, you could easily write your worker in, for instance golang, and then use a generic pool to limit your cpu workers. from there, you can shell out to a more efficient worker. You can also do that for CPU intensive JS as well, I did this for my scrypt-js module (there are binary modules that are more performant, but I wanted one without compiled dependencies). It's not that hard to queue work to other systems, and no reason node can't be used to orchestrate said work

Tracker1

For that matter, since you can do an async shell to a console application, you could easily write your worker in, for instance golang, and then use a generic pool to limit your cpu workers. from there, you can shell out to a more efficient worker. You can also do that for CPU intensive JS as well, I did this for my scrypt-js module (there are binary modules that are more performant, but I wanted one without compiled dependencies). It's not that hard to queue work to other systems, and no reason node can't be used to orchestrate said work

Tracker1

Could *could* use an intermediate system such as TypeScript, you can also use a linter (jshint) and even require a level of test coverage in order for release. Getting 100% test coverage is generally *very* easy in scripted environments. Would suggest looking into Mocha, Chai, and Proxyquire. If you aren't writing unit tests, type safety really doesn't give you much

Tracker1

Could *could* use an intermediate system such as TypeScript, you can also use a linter (jshint) and even require a level of test coverage in order for release. Getting 100% test coverage is generally *very* easy in scripted environments. Would suggest looking into Mocha, Chai, and Proxyquire. If you aren't writing unit tests, type safety really doesn't give you much

Steve Naidamast

I am beginning to find Node. js quite interesting. However, the paradigm it appears to be promoting is hardly new to IT. In the mainframe communications world we called such capabilities, "re-entrant", where a single process could handle a high level of calls to it. Microsoft implemented similar capabilities with its Singleton object infrastructure and I imagine the Java world has done similar implementations. Oddly enough, the Microsoft recommendation for enhancing scalability across the wires to back-end services was to promote the "Single Call" object structure or one object instance per calling request. Thus, the argument made for Node. js is actually contrary to the Microsoft recommendation; BTW, a recommendation I never quite understood. In any event, as a business ASP. NET developer, I am not sure if I would find any use for a Node. js implementation, though our web designer may. On another note, I would like to add my own opinion on the use of ORMs. ORMs are great tools when faced with an existing database structure against the requirements of a new application as the ORM can handle a lot of the mundane, repetitive coding that is usually found with any database application. However, because ORMs are high-level layers, they are usually not the most efficient options to use against databases whereas direct access through native providers are. In many respects, better to do the repetitive coding for efficiency over applying a heavy-weight interim layer such as an ORM

Steve Naidamast

I am beginning to find Node. js quite interesting. However, the paradigm it appears to be promoting is hardly new to IT. In the mainframe communications world we called such capabilities, "re-entrant", where a single process could handle a high level of calls to it. Microsoft implemented similar capabilities with its Singleton object infrastructure and I imagine the Java world has done similar implementations. Oddly enough, the Microsoft recommendation for enhancing scalability across the wires to back-end services was to promote the "Single Call" object structure or one object instance per calling request. Thus, the argument made for Node. js is actually contrary to the Microsoft recommendation; BTW, a recommendation I never quite understood. In any event, as a business ASP. NET developer, I am not sure if I would find any use for a Node. js implementation, though our web designer may. On another note, I would like to add my own opinion on the use of ORMs. ORMs are great tools when faced with an existing database structure against the requirements of a new application as the ORM can handle a lot of the mundane, repetitive coding that is usually found with any database application. However, because ORMs are high-level layers, they are usually not the most efficient options to use against databases whereas direct access through native providers are. In many respects, better to do the repetitive coding for efficiency over applying a heavy-weight interim layer such as an ORM

opensas

Very interesting observation. I'd like someone to elaborate a bit more on that. I would like a more concrete example, like some piece of concrete code calling an async heavy-computational function, and someone explaining what happens if that is run in a multicore equipment. Does the thread that was sercing http requests gets blocked? Or another thread is used for that?

opensas

Very interesting observation. I'd like someone to elaborate a bit more on that. I would like a more concrete example, like some piece of concrete code calling an async heavy-computational function, and someone explaining what happens if that is run in a multicore equipment. Does the thread that was sercing http requests gets blocked? Or another thread is used for that?

Derrick Simpson

Node is terrible as a web server. Even the creator suggests that this is not what Node is intended for, and that it should be leveraged for it's strengths. JavaScript "Everything", just like worker processes, is ludicrous

Derrick Simpson

Node is terrible as a web server. Even the creator suggests that this is not what Node is intended for, and that it should be leveraged for it's strengths. JavaScript "Everything", just like worker processes, is ludicrous

Eric Elliott

This is ridiculous. Node was built with the web as first class, and it excels as a web server. It is rapidly replacing Ruby and PHP in many enterprise organizations because it has demonstrably boosted both application performance (reduced page-load times, etc. ) and developer productivity

Eric Elliott

This is ridiculous. Node was built with the web as first class, and it excels as a web server. It is rapidly replacing Ruby and PHP in many enterprise organizations because it has demonstrably boosted both application performance (reduced page-load times, etc. ) and developer productivity

jonpress

You can in fact create multi-threaded servers using Node. js to offer more stable performance but it does take a lot of extra work (see the built-in cluster module and the child_process module). I have created a framework which runs on multiple CPU cores and solves much of the issues discussed in this post. Check it out. http. //nombo. io/

jonpress

You can in fact create multi-threaded servers using Node. js to offer more stable performance but it does take a lot of extra work (see the built-in cluster module and the child_process module). I have created a framework which runs on multiple CPU cores and solves much of the issues discussed in this post. Check it out. http. //nombo. io/

Connor Leech

does something like mongoose. js solve the node relational database issue? http. //mongoosejs. com/

Connor Leech

does something like mongoose. js solve the node relational database issue? http. //mongoosejs. com/

Rob Tweed

Có - xem cách tiếp cận nhóm công nhân hàng đợi/phân nhánh trước được EWD áp dụng. js. http. //gradvs1. mgateway. com/download/EWDjs. pdf Summarised here. http. //gradvs1. mgateway. com/download/EWDjsMechanics. pdf

Rob Tweed

Có - xem cách tiếp cận nhóm công nhân hàng đợi/phân nhánh trước được EWD áp dụng. js. http. //gradvs1. mgateway. com/download/EWDjs. pdf Summarised here. http. //gradvs1. mgateway. com/download/EWDjsMechanics. pdf

keith

yeah, I was wondering about it too. great visual + awesome post

keith

yeah, I was wondering about it too. great visual + awesome post

Carlos Ballena

Very helpful article

Carlos Ballena

Very helpful article

Jesus Nuñez

npm install felixge/node-mysql. That might be the most useful repository I've seen in ages

Jesus Nuñez

npm install felixge/node-mysql. That might be the most useful repository I've seen in ages

Matthias Lienau

Nice article, indeed. But, @hfuti. disqus, you're wrong in saying "NodeJS is not running in a single thread . each function call per event will run in a separate thread. " As far as I understood, the main NodeJS event loop consuming your JS code in fact runs in a single thread. All potentially blocking and/or long-running tasks like disk I/O is delegated to and executed by libuv as part of the node runtime engine which spawns a *limited* number of threads made available as thread pool. Said this, it's obvious that the main event loop thread is not affected or blocked by other (yet again asynchronous) code execution. So, for example, file I/O with the fs module itself is implemented in a non-blocking manner - in the end as good as the OS/kernel allows non-blocking operations. Of course foreign processes or threads could always be spawned by custom modules or 3rd party services (worker processes). And yes, there are runtime env projects handling more than one node process and their threads on the same machine or cpu cluster. But that's another story. Feel free to correct me if I'm wrong

Matthias Lienau

Nice article, indeed. But, @hfuti. disqus, you're wrong in saying "NodeJS is not running in a single thread . each function call per event will run in a separate thread. " As far as I understood, the main NodeJS event loop consuming your JS code in fact runs in a single thread. All potentially blocking and/or long-running tasks like disk I/O is delegated to and executed by libuv as part of the node runtime engine which spawns a *limited* number of threads made available as thread pool. Said this, it's obvious that the main event loop thread is not affected or blocked by other (yet again asynchronous) code execution. So, for example, file I/O with the fs module itself is implemented in a non-blocking manner - in the end as good as the OS/kernel allows non-blocking operations. Of course foreign processes or threads could always be spawned by custom modules or 3rd party services (worker processes). And yes, there are runtime env projects handling more than one node process and their threads on the same machine or cpu cluster. But that's another story. Feel free to correct me if I'm wrong

josep2

This is fantastic

josep2

This is fantastic

Jacopo Chiapparino

Nice article, thank you

Jacopo Chiapparino

Nice article, thank you

NoobMovies. com

I think Django still kicks Node's ass

NoobMovies. com

I think Django still kicks Node's ass

Alex Writing

Hey Tomislav, http. //codecondo. com/7-minimal-node-js-web-frameworks/ I'd love if you could add the above post to the list . )

Alex Writing

Hey Tomislav, http. //codecondo. com/7-minimal-node-js-web-frameworks/ I'd love if you could add the above post to the list . )

Victor Lava

Omg, this is amazing. I have always wanted to learn node. js

Victor Lava

Omg, this is amazing. I have always wanted to learn node. js

ak

Thanks for providing examples, illustrations and use cases. The detailed explanation and steps in some cases with relevant resources makes it a great read. Where nodejs *should* be used is very useful

ak

Thanks for providing examples, illustrations and use cases. The detailed explanation and steps in some cases with relevant resources makes it a great read. Where nodejs *should* be used is very useful

crueber

All Node code is thread-bound. It may not run on the same thread at all times (which has nothing to do with Node itself, and instead has to do with the operating system process scheduler), but it is thread bound. In order to take advantage of multiple threads, you need to use something like Cluster. http. //nodejs. org/api/cluster. html

crueber

All Node code is thread-bound. It may not run on the same thread at all times (which has nothing to do with Node itself, and instead has to do with the operating system process scheduler), but it is thread bound. In order to take advantage of multiple threads, you need to use something like Cluster. http. //nodejs. org/api/cluster. html

crueber

Agreed. I use Postgres for all sorts of GIS operations in an application I've been working on for about a year, and it works great, and benefits from the same non-blocking I/O that any other database access does. It's just that you have to drop down directly to the SQL. There are a couple ORMs, but nothing that is real mature

crueber

Agreed. I use Postgres for all sorts of GIS operations in an application I've been working on for about a year, and it works great, and benefits from the same non-blocking I/O that any other database access does. It's just that you have to drop down directly to the SQL. There are a couple ORMs, but nothing that is real mature

elijahca

Awesome, thanks a lot for this

elijahca

Awesome, thanks a lot for this

Zmirc

Minor comment. don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things

Zmirc

Minor comment. don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things

Gianlucca

i agree, good post

Gianlucca

i agree, good post

Gianlucca

yes, i agree

Gianlucca

yes, i agree

Gianlucca

sure

Gianlucca

sure

Toulon

Very well written article. You put a lot of thought into it. Quick node/express question I am I am adding rapid data entry, not batch, data entry to my system I have a form (mfntapes) that works great. I have a test form (joe) the prompts for the number of times I want to call the mfntapes form The gist contains the code, fails to work, the after prompting for cnt attempts to call for mfntapes cnt times. Error is "ReferenceError. form is not defined" in line 87 of the gist The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of https. //gist. github. com/toulon/9571625

Toulon

Very well written article. You put a lot of thought into it. Quick node/express question I am I am adding rapid data entry, not batch, data entry to my system I have a form (mfntapes) that works great. I have a test form (joe) the prompts for the number of times I want to call the mfntapes form The gist contains the code, fails to work, the after prompting for cnt attempts to call for mfntapes cnt times. Error is "ReferenceError. form is not defined" in line 87 of the gist The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of https. //gist. github. com/toulon/9571625

Jesus Bejarano

ORM for real projects are useless hone

Jesus Bejarano

ORM for real projects are useless hone

Thomas

Nice article . -) > SERVER-SIDE WEB APPLICATION W/ A RELATIONAL DB BEHIND I wonder why Node is not good for that? You have promise based *SQL libraries (like Knex) which enables non-blocking queries. Node has no opposition with relational databases. it has no interest with blocking I/O drivers only. Relational or not relational

Thomas

Nice article . -) > SERVER-SIDE WEB APPLICATION W/ A RELATIONAL DB BEHIND I wonder why Node is not good for that? You have promise based *SQL libraries (like Knex) which enables non-blocking queries. Node has no opposition with relational databases. it has no interest with blocking I/O drivers only. Relational or not relational

Seb

I wish NodeJS was not (almost) systematicallty presented as THE de facto alternative to the traditional threaded webserver. Async IO is not exclusive to NodeJS. Most major languages out there - including Java and PHP - have async IO frameworks similar to NodeJS. This wiki page lists most of them. http. //en. wikipedia. org/wiki/Reactor_pattern I'm not saying NodeJS doesn't have its merit, but I'm sick and tired of seeing people flocking to it as if it's the *only* async IO stack available, and the *only* alternative to the good ol' PHP or Rails stack. To be honest, we may be stuck with Javascript on the browser, and will be for a very long time (except if Javascript becomes just another target platform/language thanks to asm. js), but I can't come up with any good reason to use it on the server side in favor to other available languages. Most of the alternatives are just way better as a language, have better standard libraries, tools and resources. Just a personal opinion. Long story short, Node JS is cool, but there certainly is a similar framework written in your favorite language. Please just take 5 minutes to research it before switching to NodeJS

Seb

I wish NodeJS was not (almost) systematicallty presented as THE de facto alternative to the traditional threaded webserver. Async IO is not exclusive to NodeJS. Most major languages out there - including Java and PHP - have async IO frameworks similar to NodeJS. This wiki page lists most of them. http. //en. wikipedia. org/wiki/Reactor_pattern I'm not saying NodeJS doesn't have its merit, but I'm sick and tired of seeing people flocking to it as if it's the *only* async IO stack available, and the *only* alternative to the good ol' PHP or Rails stack. To be honest, we may be stuck with Javascript on the browser, and will be for a very long time (except if Javascript becomes just another target platform/language thanks to asm. js), but I can't come up with any good reason to use it on the server side in favor to other available languages. Most of the alternatives are just way better as a language, have better standard libraries, tools and resources. Just a personal opinion. Long story short, Node JS is cool, but there certainly is a similar framework written in your favorite language. Please just take 5 minutes to research it before switching to NodeJS

Jarle Leopold Moe

Làm thế nào bạn sẽ tải lên các tập tin? . Node. js is _single-threaded_ it's only applicable for certain types of tasks

Jarle Leopold Moe

Làm thế nào bạn sẽ tải lên các tập tin? . Node. js is _single-threaded_ it's only applicable for certain types of tasks

Eric Elliott

These are great examples of why Node is so much better than the competition at web services. Không ai trong số đó đang chặn hoạt động trong Node. Chúng không đồng bộ. Trong khi các máy chủ khác lãng phí tài nguyên khi chạy các luồng riêng biệt, Node kích hoạt hoạt động không đồng bộ theo hướng sự kiện và tiếp tục nhận nhiều yêu cầu hơn trong thời gian chờ đợi. The practical upshot is that porting web services from PHP or Ruby can deliver between 2x and 10x improvements in simultaneous connections and typically 30% - 60% improvements in average response times. Lots of big companies are doing web Node projects just for these reasons, including Adobe, Paypal, eBay, Walmart, Yahoo. , Groupon, Uber, etc

Eric Elliott

These are great examples of why Node is so much better than the competition at web services. Không ai trong số đó đang chặn hoạt động trong Node. Chúng không đồng bộ. Trong khi các máy chủ khác lãng phí tài nguyên khi chạy các luồng riêng biệt, Node kích hoạt hoạt động không đồng bộ theo hướng sự kiện và tiếp tục nhận nhiều yêu cầu hơn trong thời gian chờ đợi. The practical upshot is that porting web services from PHP or Ruby can deliver between 2x and 10x improvements in simultaneous connections and typically 30% - 60% improvements in average response times. Lots of big companies are doing web Node projects just for these reasons, including Adobe, Paypal, eBay, Walmart, Yahoo. , Groupon, Uber, etc

jenit shah

very nice article and very clear thought regarding node. js where to use and where not

jenit shah

very nice article and very clear thought regarding node. js where to use and where not

CowsRule

Every major application development platform has already had support for HTML5 for the past several years, including websockets for bi-directional communication. Add to this the strong types, multi-threading and the tons of other stuff that languages such as Java have to offer and I seriously question why anyone would waste their time using this

CowsRule

Every major application development platform has already had support for HTML5 for the past several years, including websockets for bi-directional communication. Add to this the strong types, multi-threading and the tons of other stuff that languages such as Java have to offer and I seriously question why anyone would waste their time using this

robertcooke

Just want to mention that node is not the only server side option for javascript especially since oracle put the nashorn javascript engine on the jdk. Now you can also use all the jvm goodness from javascript we are using vert. x as the async server and nashorn to use javascript. You can see some code samples in this module https. //github. com/core9/module-nashorn trang web dự án là core9. io

robertcooke

Just want to mention that node is not the only server side option for javascript especially since oracle put the nashorn javascript engine on the jdk. Now you can also use all the jvm goodness from javascript we are using vert. x as the async server and nashorn to use javascript. You can see some code samples in this module https. //github. com/core9/module-nashorn trang web dự án là core9. io

Anonymous

This is an amazing overview . Thank you

Anonymous

This is an amazing overview . Thank you

Vishnu Tekale

Very well written. Thanks for sharing

Vishnu Tekale

Very well written. Thanks for sharing

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. calepin. co/why-node-is-different. html

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. calepin. co/why-node-is-different. html

FluckerSputter

Just to let you know you have "support support" in How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node. js operates on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connections (held in the event loop)

FluckerSputter

Just to let you know you have "support support" in How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node. js operates on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connections (held in the event loop)

piloh23

Node. js will never replace Rails as the number one web framework

piloh23

Node. js will never replace Rails as the number one web framework

Alifa Nurani Putri

Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?

Alifa Nurani Putri

Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?

SleightDifference

How come PHP isn't mentioned for interacting with relational databases? It's as if PHP isn't used anymore? Why is it being neglected?

SleightDifference

How come PHP isn't mentioned for interacting with relational databases? It's as if PHP isn't used anymore? Why is it being neglected?

Clain Dsilva

Thanks for taking time to explain Node. js. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Clain Dsilva

Thanks for taking time to explain Node. js. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Cezar Luiz

What about this https. //github. com/felixge/node-mysql? Nice article. Thanks

Cezar Luiz

What about this https. //github. com/felixge/node-mysql? Nice article. Thanks

Marcelo Lima

Thank you for this article. Cleared a lot of questions I had about Node internals

Marcelo Lima

Thank you for this article. Cleared a lot of questions I had about Node internals

Navid

Awesome Article

Navid

Awesome Article

Abdelhakim

https. //www. udemy. com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 1. Lifetime access to 24 lectures 2. Over 120 mins of high quality content. 2. Join to a community of over 2687 students learning together. 4. Course information and regular updates 5. Learn node. js and mongoDB from scratch by examples. 6. Course information and regular updates. 7. Discussion forum, which we encourage you to make use of -- both to pose questions about the material to the course instructor and to exchange ideas with your classmates. 8. High quality course support

Abdelhakim

https. //www. udemy. com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 1. Lifetime access to 24 lectures 2. Over 120 mins of high quality content. 2. Join to a community of over 2687 students learning together. 4. Course information and regular updates 5. Learn node. js and mongoDB from scratch by examples. 6. Course information and regular updates. 7. Discussion forum, which we encourage you to make use of -- both to pose questions about the material to the course instructor and to exchange ideas with your classmates. 8. High quality course support

rahul garg

As per my understanding with article, if you send any request to node server it will actually process on some background thread (libuv. dll). Now I want to post some file through node server, why it block the node server while it will actually process on background thread and when done , only response will be returned by node thread ? Kindly suggest if I am missing some thing

rahul garg

As per my understanding with article, if you send any request to node server it will actually process on some background thread (libuv. dll). Now I want to post some file through node server, why it block the node server while it will actually process on background thread and when done , only response will be returned by node thread ? Kindly suggest if I am missing some thing

siddesh

Super Article

siddesh

Super Article

Fanck

Isn't it possible to get the date of posting of your article? or all your posts for that matter. It is really disturbing to read technical posts without dates. thanks

Fanck

Isn't it possible to get the date of posting of your article? or all your posts for that matter. It is really disturbing to read technical posts without dates. thanks

Namo

You mention Node. js is good for a chat application because it's not CPU intensive. I can't think of too many use cases that don't require much CPU. For example, could Twitter be built with Node? It seems there's a lot of computation required just to generate your feed. Node. js uses certainly can't be so narrow

Namo

You mention Node. js is good for a chat application because it's not CPU intensive. I can't think of too many use cases that don't require much CPU. For example, could Twitter be built with Node? It seems there's a lot of computation required just to generate your feed. Node. js uses certainly can't be so narrow

Ian Kaplan

Great article. Thanks. There's an old joke. bạn không phải là một kẻ hoang tưởng nếu họ thực sự ra ngoài để có được bạn. That's the attitude that should be taken when it comes to Web application security. One thing that bothers me about Node. js is that I have no insight into how secure it is. When an environment like Grails, where I have Java/Groovy running on Tomcat I have some confidence in Tomcat security, if for no other reason than the fact that Tomcat has been around a long time and has evolved. This isn't true with Node. js. I was also looking at the Node. js libraries. Ít nhất là đối với quyền truy cập tệp, nó dường như chẳng khác gì một lớp mỏng trên các cuộc gọi hệ thống tệp POSIX. I like the Java or even the C++ file abstractions more. The main argument that I see for Node. js (made in this post) is that it has really lightweight threads and that you can have JavaScrip everywhere. Vấn đề cuối cùng này là một điểm thu hút đối với những người chỉ biết JavaScript. As far as the light weight threads, this is not so much a language issue as a platform support issue. It should be possible to support this kind of thread model in another language

Ian Kaplan

Great article. Thanks. There's an old joke. bạn không phải là một kẻ hoang tưởng nếu họ thực sự ra ngoài để có được bạn. That's the attitude that should be taken when it comes to Web application security. One thing that bothers me about Node. js is that I have no insight into how secure it is. When an environment like Grails, where I have Java/Groovy running on Tomcat I have some confidence in Tomcat security, if for no other reason than the fact that Tomcat has been around a long time and has evolved. This isn't true with Node. js. I was also looking at the Node. js libraries. Ít nhất là đối với quyền truy cập tệp, nó dường như chẳng khác gì một lớp mỏng trên các cuộc gọi hệ thống tệp POSIX. I like the Java or even the C++ file abstractions more. The main argument that I see for Node. js (made in this post) is that it has really lightweight threads and that you can have JavaScrip everywhere. Vấn đề cuối cùng này là một điểm thu hút đối với những người chỉ biết JavaScript. As far as the light weight threads, this is not so much a language issue as a platform support issue. It should be possible to support this kind of thread model in another language

Huge Web

Toptal designer did the design for them

Huge Web

Toptal designer did the design for them

Scott

Great article. Thank you for all the information

Scott

Great article. Thank you for all the information

daimmo

I agree. I guessed it was around "a year ago" because of most of Disqus comments. This is taken from their meta tags anyway. 2013-08-13

daimmo

I agree. I guessed it was around "a year ago" because of most of Disqus comments. This is taken from their meta tags anyway. 2013-08-13

Adnan King

nice

Adnan King

nice

Ethan Garofolo

Nút. js isn't a web framework. It's a packed V8 runtime with some core libraries attached. Node is more like mri in the Ruby world than Rails

Ethan Garofolo

Nút. js isn't a web framework. It's a packed V8 runtime with some core libraries attached. Node is more like mri in the Ruby world than Rails

Guest

Node. js is more like Rack, but not the same. MRI is just a language implementation

Guest

Node. js is more like Rack, but not the same. MRI is just a language implementation

Lambda Pool

the problem is that mongodb, its too risky using a database who can't be migrated never

Lambda Pool

the problem is that mongodb, its too risky using a database who can't be migrated never

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

the database engine itself will be ever more sophisticated than any ORM library home made by someone else

Lambda Pool

the database engine itself will be ever more sophisticated than any ORM library home made by someone else

John Bailo

It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there

John Bailo

It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there

Jayaraj Poroor

I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction

Jayaraj Poroor

I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction

Jayaraj Poroor

Regarding using Node. js with relational databases. Shelloid (http. //shelloid. org) is an open source application server for Node. js mà chúng tôi đã phát triển để đơn giản hóa nhiều tác vụ của lập trình viên. e. g. , You can declare named SQL queries as annotations and a function by that name automatically gets added to the DB object for you to use

Jayaraj Poroor

Regarding using Node. js with relational databases. Shelloid (http. //shelloid. org) is an open source application server for Node. js mà chúng tôi đã phát triển để đơn giản hóa nhiều tác vụ của lập trình viên. e. g. , You can declare named SQL queries as annotations and a function by that name automatically gets added to the DB object for you to use

M

I think you do not understand the reason for or characteristics of ORM's very well. ORM's not only isolate data concerns, they provide testability and greater flexibility than traditional SQL clients. ORM's also provide in memory access in place of inefficient joins, so they can actually be far more efficient than SQL in real world scenarios. Plus, given the choice of performing complex set operations in a limited procedural set language like SQL or complex in memory operations using a far richer, more expressive and maintainable language, the richer language wins if you ever expect to maintain or extend the application

M

I think you do not understand the reason for or characteristics of ORM's very well. ORM's not only isolate data concerns, they provide testability and greater flexibility than traditional SQL clients. ORM's also provide in memory access in place of inefficient joins, so they can actually be far more efficient than SQL in real world scenarios. Plus, given the choice of performing complex set operations in a limited procedural set language like SQL or complex in memory operations using a far richer, more expressive and maintainable language, the richer language wins if you ever expect to maintain or extend the application

M

You don't know what you are talking about. If you are writing a non-trivial applications and not using an ORM than I'm sure there will be many developers both today and in the future that will be cursing your name as they wade through ridiculous rafts of SQL. Testability? I guess that's just for trivial applications. When I see ridiculous comments like this coming from node. js fanboi's it makes me suspect that they'd be singing a different tune if node. js had decent RDBMS capabilities

M

You don't know what you are talking about. If you are writing a non-trivial applications and not using an ORM than I'm sure there will be many developers both today and in the future that will be cursing your name as they wade through ridiculous rafts of SQL. Testability? I guess that's just for trivial applications. When I see ridiculous comments like this coming from node. js fanboi's it makes me suspect that they'd be singing a different tune if node. js had decent RDBMS capabilities

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

your comment is ridiculous too, ORM is not a everyone's accepted pattern

Lambda Pool

your comment is ridiculous too, ORM is not a everyone's accepted pattern

M

The irony is that lambda's (aka, anonymous methods) are the basis of both javascript and the preferred technique for C#'s multiple implementation of the same callback pattern, albeit with full type safety. In fact node's major characteristics (2-way, lightweight, asynchronous has effectively been implemented in C# as "SignalR", and there are several language features which are both asynchronous and natively multithreaded, (unlike node. js). Now I could understand if your experience with ORM's was limited to Hibernate (absolutely awful, one of the worst implementations of a major concept I've ever had the displeasure to work with) or even EF, which at least is fairly powerful and expressive due to LINQ, if data nanny overkill. But a micro-ORM like Dapper gives you all the flexibility and power of direct SQL with the benefits of rich data manipulation via objects, and is fast, very fast. And I'm sorry, but OOP is a well proven, very effective design strategy if you know what you are doing, i. e. , you are a pro. I see three major problems with the node. js approach that no one seems to have a good answer for. So you start with the premise that there are such inefficiencies in waiting for IO that there is a huge potential there. So yeah, you've got great concurrency, right until you get to the first blocking library, a database, a file server, etc, which is practically every major piece of functionality written. So it's just hurry up and wait for 10,000 connections instead of 100, ok that's something, but where does it get you? So then you start rewriting all those services asynchronously, but that's just a snake eating its own tail, because that's hurry up and wait too. Because in the end every database on earth ultimately comes to a magnetic arm skipping across a disk or reading solid state memory, and that's assuming you're on the same machine, as opposed to distributing data across a pool of far slower network connections. Then you have the single threaded issue. Có lẽ không có ngôn ngữ nào bị lạm dụng nhiều hơn Javascript vì rào cản gia nhập quá thấp. And while early adopters might understand a bad practice when they see one, most javascript programmers simply have no idea what they are doing. Thirdly, Javascript is not exactly a particularly fast language, so the advice seems to be don't do compute intensive tasks. Where does that get you? So you end up with an elegant solution to one category of issues, but you're trapped there, with no way out of the non-compute intensive, hurry up and wait ghetto

M

The irony is that lambda's (aka, anonymous methods) are the basis of both javascript and the preferred technique for C#'s multiple implementation of the same callback pattern, albeit with full type safety. In fact node's major characteristics (2-way, lightweight, asynchronous has effectively been implemented in C# as "SignalR", and there are several language features which are both asynchronous and natively multithreaded, (unlike node. js). Now I could understand if your experience with ORM's was limited to Hibernate (absolutely awful, one of the worst implementations of a major concept I've ever had the displeasure to work with) or even EF, which at least is fairly powerful and expressive due to LINQ, if data nanny overkill. But a micro-ORM like Dapper gives you all the flexibility and power of direct SQL with the benefits of rich data manipulation via objects, and is fast, very fast. And I'm sorry, but OOP is a well proven, very effective design strategy if you know what you are doing, i. e. , you are a pro. I see three major problems with the node. js approach that no one seems to have a good answer for. So you start with the premise that there are such inefficiencies in waiting for IO that there is a huge potential there. So yeah, you've got great concurrency, right until you get to the first blocking library, a database, a file server, etc, which is practically every major piece of functionality written. So it's just hurry up and wait for 10,000 connections instead of 100, ok that's something, but where does it get you? So then you start rewriting all those services asynchronously, but that's just a snake eating its own tail, because that's hurry up and wait too. Because in the end every database on earth ultimately comes to a magnetic arm skipping across a disk or reading solid state memory, and that's assuming you're on the same machine, as opposed to distributing data across a pool of far slower network connections. Then you have the single threaded issue. Có lẽ không có ngôn ngữ nào bị lạm dụng nhiều hơn Javascript vì rào cản gia nhập quá thấp. And while early adopters might understand a bad practice when they see one, most javascript programmers simply have no idea what they are doing. Thirdly, Javascript is not exactly a particularly fast language, so the advice seems to be don't do compute intensive tasks. Where does that get you? So you end up with an elegant solution to one category of issues, but you're trapped there, with no way out of the non-compute intensive, hurry up and wait ghetto

M

Wow, that is one seriously ignorant statement. Uploading files to webservers is *THE* stated rational of node. js's inventor for why he wanted a non-blocking library. So when you fanboi's break out of the single threaded, slow dynamic world of cut and paste code with zero type safety, multithreading, and only one trick pony (lambdas) to match . Net's multiple asynchronous capablities, (all so that you can get 10x more users to hurry up and wait for IO), then you can lecture us about "sophistication". The . Net framework has a vastly more advanced feature set than any language you can name, period, and IIS, properly configured, can beat the piss out of Apache and can readily match nginx as a reverse proxy or for static content. In the end you've got several problems which are intractable. 1. Javascript is slow, and your technology of choice is single-threaded, so intensive compute tasks are off the table. 2. Javascript debugging and testing blows in comparison with any typed language. Pro's use extensive testing, not fly by the pants 'hey it works'. 3. The 'everything is modular' approach is not an architecture, it's an invitation to chaos, like Perl or PHP. 4. Concurrency doesn't buy you crap if all you are doing is waiting for some other IO bound process, which is pretty much everything worth doing with computers. 5. The quality and experience of many javascript programmers (not node. js programmers necessarily, but it's popularity will bring them) is remarkably poor, as demonstrated by comments in which fanboi's prove that they have no idea how other systems that actually don't ignore any computing problem they can't solve work

M

Wow, that is one seriously ignorant statement. Uploading files to webservers is *THE* stated rational of node. js's inventor for why he wanted a non-blocking library. So when you fanboi's break out of the single threaded, slow dynamic world of cut and paste code with zero type safety, multithreading, and only one trick pony (lambdas) to match . Net's multiple asynchronous capablities, (all so that you can get 10x more users to hurry up and wait for IO), then you can lecture us about "sophistication". The . Net framework has a vastly more advanced feature set than any language you can name, period, and IIS, properly configured, can beat the piss out of Apache and can readily match nginx as a reverse proxy or for static content. In the end you've got several problems which are intractable. 1. Javascript is slow, and your technology of choice is single-threaded, so intensive compute tasks are off the table. 2. Javascript debugging and testing blows in comparison with any typed language. Pro's use extensive testing, not fly by the pants 'hey it works'. 3. The 'everything is modular' approach is not an architecture, it's an invitation to chaos, like Perl or PHP. 4. Concurrency doesn't buy you crap if all you are doing is waiting for some other IO bound process, which is pretty much everything worth doing with computers. 5. The quality and experience of many javascript programmers (not node. js programmers necessarily, but it's popularity will bring them) is remarkably poor, as demonstrated by comments in which fanboi's prove that they have no idea how other systems that actually don't ignore any computing problem they can't solve work

Lambda Pool

ORM is just a work around for the problem of impedance mismatch, nothing else. Its not big deal, about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing, every real skilled programmer already knows that

Lambda Pool

ORM is just a work around for the problem of impedance mismatch, nothing else. Its not big deal, about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing, every real skilled programmer already knows that

M

Impedance mismatch involves all sorts of ramifications, especially in regards to maintainability, portability, extensibility and performance. To quote Ethan above (since my explanation obviously didn't take). ". đó là một công cụ được sử dụng để đóng gói các mối quan tâm về cơ sở dữ liệu, cách ly chúng khỏi ứng dụng. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. " "about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing" Ok, I'll be sure to spread the word that we should stop fooling around with all this esoteric OOP stuff and get back to a language that lets us do everything vis-a-vis encapsulation. VB6. You'd think a Javascript programmer might want to mention inheritance, if not polymorphism, since javascript has a relatively unusual mechanism for it. prototypes

M

Impedance mismatch involves all sorts of ramifications, especially in regards to maintainability, portability, extensibility and performance. To quote Ethan above (since my explanation obviously didn't take). ". đó là một công cụ được sử dụng để đóng gói các mối quan tâm về cơ sở dữ liệu, cách ly chúng khỏi ứng dụng. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. " "about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing" Ok, I'll be sure to spread the word that we should stop fooling around with all this esoteric OOP stuff and get back to a language that lets us do everything vis-a-vis encapsulation. VB6. You'd think a Javascript programmer might want to mention inheritance, if not polymorphism, since javascript has a relatively unusual mechanism for it. prototypes

M

A singleton is an instantiable (non-static) object with a private constructor so that only a single instance can be created. (Imagine an instance class with a static property exposing an instance of itself that depends upon a private instance constructor). It was actually implemented in Java before . mạng tồn tại. Perhaps what you are thinking of is a non-blocking Callback mechanism, which is handled in C# via delegates, events (multicast delegates) and the new async and await keywords that transform standard C# into a lambda to be executed at compile time. It also handles multi-threaded asynchronous operations via it's Parallel extensions, which permit spreading load across multiple threads/cores as long as that work is not serial in nature. Also, I would encourage you to check out a micro-ORM like Dapper. It's far less comprehensive than EF, but it's far more flexible and gets out of the way, plus it's significantly more efficient than Hibernate and EF (about 5x faster for reads)

M

A singleton is an instantiable (non-static) object with a private constructor so that only a single instance can be created. (Imagine an instance class with a static property exposing an instance of itself that depends upon a private instance constructor). It was actually implemented in Java before . mạng tồn tại. Perhaps what you are thinking of is a non-blocking Callback mechanism, which is handled in C# via delegates, events (multicast delegates) and the new async and await keywords that transform standard C# into a lambda to be executed at compile time. It also handles multi-threaded asynchronous operations via it's Parallel extensions, which permit spreading load across multiple threads/cores as long as that work is not serial in nature. Also, I would encourage you to check out a micro-ORM like Dapper. It's far less comprehensive than EF, but it's far more flexible and gets out of the way, plus it's significantly more efficient than Hibernate and EF (about 5x faster for reads)

Qalandr

Yes this article rocked tits. Esp good for a Croat with ESL. ;) #nodeboy

Qalandr

Yes this article rocked tits. Esp good for a Croat with ESL. ;) #nodeboy

Ty Turner

We are searching for a Node. js developer. Please see http. //altaits. com/careers/search-jobs/ for details. Cảm ơn bạn

Ty Turner

We are searching for a Node. js developer. Please see http. //altaits. com/careers/search-jobs/ for details. Cảm ơn bạn

Vob Bobily

So after reading your article I still havent figured out why Node js want to reinvent the wheel. I still think node js and the likes are crap

Vob Bobily

So after reading your article I still havent figured out why Node js want to reinvent the wheel. I still think node js and the likes are crap

cintalauraramarimari

A great introduction to find out what it is JavaScript and once the answer to from bagaimana tips mengatasi wanita frigid

cintalauraramarimari

A great introduction to find out what it is JavaScript and once the answer to from bagaimana tips mengatasi wanita frigid

Daniel

Noob questions. Um, isn't the ease with which you can move request data (i. e. untrusted data) into database (where data is assumed to be trusted) a big hazard? How do you ensure that you never forget to inspect every piece of incoming data when it arrives, before you start trusting it? Generally, I would assume something as popular as Node. js would have thought of this, but I remember back when Rails had blanket model update. That changed real quick when Github's use of this "feature" was exploited (fortunately, by a whitehat). Also, of course, just because you add a conversion speed bump does not mean that people won't make mistakes, but at least they're more likely to give it some thought, which probably means they're going to make less mistakes

Daniel

Noob questions. Um, isn't the ease with which you can move request data (i. e. untrusted data) into database (where data is assumed to be trusted) a big hazard? How do you ensure that you never forget to inspect every piece of incoming data when it arrives, before you start trusting it? Generally, I would assume something as popular as Node. js would have thought of this, but I remember back when Rails had blanket model update. That changed real quick when Github's use of this "feature" was exploited (fortunately, by a whitehat). Also, of course, just because you add a conversion speed bump does not mean that people won't make mistakes, but at least they're more likely to give it some thought, which probably means they're going to make less mistakes

Q

I don't understand the angst against using an ORM. Were you in a proper environment where concerns were separated? The ones bashing ORM just sound like they don't know what they're doing or how to engineer proper software. Why on earth would I want to go from writing software in Java/C#/_whatever_ to drop into SQL where it is hard to version, properly test, and can apparently cause severe brain damage? Everything is a double edged sword - an implementation or a convention like using an ORM over raw SQL really doesn't matter. Depending on the situation raw SQL might be best. it might be better to use a NoSQL store. maybe an ORM is fine. Usually, from my experience, I can tell you that an ORM is better for a lot of reasons, and they have been relayed by M. I spent the time to write my own libraries to abstract vendor specific implementations and you need to create your own mappings. You can easily spawn from a certain state or use existing data structures. It took time to write my libraries and it was not easy at all to do it but it was well worth my time to do it since I can now reuse my libraries. Is it the BEST? I don't know. I like it but I certainly won't go around to arbitrary technical articles that have nothing to do about SQL and post something like "Yes this technology is good but stay away from raw SQL. " I just don't see a need to be bashing anything here, especially an ORM when the article is exclusively about JS and NodeJS

Q

I don't understand the angst against using an ORM. Were you in a proper environment where concerns were separated? The ones bashing ORM just sound like they don't know what they're doing or how to engineer proper software. Why on earth would I want to go from writing software in Java/C#/_whatever_ to drop into SQL where it is hard to version, properly test, and can apparently cause severe brain damage? Everything is a double edged sword - an implementation or a convention like using an ORM over raw SQL really doesn't matter. Depending on the situation raw SQL might be best. it might be better to use a NoSQL store. maybe an ORM is fine. Usually, from my experience, I can tell you that an ORM is better for a lot of reasons, and they have been relayed by M. I spent the time to write my own libraries to abstract vendor specific implementations and you need to create your own mappings. You can easily spawn from a certain state or use existing data structures. It took time to write my libraries and it was not easy at all to do it but it was well worth my time to do it since I can now reuse my libraries. Is it the BEST? I don't know. I like it but I certainly won't go around to arbitrary technical articles that have nothing to do about SQL and post something like "Yes this technology is good but stay away from raw SQL. " I just don't see a need to be bashing anything here, especially an ORM when the article is exclusively about JS and NodeJS

Michael

Probably one of the main points of this article, that gives Node is supposed scalability, is the offloading to a Queue or Service Bus that leads to asynchronous processing. That is a well proven architectural pattern, available in many languages, is especially used in CQRS (Command Query Responsibility Segregation) with Event Sourcing, is very well suited to be used by technologies such . Net Reactive Extensions that provide considerably greater functionality and flexibility than Node. Asynchronous programming and handling its pitfalls has been around without Node for years, if you had knowledge of enterprise development. As for the hate against ORMs. you guys crticising it seem to be moving from front-end development into an area where you have no knowledge or expertise in OO, BDD, TDD or any other proven Enterprise level methodology. No concept of integration other than Twitter feeds. No experience of complex Workflow or scalable caching. This is one of the dangers - you know JavaScript, and a bit of SQL. So everything else is superfluous - until you need it, such as the attempts to bring an element of type checking to JavaScript. Seriously, each technology has its place, but there is no one size fits all approach. Appreciate the strengths of each technology, and use them where appropriate

Michael

Probably one of the main points of this article, that gives Node is supposed scalability, is the offloading to a Queue or Service Bus that leads to asynchronous processing. That is a well proven architectural pattern, available in many languages, is especially used in CQRS (Command Query Responsibility Segregation) with Event Sourcing, is very well suited to be used by technologies such . Net Reactive Extensions that provide considerably greater functionality and flexibility than Node. Asynchronous programming and handling its pitfalls has been around without Node for years, if you had knowledge of enterprise development. As for the hate against ORMs. you guys crticising it seem to be moving from front-end development into an area where you have no knowledge or expertise in OO, BDD, TDD or any other proven Enterprise level methodology. No concept of integration other than Twitter feeds. No experience of complex Workflow or scalable caching. This is one of the dangers - you know JavaScript, and a bit of SQL. So everything else is superfluous - until you need it, such as the attempts to bring an element of type checking to JavaScript. Seriously, each technology has its place, but there is no one size fits all approach. Appreciate the strengths of each technology, and use them where appropriate

Reo

Great introduction to node. js. Cảm ơn, tôi đã ngủ trưa

Reo

Great introduction to node. js. Cảm ơn, tôi đã ngủ trưa

Richard Bellantoni

Because they suck for a complex application. Sure if your scenario where you spent all this time trying to make the ORM work the way you need it to, you could have just put that same effort into writing the SQL properly and making sure it's organized etc and you would be further along in the project and have more control over the application. ORM's are great at saving time on a small to medium scale project, but once you delve into more complex and larger applications, you're going to spend either A. ) A lot of time coding to make the ORM work the way you need it or B. ) Just decide to write the SQL yourself because the time it takes to make the tool work how you need it just isn't worth it

Richard Bellantoni

Because they suck for a complex application. Sure if your scenario where you spent all this time trying to make the ORM work the way you need it to, you could have just put that same effort into writing the SQL properly and making sure it's organized etc and you would be further along in the project and have more control over the application. ORM's are great at saving time on a small to medium scale project, but once you delve into more complex and larger applications, you're going to spend either A. ) A lot of time coding to make the ORM work the way you need it or B. ) Just decide to write the SQL yourself because the time it takes to make the tool work how you need it just isn't worth it

sinta maharani

JavaScript is better than some of the other programming languages. therefore cara menghilangkan gatal keputihan better fit with JavaScript

sinta maharani

JavaScript is better than some of the other programming languages. therefore cara menghilangkan gatal keputihan better fit with JavaScript

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

Eric Elliott

Pot, meet kettle. Those may be intractable problems if any of them were true. None of them are. 1. a) JavaScript is all JIT these days and delivers 1-2x native code performance (faster than any other dynamic language I'm aware of). b) Non-blocking by default can deliver orders-of-magnitude improvements in code efficiency - transparently. 2. Almost all modern editors support type inference for JS. ESLint, Closure Compiler, and a number of other options offer sophisticated static analysis capabilities. TypeScript even offers a nice structural type system. 3. The opposite of modular is a tightly coupled monolith. That's a bad idea in ANY language. 4. "if all you are doing is waiting for some other IO bound process" - Non-blocking by default means you're NEVER waiting for some other IO bound process. That's why Node delivers such huge improvements on resource utilization. 5. 2006 được gọi là. They want their language-snob attitude back. The days when serious engineers considered JS to be a toy are long since over. JS powers sophisticated enterprise applications at just about every fortune 500 today. Additional point. JS is the only language with fully native support for isomorphic code (meaning you reuse most of your application on both servers and clients). You can write JS ONCE, and it will power the server, the web browser, and mobile devices including iOS and Android. Xem phản ứng bản địa. https. // leanpub. com/learn-javascript-react-nodejs-es6/

Eric Elliott

Pot, meet kettle. Those may be intractable problems if any of them were true. None of them are. 1. a) JavaScript is all JIT these days and delivers 1-2x native code performance (faster than any other dynamic language I'm aware of). b) Non-blocking by default can deliver orders-of-magnitude improvements in code efficiency - transparently. 2. Almost all modern editors support type inference for JS. ESLint, Closure Compiler, and a number of other options offer sophisticated static analysis capabilities. TypeScript even offers a nice structural type system. 3. The opposite of modular is a tightly coupled monolith. That's a bad idea in ANY language. 4. "if all you are doing is waiting for some other IO bound process" - Non-blocking by default means you're NEVER waiting for some other IO bound process. That's why Node delivers such huge improvements on resource utilization. 5. 2006 được gọi là. They want their language-snob attitude back. The days when serious engineers considered JS to be a toy are long since over. JS powers sophisticated enterprise applications at just about every fortune 500 today. Additional point. JS is the only language with fully native support for isomorphic code (meaning you reuse most of your application on both servers and clients). You can write JS ONCE, and it will power the server, the web browser, and mobile devices including iOS and Android. Xem phản ứng bản địa. https. // leanpub. com/learn-javascript-react-nodejs-es6/

M

1) 1-2x native code performance? Do the electrons run faster on node code? Not a good start. 2) Type inference is mapping variable declarations to types without explicit syntax, i. e. , a) it requires actual types, and b) compilers enforce type safety, not editors. And you can dress it up any way you want, but there is no way to enforce sophisticated state analysis with slop-tastic dictionaries of whatever stored in strings & functional delegates. Also, Typescript is not Javascript, it is Javascript with a half-assed type system pasted on top. Even Google is abandoning Js for Typescript in Angular 2. 0 Why? Because Google has decided that an untyped system is insufficient for serious work. Nhưng liệu hệ thống kiểu đó có phức tạp như một ngôn ngữ được biên dịch không? . 3) You are misunderstanding what I was characterizing as "modular design". The alternative is not monolithic code, but encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC. The alternative is SOLID, i. e. , modern Object Orientation. 4) Your process may not be waiting, but your customers are waiting for the callback. Quan điểm của tôi là việc có thể phục vụ nhiều yêu cầu hơn không giúp ích gì cho bạn nếu mọi yêu cầu được phục vụ sau đó lại phải chờ một hoạt động khác. Cuối cùng, ở một nơi nào đó, cuối cùng bạn sẽ chuyển sang đĩa hoặc chờ IO, bởi vì đó là nơi thông tin mà khách hàng muốn tồn tại. 5) Tôi không nói rằng JavaScript là ngôn ngữ đồ chơi, tôi đã nói rằng hầu hết các nhà phát triển JavaScript đều có ý tốt, cắt và dán nghiệp dư và họ sẽ xâm chiếm hàng ngũ nút. js khi nó trở nên phổ biến hơn. I'll take a strong type system over "full native support" (that's not native) for "isometric" code that can run on clients or servers [you say that like that's a good thing] any day. Wow, Js on android and iOS. Tôi đoán rằng thời của Apple bổ sung một ngôn ngữ bản địa, được gõ mạnh khác cho iOS đã qua Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính, tạo thời gian chạy gốc cho cả ba nền tảng di động chính và chạy trên mọi thứ từ cụm beowulf đến thiết bị đeo được. Đây là lý do tại sao chúng tôi không tôn trọng bạn. Bạn không biết hoặc không hiểu bất cứ điều gì xảy ra trước đó hoặc bất kỳ điều gì bên ngoài bong bóng javascript của bạn. Bạn không giải quyết bất kỳ vấn đề nào chưa được giải quyết trước đây, nhưng bạn tin rằng mình có tất cả các câu trả lời. Đó dường như là một chủ đề phổ biến với bất kỳ ai có hệ thống giáo dục nhấn mạnh lòng tự trọng hơn tư duy phản biện

M

1) 1-2x native code performance? Do the electrons run faster on node code? Not a good start. 2) Type inference is mapping variable declarations to types without explicit syntax, i. e. , a) it requires actual types, and b) compilers enforce type safety, not editors. And you can dress it up any way you want, but there is no way to enforce sophisticated state analysis with slop-tastic dictionaries of whatever stored in strings & functional delegates. Also, Typescript is not Javascript, it is Javascript with a half-assed type system pasted on top. Even Google is abandoning Js for Typescript in Angular 2. 0 Why? Because Google has decided that an untyped system is insufficient for serious work. Nhưng liệu hệ thống kiểu đó có phức tạp như một ngôn ngữ được biên dịch không? . 3) You are misunderstanding what I was characterizing as "modular design". The alternative is not monolithic code, but encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC. The alternative is SOLID, i. e. , modern Object Orientation. 4) Your process may not be waiting, but your customers are waiting for the callback. Quan điểm của tôi là việc có thể phục vụ nhiều yêu cầu hơn không giúp ích gì cho bạn nếu mọi yêu cầu được phục vụ sau đó lại phải chờ một hoạt động khác. Cuối cùng, ở một nơi nào đó, cuối cùng bạn sẽ chuyển sang đĩa hoặc chờ IO, bởi vì đó là nơi thông tin mà khách hàng muốn tồn tại. 5) Tôi không nói rằng JavaScript là ngôn ngữ đồ chơi, tôi đã nói rằng hầu hết các nhà phát triển JavaScript đều có ý tốt, cắt và dán nghiệp dư và họ sẽ xâm chiếm hàng ngũ nút. js khi nó trở nên phổ biến hơn. I'll take a strong type system over "full native support" (that's not native) for "isometric" code that can run on clients or servers [you say that like that's a good thing] any day. Wow, Js on android and iOS. Tôi đoán rằng thời của Apple bổ sung một ngôn ngữ bản địa, được gõ mạnh khác cho iOS đã qua Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính, tạo thời gian chạy gốc cho cả ba nền tảng di động chính và chạy trên mọi thứ từ cụm beowulf đến thiết bị đeo được. Đây là lý do tại sao chúng tôi không tôn trọng bạn. Bạn không biết hoặc không hiểu bất cứ điều gì xảy ra trước đó hoặc bất kỳ điều gì bên ngoài bong bóng javascript của bạn. Bạn không giải quyết bất kỳ vấn đề nào chưa được giải quyết trước đây, nhưng bạn tin rằng mình có tất cả các câu trả lời. Đó dường như là một chủ đề phổ biến với bất kỳ ai có hệ thống giáo dục nhấn mạnh lòng tự trọng hơn tư duy phản biện

Eric Elliott

Câu trả lời này chỉ gây ấn tượng với tôi là sự thiếu hiểu biết cố ý. 1. Có thật không? . Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. 3. "đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), tính đa hình và phụ thuộc bên ngoài thông qua IoC" - đây đều là các dạng mô-đun và các mô-đun JavaScript cung cấp các lựa chọn thay thế khả thi cho tất cả chúng - và trong trường hợp kế thừa lớp, nó vượt trội hơn nhiều. Xem https. //Trung bình. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. "khách hàng của bạn đang chờ gọi lại. " May mắn thay, đó là nơi màn trình diễn mà tôi đã nói ở điểm 1 tỏa sáng. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "you say that like that's a good thing" I've seen objectively measurable increases in team velocity ranging from 40% - 60% improvements. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. It's because they ran the tests themselves and figured out it's a huge win. "Obviously you've never heard of Mono, the cross platform . Net that compiles and runs on every major OS" Yeah, I have - what I haven't heard of is Mono delivering anywhere near the value that Node delivers in enterprise production. Got a good article on that? 'Cause a quick Google search isn't turning up much. Check out this awesome result in the top 3 of the SERP. http. //www. quora. com/Why-isnt-C-with-Mono-popular-for-enterprise-applications-on-Linux-servers . but a quick Google search for Enterprise Node. js delivers quite a bit. Here are the top 3 search results I see. http. //blog. risingstack. com/node-js-is-enterprise-ready/ https. //www. joyent. com/nodejs-support https. //www. centurylinkcloud. com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here

Eric Elliott

Câu trả lời này chỉ gây ấn tượng với tôi là sự thiếu hiểu biết cố ý. 1. Có thật không? . Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. 3. "đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), tính đa hình và phụ thuộc bên ngoài thông qua IoC" - đây đều là các dạng mô-đun và các mô-đun JavaScript cung cấp các lựa chọn thay thế khả thi cho tất cả chúng - và trong trường hợp kế thừa lớp, nó vượt trội hơn nhiều. Xem https. //Trung bình. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. "khách hàng của bạn đang chờ gọi lại. " May mắn thay, đó là nơi màn trình diễn mà tôi đã nói ở điểm 1 tỏa sáng. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "you say that like that's a good thing" I've seen objectively measurable increases in team velocity ranging from 40% - 60% improvements. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. It's because they ran the tests themselves and figured out it's a huge win. "Obviously you've never heard of Mono, the cross platform . Net that compiles and runs on every major OS" Yeah, I have - what I haven't heard of is Mono delivering anywhere near the value that Node delivers in enterprise production. Got a good article on that? 'Cause a quick Google search isn't turning up much. Check out this awesome result in the top 3 of the SERP. http. //www. quora. com/Why-isnt-C-with-Mono-popular-for-enterprise-applications-on-Linux-servers . but a quick Google search for Enterprise Node. js delivers quite a bit. Here are the top 3 search results I see. http. //blog. risingstack. com/node-js-is-enterprise-ready/ https. //www. joyent. com/nodejs-support https. //www. centurylinkcloud. com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here

M

1, yes, I'm mocking your evidently accidental claim that JavaScript makes electrons run faster, or even as fast as native, because it's patent nonsense. Not only is that impossible, it ignores one of node. js' acknowledged weaknesses. It sucks on compute intensive operations, because it's single threaded, which means compute intensive operations block execution. duh. 2. Your knowledge of Java does not qualify you to understand what a competent type system is. Java's generics are a largely useless, johnny come lately me-too feature when compared against to C# generics because they suffer from run-time erasure, in other words, the generic type safety and reflection only works at compile time, because at run time, everything is cast to an object. So when you are going on about static analysis, you are effectively trying to claim it's as good as compile time + run time type reflection, which is very far from the truth. 3. Meh. Chopping up everything into discrete functions is a form of modularity too, but it's vastly inferior to SOLID, which was my point in the first place. And while prototype based inheritance is interesting, it's hardly better than real inheritance, which permits far more flexible arrangements. 4. I don't see how it's impressive to speed up a Ruby app, or refactor some craptastic PHP into something faster. Your memory overhead claims are equally baseless. I can run micro. Net on a watch or on an arduino device. I can write . Net that runs very well on an under-powered phone. Look at the memory chrome consumes for an SPA, or try to run a complex javascript app on a tablet, and then tell me how "lightweight" JavaScript is. 5. The lack of a proper separation of concerns (which is the cause of most maintainability problems) is the number one issue I encounter at enterprise scaled customers, and an impressive team velocity is always how they got there. Why do I think a number of organizations are choosing node? Because typically a mediocre, over-sized team of moderate competence f'd up the previously shiny new thing that was supposed to solve all their problems, so they want to believe the hype that the problem is not them, but their previous technology choices

M

1, yes, I'm mocking your evidently accidental claim that JavaScript makes electrons run faster, or even as fast as native, because it's patent nonsense. Not only is that impossible, it ignores one of node. js' acknowledged weaknesses. It sucks on compute intensive operations, because it's single threaded, which means compute intensive operations block execution. duh. 2. Your knowledge of Java does not qualify you to understand what a competent type system is. Java's generics are a largely useless, johnny come lately me-too feature when compared against to C# generics because they suffer from run-time erasure, in other words, the generic type safety and reflection only works at compile time, because at run time, everything is cast to an object. So when you are going on about static analysis, you are effectively trying to claim it's as good as compile time + run time type reflection, which is very far from the truth. 3. Meh. Chopping up everything into discrete functions is a form of modularity too, but it's vastly inferior to SOLID, which was my point in the first place. And while prototype based inheritance is interesting, it's hardly better than real inheritance, which permits far more flexible arrangements. 4. I don't see how it's impressive to speed up a Ruby app, or refactor some craptastic PHP into something faster. Your memory overhead claims are equally baseless. I can run micro. Net on a watch or on an arduino device. I can write . Net that runs very well on an under-powered phone. Look at the memory chrome consumes for an SPA, or try to run a complex javascript app on a tablet, and then tell me how "lightweight" JavaScript is. 5. The lack of a proper separation of concerns (which is the cause of most maintainability problems) is the number one issue I encounter at enterprise scaled customers, and an impressive team velocity is always how they got there. Why do I think a number of organizations are choosing node? Because typically a mediocre, over-sized team of moderate competence f'd up the previously shiny new thing that was supposed to solve all their problems, so they want to believe the hype that the problem is not them, but their previous technology choices

Eric Elliott

1. I think you misunderstood my meaning. JS runs 1-2x SLOWER than native -- much better perf than any other dynamic language I know of. It's fast enough to run AAA game engines like Unreal Engine and Unity in stunning quality at 60+ fps. 2. I actually think that a good native type tool would be a good addition to JavaScript, but only if they're user-definable structural types. That said, JavaScript does support static analysis via type inference, and there are a number of ways to provide type hints for dev tools. In addition, JavaScript also has an impressive array of runtime analysis tools. 3. "hardly better than real inheritance, which permits far more flexible arrangements. " Wrong. https. //medium. com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. My apologies. I was not aware of micro. Bọc lưới. JavaScript cũng chạy nguyên trạng trên các thiết bị có công suất thấp bao gồm Arduino, Tessel và một số thiết bị khác. Nút hoạt động tốt trên hầu hết chúng. Nếu điều đó không đủ nhỏ, bạn có thể tạo một trình biên dịch Node tùy chỉnh, loại bỏ các tính năng, thậm chí hoán đổi công cụ V8 cho một công cụ JS khác nếu bạn cần. Bạn cũng có thể hạn chế sử dụng các thư viện JS nhỏ (trong đó có rất nhiều trên npm) để giữ cho cơ sở mã của bạn nhỏ gọn. 5. ". họ muốn tin vào sự cường điệu rằng vấn đề không phải ở họ, mà là do họ lựa chọn công nghệ trước đây. " Điều đó có thể giải thích cho một hoặc hai thử nghiệm, nhưng việc tiếp quản Node còn nhiều hơn thế. Chúng tôi đang nhanh chóng thay thế các ứng dụng bằng nhiều ngôn ngữ khác nhau bằng Node. Đã từng làm việc với số tiền 500 đô la trong quá trình chuyển đổi sang Node, tôi có thể cho bạn biết lý do của chúng tôi. Chúng tôi đã thử nghiệm chuyển sang Node, đã tìm thấy. 1. rằng ứng dụng nhanh hơn và đáng tin cậy hơn, mang lại những chiến thắng lớn về cả thời gian phản hồi trung bình và số lượng yêu cầu chúng tôi có thể phục vụ với cùng một máy và 2. Các nhà phát triển đã làm việc hiệu quả hơn vì nhiều lý do, bao gồm cả việc các chuyên gia JavaScript có thể làm việc dễ dàng hơn trên cả hai mặt của ngăn xếp mà không cần chuyển ngữ cảnh và nhiều mã có thể được chia sẻ ở cả máy chủ và máy khách. Những lợi thế đó có ảnh hưởng thực sự, có thể đo lường được đến lợi nhuận của công ty. Đó là lý do tại sao Node đang chiếm lĩnh cả các công ty khởi nghiệp và doanh nghiệp

Eric Elliott

1. I think you misunderstood my meaning. JS runs 1-2x SLOWER than native -- much better perf than any other dynamic language I know of. It's fast enough to run AAA game engines like Unreal Engine and Unity in stunning quality at 60+ fps. 2. I actually think that a good native type tool would be a good addition to JavaScript, but only if they're user-definable structural types. That said, JavaScript does support static analysis via type inference, and there are a number of ways to provide type hints for dev tools. In addition, JavaScript also has an impressive array of runtime analysis tools. 3. "hardly better than real inheritance, which permits far more flexible arrangements. " Wrong. https. //medium. com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. My apologies. I was not aware of micro. Bọc lưới. JavaScript cũng chạy nguyên trạng trên các thiết bị có công suất thấp bao gồm Arduino, Tessel và một số thiết bị khác. Nút hoạt động tốt trên hầu hết chúng. Nếu điều đó không đủ nhỏ, bạn có thể tạo một trình biên dịch Node tùy chỉnh, loại bỏ các tính năng, thậm chí hoán đổi công cụ V8 cho một công cụ JS khác nếu bạn cần. Bạn cũng có thể hạn chế sử dụng các thư viện JS nhỏ (trong đó có rất nhiều trên npm) để giữ cho cơ sở mã của bạn nhỏ gọn. 5. ". họ muốn tin vào sự cường điệu rằng vấn đề không phải ở họ, mà là do họ lựa chọn công nghệ trước đây. " Điều đó có thể giải thích cho một hoặc hai thử nghiệm, nhưng việc tiếp quản Node còn nhiều hơn thế. Chúng tôi đang nhanh chóng thay thế các ứng dụng bằng nhiều ngôn ngữ khác nhau bằng Node. Đã từng làm việc với số tiền 500 đô la trong quá trình chuyển đổi sang Node, tôi có thể cho bạn biết lý do của chúng tôi. Chúng tôi đã thử nghiệm chuyển sang Node, đã tìm thấy. 1. rằng ứng dụng nhanh hơn và đáng tin cậy hơn, mang lại những chiến thắng lớn về cả thời gian phản hồi trung bình và số lượng yêu cầu chúng tôi có thể phục vụ với cùng một máy và 2. Các nhà phát triển đã làm việc hiệu quả hơn vì nhiều lý do, bao gồm cả việc các chuyên gia JavaScript có thể làm việc dễ dàng hơn trên cả hai mặt của ngăn xếp mà không cần chuyển ngữ cảnh và nhiều mã có thể được chia sẻ ở cả máy chủ và máy khách. Những lợi thế đó có ảnh hưởng thực sự, có thể đo lường được đến lợi nhuận của công ty. Đó là lý do tại sao Node đang chiếm lĩnh cả các công ty khởi nghiệp và doanh nghiệp

Kesava Velugubantla

đặc biệt là với cạnh nó thực sự tiện dụng

Kesava Velugubantla

đặc biệt là với cạnh nó thực sự tiện dụng

pawan kumar

Thanks Tamisalv I was looking for quick reference read for understanding node. js and why projects might use it. Reading this gave me a better understanding of advantages of this this technology and also when one might use it. Cheers

pawan kumar

Thanks Tamisalv I was looking for quick reference read for understanding node. js and why projects might use it. Reading this gave me a better understanding of advantages of this this technology and also when one might use it. Cheers

Jay

"After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections. " As a result we have webpages which take longer to load nowadays when we have Internet speeds in the order of megabytes per second, than back in the day when our speeds were in the order of bytes per second but our webpages were plain simple HTML. Nowadays we have webpages which load halfway and then stop, which crash at the slightest network error i. e. dynamic IP address reassigning, or a momentary lapse in the WiFi signal forcing you to reload the whole page, whereas browsers are designed to gracefully handle those errors or resume once the network connection is restored, buggy Javascript scripts don't handle errors as well

Jay

"After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections. " As a result we have webpages which take longer to load nowadays when we have Internet speeds in the order of megabytes per second, than back in the day when our speeds were in the order of bytes per second but our webpages were plain simple HTML. Nowadays we have webpages which load halfway and then stop, which crash at the slightest network error i. e. dynamic IP address reassigning, or a momentary lapse in the WiFi signal forcing you to reload the whole page, whereas browsers are designed to gracefully handle those errors or resume once the network connection is restored, buggy Javascript scripts don't handle errors as well

adroittech

I only have 1 question here with your statement. "It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. " I can not take that. How? can you examplify? Some Facts (with obviously answer in no) - Why did Node inventor used V8 engine which was made in C++ to power node, if the js type system was so flexible and much better? - Can nodejs decode vp8 codec video by itself as efficiently as C/C++? - Could you build nodejs on top of pure javascript instead of C++? - Is there any such thing as pure javascript? You really have to understand my friend that it is a type system that can take advantage of underlying hardware and makes your program efficient at CPU and memory. Strongly typed C++ can solve any problem, even build node js. Node shines at non-blocking i/o and that is about it, it can not do anything else. Yes you can chop-off node code and make it work on micro devices but will it be efficient and make sense? Can you make product like node where you have to code in C++, yes you can but it would not make sense as power of C/C++ in not in web, its optimizations and hardware. It not like non-blocking I/O is something new, we have had that in many technologies including java, . Net, basic, python and perl, this is very old. The only reason why this thing is in limelight is it has enabled millions of frontend javascript developers, who do not understand pointers and bash about C++, to write server code, which is simply overwhelming, that's why the buzz. And about "Node in particular are actually very well suited to handle distributed computation", why on earth one would write such a statement? Node is not made for computation. it can not compute as efficiently as C/C++/Java. Period. With all due respect, lets not bring C++ in picture here, there is simply no practical comparison at all, or it will be very touchy

adroittech

I only have 1 question here with your statement. "It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. " I can not take that. How? can you examplify? Some Facts (with obviously answer in no) - Why did Node inventor used V8 engine which was made in C++ to power node, if the js type system was so flexible and much better? - Can nodejs decode vp8 codec video by itself as efficiently as C/C++? - Could you build nodejs on top of pure javascript instead of C++? - Is there any such thing as pure javascript? You really have to understand my friend that it is a type system that can take advantage of underlying hardware and makes your program efficient at CPU and memory. Strongly typed C++ can solve any problem, even build node js. Node shines at non-blocking i/o and that is about it, it can not do anything else. Yes you can chop-off node code and make it work on micro devices but will it be efficient and make sense? Can you make product like node where you have to code in C++, yes you can but it would not make sense as power of C/C++ in not in web, its optimizations and hardware. It not like non-blocking I/O is something new, we have had that in many technologies including java, . Net, basic, python and perl, this is very old. The only reason why this thing is in limelight is it has enabled millions of frontend javascript developers, who do not understand pointers and bash about C++, to write server code, which is simply overwhelming, that's why the buzz. And about "Node in particular are actually very well suited to handle distributed computation", why on earth one would write such a statement? Node is not made for computation. it can not compute as efficiently as C/C++/Java. Period. With all due respect, lets not bring C++ in picture here, there is simply no practical comparison at all, or it will be very touchy

Eric Elliott

You may be interested in this. https. //medium. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Eric Elliott

You may be interested in this. https. //medium. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Ken Kopelson

Actually, Javascript in the V8 server engine is QUITE fast. The statement that Javascript is not fast is outdated. You combine Node with Chrome and you get a very fast environment. If you understand how Node works, it has an event loop that processes all code that is ready to run. So, you call a function that has a blocking database call inside and a callback when finished, it allows the the function to be called, which returns immediately allowing you to get on with other things while the database call is being processed. So you aren't "hurry-up and waiting" as you suppose. You get on with other things, and once the database call finishes, execution will continue to the callback which is invoked after the database call returns. So, you get the same basic abilities as a multi-threaded environment without all the extra overhead incurred by thread-state swapping. Bởi vì bạn không bị "cắt thời gian", bạn phải cẩn thận để không có đoạn mã nào mất quá nhiều thời gian để chạy và nếu có, bạn chỉ cần chia nhỏ nó bằng cách sử dụng các gói như "async". I come from a long C, C++, Delphi, Java background, having mastered the multi-threaded paradigm, and I can state assuredly that the Node single-threaded async paradigm is super cool, fast, and highly scalable. IF YOU KNOW WHAT YOU'RE DOING. But that's the same for any of the other technologies as well. None of these technologies are for neophytes

Ken Kopelson

Actually, Javascript in the V8 server engine is QUITE fast. The statement that Javascript is not fast is outdated. You combine Node with Chrome and you get a very fast environment. If you understand how Node works, it has an event loop that processes all code that is ready to run. So, you call a function that has a blocking database call inside and a callback when finished, it allows the the function to be called, which returns immediately allowing you to get on with other things while the database call is being processed. So you aren't "hurry-up and waiting" as you suppose. You get on with other things, and once the database call finishes, execution will continue to the callback which is invoked after the database call returns. So, you get the same basic abilities as a multi-threaded environment without all the extra overhead incurred by thread-state swapping. Bởi vì bạn không bị "cắt thời gian", bạn phải cẩn thận để không có đoạn mã nào mất quá nhiều thời gian để chạy và nếu có, bạn chỉ cần chia nhỏ nó bằng cách sử dụng các gói như "async". I come from a long C, C++, Delphi, Java background, having mastered the multi-threaded paradigm, and I can state assuredly that the Node single-threaded async paradigm is super cool, fast, and highly scalable. IF YOU KNOW WHAT YOU'RE DOING. But that's the same for any of the other technologies as well. None of these technologies are for neophytes

M

Một ứng dụng phức tạp chính xác là nơi các đối tượng Miền được điều chỉnh tốt và các hệ thống con được tách riêng phù hợp là cần thiết nhất. Nếu bạn đang dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động, bạn nên tìm hiểu ORM đó tốt hơn hoặc kiếm một ORM khác. Tôi cho rằng cái trước không cần phải nói vì vậy nếu bạn vẫn đang chiến đấu với ORM của mình thì đã đến lúc chọn một cái vừa hoạt động

M

Một ứng dụng phức tạp chính xác là nơi các đối tượng Miền được điều chỉnh tốt và các hệ thống con được tách riêng phù hợp là cần thiết nhất. Nếu bạn đang dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động, bạn nên tìm hiểu ORM đó tốt hơn hoặc kiếm một ORM khác. Tôi cho rằng cái trước không cần phải nói vì vậy nếu bạn vẫn đang chiến đấu với ORM của mình thì đã đến lúc chọn một cái vừa hoạt động

M

Ngoại trừ nhận xét cuối cùng của bạn rằng những công nghệ này không dành cho tân sinh viên, tôi nghĩ bạn đang bỏ qua hai đoạn cuối mà bạn đang phản hồi. Ngay cả người sáng lập nút. js nói để tránh các hoạt động chuyên sâu tính toán. Có, V8 tăng tốc javascript, nhưng điều đó không giải quyết được vấn đề về hoạt động tính toán chuyên sâu hoặc hoạt động phụ thuộc vào IO chặn một chuỗi. Sau đó, bạn trả lời nút đó. js không bị chặn và do đó có thể đợi. Tuyệt, tôi hiểu rồi, chắc chắn rồi, nhưng bạn còn chờ gì nữa? . js rõ ràng, (rất nhiều vì lợi ích được tuyên bố là "một ngôn ngữ thực sự để cai trị tất cả"), bởi vì nút luồng đơn của bạn. js vui vẻ chuyển sang một thứ khác cho đến khi gọi lại. Vì vậy, nút. js hoạt động tốt miễn là bạn có thể dựa vào các quy trình khác xử lý khối lượng công việc đang chặn (như chờ IO) hoặc một phiên bản khác của nút đơn luồng. js, điều đó chắc chắn sẽ (nếu được viết "chính xác") sẽ chuyển hướng sang một quy trình khác. Và đó là vấn đề. there are a limited subset of stuff done in programs that can be executed in parallel/out of order, and/or doesn't rely on blocking operations. Đa luồng phức tạp hơn và có một số chi phí hoạt động mỗi khi có chuyển đổi ngữ cảnh, nhưng điều đó có nghĩa là có thể ném nhiều lõi hơn vào các đơn vị công việc có thể song song hóa và thậm chí các hoạt động rời rạc có thể được xử lý bởi các luồng khác nhau. Trong một "nút. js giải quyết mọi thứ", bạn đang dựa vào thứ gì đó không được viết trong nút. js hoặc chờ nút đơn luồng của bạn. js để hoàn thành tất cả những thứ phải hoàn thành, bằng cách này hay cách khác

M

Ngoại trừ nhận xét cuối cùng của bạn rằng những công nghệ này không dành cho tân sinh viên, tôi nghĩ bạn đang bỏ qua hai đoạn cuối mà bạn đang phản hồi. Ngay cả người sáng lập nút. js nói để tránh các hoạt động chuyên sâu tính toán. Có, V8 tăng tốc javascript, nhưng điều đó không giải quyết được vấn đề về hoạt động tính toán chuyên sâu hoặc hoạt động phụ thuộc vào IO chặn một chuỗi. Sau đó, bạn trả lời nút đó. js không bị chặn và do đó có thể đợi. Tuyệt, tôi hiểu rồi, chắc chắn rồi, nhưng bạn còn chờ gì nữa? . js rõ ràng, (rất nhiều vì lợi ích được tuyên bố là "một ngôn ngữ thực sự để cai trị tất cả"), bởi vì nút luồng đơn của bạn. js vui vẻ chuyển sang một thứ khác cho đến khi gọi lại. Vì vậy, nút. js hoạt động tốt miễn là bạn có thể dựa vào các quy trình khác xử lý khối lượng công việc đang chặn (như chờ IO) hoặc một phiên bản khác của nút đơn luồng. js, điều đó chắc chắn sẽ (nếu được viết "chính xác") sẽ chuyển hướng sang một quy trình khác. Và đó là vấn đề. there are a limited subset of stuff done in programs that can be executed in parallel/out of order, and/or doesn't rely on blocking operations. Đa luồng phức tạp hơn và có một số chi phí hoạt động mỗi khi có chuyển đổi ngữ cảnh, nhưng điều đó có nghĩa là có thể ném nhiều lõi hơn vào các đơn vị công việc có thể song song hóa và thậm chí các hoạt động rời rạc có thể được xử lý bởi các luồng khác nhau. Trong một "nút. js giải quyết mọi thứ", bạn đang dựa vào thứ gì đó không được viết trong nút. js hoặc chờ nút đơn luồng của bạn. js để hoàn thành tất cả những thứ phải hoàn thành, bằng cách này hay cách khác

Ken Kopelson

Bạn biết gì? . Rõ ràng là bạn chưa bao giờ xây dựng bất cứ thứ gì nghiêm túc trong Node. js. Vâng, tôi có, và tôi có thể nói với bạn rằng nó hoạt động rất tốt nếu bạn thực sự lập trình nó một cách chính xác. Điều đó có nghĩa là bạn sử dụng những thứ như hàng đợi công việc, bạn sử dụng phân cụm mà Node cung cấp, bạn đảm bảo rằng bạn làm mọi thứ với lời gọi lại và lời hứa, bạn sử dụng "async" và "setImmediate" để chia sẻ bộ xử lý đúng cách giữa mã đang chờ và mã có thể . Ví dụ: tôi đã viết một thuật toán sắp xếp heap "không đồng bộ" hoạt động rất tốt, sắp xếp các danh sách lớn trong khi không chặn trong bất kỳ khoảng thời gian đáng kể nào. Tôi cũng có một thuật toán heuristic 5000 dòng khá phức tạp mà tôi đã chia ra để các vòng lặp chính được thực thi bằng cách sử dụng các cấu trúc không đồng bộ. Sau đó, tôi đã thực hiện các lệnh này từ hàng đợi công việc có tên là "Kue" cho phép sử dụng hiệu quả tất cả các lõi, không có luồng, thời gian phản hồi giao diện người dùng tuyệt vời và các công việc tính toán phức tạp được thực hiện trong nền bằng cách sử dụng tất cả sức mạnh bộ xử lý có sẵn. Điều này TẤT CẢ được thực hiện bằng javascript với hiệu suất tuyệt vời trong cả các tác vụ sử dụng nhiều CPU và phản hồi các yêu cầu dữ liệu từ giao diện người dùng. Nói cách khác, giao diện người dùng siêu nhạy và quá trình xử lý nền (tính toán heuristic phức tạp) được thực hiện nhanh chóng và rất nhạy. This is all done with a single language for both backend and front end, which is a huge deal when it comes to system architecture

Ken Kopelson

Bạn biết gì? . Rõ ràng là bạn chưa bao giờ xây dựng bất cứ thứ gì nghiêm túc trong Node. js. Vâng, tôi có, và tôi có thể nói với bạn rằng nó hoạt động rất tốt nếu bạn thực sự lập trình nó một cách chính xác. Điều đó có nghĩa là bạn sử dụng những thứ như hàng đợi công việc, bạn sử dụng phân cụm mà Node cung cấp, bạn đảm bảo rằng bạn làm mọi thứ với lời gọi lại và lời hứa, bạn sử dụng "async" và "setImmediate" để chia sẻ bộ xử lý đúng cách giữa mã đang chờ và mã có thể . Ví dụ: tôi đã viết một thuật toán sắp xếp heap "không đồng bộ" hoạt động rất tốt, sắp xếp các danh sách lớn trong khi không chặn trong bất kỳ khoảng thời gian đáng kể nào. Tôi cũng có một thuật toán heuristic 5000 dòng khá phức tạp mà tôi đã chia ra để các vòng lặp chính được thực thi bằng cách sử dụng các cấu trúc không đồng bộ. Sau đó, tôi đã thực hiện các lệnh này từ hàng đợi công việc có tên là "Kue" cho phép sử dụng hiệu quả tất cả các lõi, không có luồng, thời gian phản hồi giao diện người dùng tuyệt vời và các công việc tính toán phức tạp được thực hiện trong nền bằng cách sử dụng tất cả sức mạnh bộ xử lý có sẵn. Điều này TẤT CẢ được thực hiện bằng javascript với hiệu suất tuyệt vời trong cả các tác vụ sử dụng nhiều CPU và phản hồi các yêu cầu dữ liệu từ giao diện người dùng. Nói cách khác, giao diện người dùng siêu nhạy và quá trình xử lý nền (tính toán heuristic phức tạp) được thực hiện nhanh chóng và rất nhạy. This is all done with a single language for both backend and front end, which is a huge deal when it comes to system architecture

Jacob Ross

Tại sao chúng không dành cho "neophytes"?

Jacob Ross

Tại sao chúng không dành cho "neophytes"?

Jacob Ross

tôi đồng ý. Hầu hết những lần tôi nghĩ ORM không đủ cho các truy vấn phức tạp, tôi viết ra SQL thô, sau đó phát hiện ra ORM có một "ứng dụng cho điều đó". Tôi thích sử dụng ORM nhất có thể, nhưng tôi sẽ không dành quá nhiều thời gian để làm cho nó hoạt động với mình, nếu không, như M đã nói, tôi sẽ tìm một ORM khác

Jacob Ross

tôi đồng ý. Hầu hết những lần tôi nghĩ ORM không đủ cho các truy vấn phức tạp, tôi viết ra SQL thô, sau đó phát hiện ra ORM có một "ứng dụng cho điều đó". Tôi thích sử dụng ORM nhất có thể, nhưng tôi sẽ không dành quá nhiều thời gian để làm cho nó hoạt động với mình, nếu không, như M đã nói, tôi sẽ tìm một ORM khác

JF80

Nghe giống như những từ trong "Michael" mà tôi biết. ;) Tôi đồng ý với tuyên bố cuối cùng của bạn. "mỗi công nghệ có vị trí của nó". Nhưng tại sao bạn lại cho rằng tất cả các nhà phát triển Node đều là nhà phát triển front-end không có kiến ​​thức về back-end?

JF80

Nghe giống như những từ trong "Michael" mà tôi biết. ;) Tôi đồng ý với tuyên bố cuối cùng của bạn. "mỗi công nghệ có vị trí của nó". Nhưng tại sao bạn lại cho rằng tất cả các nhà phát triển Node đều là nhà phát triển front-end không có kiến ​​thức về back-end?

đấtT

Javascript là một lựa chọn ngôn ngữ kém để phát triển doanh nghiệp/phức hợp. Nó lộn xộn, khó đọc, khó tổ chức, không hỗ trợ toàn bộ các mô hình OO giúp tiết kiệm nhiều mã lặp lại và cung cấp sự trừu tượng có thể đọc được, chủ yếu gây ra lỗi thời gian chạy, không AOP, không theo quy ước, không phản ánh, . Chúng tôi bị mắc kẹt với nó trong trình duyệt và thành thật mà nói, đó chỉ là quán tính và hỗ trợ kế thừa có nghĩa là nó vẫn được sử dụng ở đó. In all rights it should have gone the way of the dinosaurs 10 years ago. Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn có lỗi liên tục không thể theo dõi được. Mới chỉ 10 năm ngắn ngủi kể từ khi chúng tôi thở phào nhẹ nhõm khi sự phát triển nghiêm túc không còn là ngôn ngữ kịch bản và ở đây chúng tôi đang làm lại điều đó mà không muốn học hỏi từ quá khứ, tin chắc rằng đây là "mới và tiên tiến", đúng hơn là . Nó sẽ kết thúc giống như lần trước, bị bàn tán với sự ghê tởm như asp cổ điển và perl cgi. Tôi chỉ có thể kết luận rằng các nhà phát triển ủng hộ nó bây giờ chỉ là không có mặt để chứng kiến ​​​​sự sụp đổ của lần cuối cùng này. Mọi thế hệ nhà phát triển mới đều tin chắc rằng họ đã khám phá ra "sự thật", những người trong chúng ta, những người đã chứng kiến ​​chu kỳ đau đớn này chỉ có thể ngồi lại và lắc đầu không thể tin được. Thật không may, bạn không thể dạy kinh nghiệm, đó là điều bạn phải học một cách khó khăn. Chắc chắn nếu bạn là một người nghiệp dư và không biết gì khác thì bằng mọi cách, nhưng bất kỳ ai đang cố gắng làm một công việc chuyên nghiệp cần phải để yên vấn đề này và ngừng đưa ra các lựa chọn công nghệ theo chủ nghĩa dân túy mà không xem xét kết quả. Nếu bạn không thể tự mình đánh giá những hạn chế lâu dài của một công nghệ thì bạn không nên làm việc trong lĩnh vực phát triển. Các nhà phát triển cần ngừng trẻ con như vậy, hành động như một lũ fan boy si mê, đây là một công việc nghiêm túc, không phải trò chơi

đấtT

Javascript là một lựa chọn ngôn ngữ kém để phát triển doanh nghiệp/phức hợp. Nó lộn xộn, khó đọc, khó tổ chức, không hỗ trợ toàn bộ các mô hình OO giúp tiết kiệm nhiều mã lặp lại và cung cấp sự trừu tượng có thể đọc được, chủ yếu gây ra lỗi thời gian chạy, không AOP, không theo quy ước, không phản ánh, . Chúng tôi bị mắc kẹt với nó trong trình duyệt và thành thật mà nói, đó chỉ là quán tính và hỗ trợ kế thừa có nghĩa là nó vẫn được sử dụng ở đó. In all rights it should have gone the way of the dinosaurs 10 years ago. Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn có lỗi liên tục không thể theo dõi được. Mới chỉ 10 năm ngắn ngủi kể từ khi chúng tôi thở phào nhẹ nhõm khi sự phát triển nghiêm túc không còn là ngôn ngữ kịch bản và ở đây chúng tôi đang làm lại điều đó mà không muốn học hỏi từ quá khứ, tin chắc rằng đây là "mới và tiên tiến", đúng hơn là . Nó sẽ kết thúc giống như lần trước, bị bàn tán với sự ghê tởm như asp cổ điển và perl cgi. Tôi chỉ có thể kết luận rằng các nhà phát triển ủng hộ nó bây giờ chỉ là không có mặt để chứng kiến ​​​​sự sụp đổ của lần cuối cùng này. Mọi thế hệ nhà phát triển mới đều tin chắc rằng họ đã khám phá ra "sự thật", những người trong chúng ta, những người đã chứng kiến ​​chu kỳ đau đớn này chỉ có thể ngồi lại và lắc đầu không thể tin được. Thật không may, bạn không thể dạy kinh nghiệm, đó là điều bạn phải học một cách khó khăn. Chắc chắn nếu bạn là một người nghiệp dư và không biết gì khác thì bằng mọi cách, nhưng bất kỳ ai đang cố gắng làm một công việc chuyên nghiệp cần phải để yên vấn đề này và ngừng đưa ra các lựa chọn công nghệ theo chủ nghĩa dân túy mà không xem xét kết quả. Nếu bạn không thể tự mình đánh giá những hạn chế lâu dài của một công nghệ thì bạn không nên làm việc trong lĩnh vực phát triển. Các nhà phát triển cần ngừng trẻ con như vậy, hành động như một lũ fan boy si mê, đây là một công việc nghiêm túc, không phải trò chơi

adroittech

Chúa ơi. Eric. Bạn có thật không? . NÓ Ở TRÊN PLAIN C/C++. http_parcer là thư viện C++. libuv là một thư viện C++ khác và quan trọng nhất trong xương sống của nodejs, làm cho nodejs không đồng bộ, hướng sự kiện và không chặn. Bản thân Javascript là một cơ thể không có linh hồn và sự sống. JAVASCRIPT chỉ là một kịch bản mà bạn sử dụng để viết kịch bản logic của mình. Một ngày nào đó nếu smeoene port lua với libs này, anh ấy sẽ không cần Javascript để viết mã. tương tự cho python, v.v. Nhưng thực tế cơ bản vẫn giữ nguyên. NÓ LÀ mã C++ tạo nên nodejs, không phải javascript quá nhanh. trên thực tế, javascript chậm nhất trong tất cả các ngôn ngữ kịch bản. Vì vậy, đừng tự tâng bốc bản thân khi tin rằng chỉ có java-script là tuyệt vời còn những thứ khác thì tệ hại. Và đừng xúc phạm C/C++ nếu bạn không có kiến ​​thức về nó. Vì vậy, một lần nữa, tôi mong bạn rút lại lời nói của mình. "Hệ thống kiểu Javascript tốt hơn C++". (Javascript has no type system. and if you still believe that it has one, you are in a very wrong field, go build some scaffolding) Also, these companies are not choosing nodejs for the reason you mentioned. Điều này có thể ở hầu hết các ngôn ngữ. Lý do tại sao các công ty chọn nodejs là vì họ có sẵn các lập trình viên javascript, hàng triệu và không thể làm mã c ++/java, để làm phía máy chủ vì nó rẻ hơn. Một lý do khác -> hệ sinh thái của nó. Một lý do khác -> Việc tiến hành kiểm tra tải trong nodejs dễ dàng hơn nhiều so với các tập lệnh khác. Liên kết bạn đã đề cập là công việc dự định sẽ được bắt đầu. Tại sao bạn không đề nghị họ viết trình biên dịch hợp ngữ web này trong nodejs chứ không phải c/C++/assembly vì theo bạn điều đó tốt hơn. Thôi nào anh bạn, làm sao bạn có thể so sánh Nodejs (Công nghệ) với C++ (ngôn ngữ), chúng không cùng đẳng cấp. C++ làm cho nút có thể, không phải ngược lại

adroittech

Chúa ơi. Eric. Bạn có thật không? . NÓ Ở TRÊN PLAIN C/C++. http_parcer là thư viện C++. libuv là một thư viện C++ khác và quan trọng nhất trong xương sống của nodejs, làm cho nodejs không đồng bộ, hướng sự kiện và không chặn. Bản thân Javascript là một cơ thể không có linh hồn và sự sống. JAVASCRIPT chỉ là một kịch bản mà bạn sử dụng để viết kịch bản logic của mình. Một ngày nào đó nếu smeoene port lua với libs này, anh ấy sẽ không cần Javascript để viết mã. tương tự cho python, v.v. Nhưng thực tế cơ bản vẫn giữ nguyên. NÓ LÀ mã C++ tạo nên nodejs, không phải javascript quá nhanh. trên thực tế, javascript chậm nhất trong tất cả các ngôn ngữ kịch bản. Vì vậy, đừng tự tâng bốc bản thân khi tin rằng chỉ có java-script là tuyệt vời còn những thứ khác thì tệ hại. Và đừng xúc phạm C/C++ nếu bạn không có kiến ​​thức về nó. Vì vậy, một lần nữa, tôi mong bạn rút lại lời nói của mình. "Hệ thống kiểu Javascript tốt hơn C++". (Javascript has no type system. and if you still believe that it has one, you are in a very wrong field, go build some scaffolding) Also, these companies are not choosing nodejs for the reason you mentioned. Điều này có thể ở hầu hết các ngôn ngữ. Lý do tại sao các công ty chọn nodejs là vì họ có sẵn các lập trình viên javascript, hàng triệu và không thể làm mã c ++/java, để làm phía máy chủ vì nó rẻ hơn. Một lý do khác -> hệ sinh thái của nó. Một lý do khác -> Việc tiến hành kiểm tra tải trong nodejs dễ dàng hơn nhiều so với các tập lệnh khác. Liên kết bạn đã đề cập là công việc dự định sẽ được bắt đầu. Tại sao bạn không đề nghị họ viết trình biên dịch hợp ngữ web này trong nodejs chứ không phải c/C++/assembly vì theo bạn điều đó tốt hơn. Thôi nào anh bạn, làm sao bạn có thể so sánh Nodejs (Công nghệ) với C++ (ngôn ngữ), chúng không cùng đẳng cấp. C++ làm cho nút có thể, không phải ngược lại

oberona

"Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn" - bạn có thể làm rõ ý của mình bằng ngôn ngữ kịch bản không và "các nhà phát triển nghiêm túc" đã chuyển sang ngôn ngữ thay thế nào trong hơn mười năm qua . Ngược lại, Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó. Những lời chỉ trích của bạn về js là đúng, nhưng tôi không thể thấy cách chúng áp dụng trên toàn bộ vũ trụ ngôn ngữ kịch bản

oberona

"Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn" - bạn có thể làm rõ ý của mình bằng ngôn ngữ kịch bản không và "các nhà phát triển nghiêm túc" đã chuyển sang ngôn ngữ thay thế nào trong hơn mười năm qua . Ngược lại, Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó. Những lời chỉ trích của bạn về js là đúng, nhưng tôi không thể thấy cách chúng áp dụng trên toàn bộ vũ trụ ngôn ngữ kịch bản

đấtT

Tôi định nghĩa ngôn ngữ kịch bản là ngôn ngữ biên dịch thời gian chạy, nhưng ngày nay có rất nhiều sự chồng chéo. Tôi thích sự đảm bảo về xác minh thời gian biên dịch ít nhất là độ chính xác của mã hóa nhưng đó không phải là yếu tố duy nhất. Mức độ xâm lấn sâu vào hoạt động bên trong của trình biên dịch mà ngày nay các ngôn ngữ được biên dịch có xu hướng phơi bày cho phép tạo ra một loạt các cấu trúc và mẫu thiết kế cho phép lập trình trở nên "thông minh" hơn, tôi chỉ không thấy mức độ này . Đó là một hạn chế nghiêm trọng cho sự phát triển doanh nghiệp nghiêm túc. ORM là một cách tiếp cận xấu để truy cập dữ liệu trên cơ sở dữ liệu quan hệ, nhưng bạn có thể phải là nhà phát triển cơ sở dữ liệu để nhận ra lý do tại sao. Thiết kế dữ liệu và thiết kế chương trình có các ràng buộc khác nhau, các ORM thực hiện một cách bất công hoặc phải sửa đổi quá nhiều đến mức chúng không mang lại năng suất. Có nhiều vấn đề chẳng hạn như bảo mật, cách ly, hoạt động nguyên tử mà ORM bị hỏng và hãy nhớ rằng cơ sở dữ liệu là một hệ thống sống và có thể yêu cầu thay đổi giữa các lần phát hành mã như một vấn đề tất nhiên. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Đó là một chủ đề chi tiết, tôi có thể viết một cuốn sách về nó, rất xin lỗi nếu điều này không đủ thuyết phục cho bạn. Không thể nói nhiều về Python ngoài việc tôi đã nghe những điều tốt nói chung. Tôi là đầu kia của thị trường trên. Net, tôi đóng đinh những người nguồn mở hàng xóm về năng suất và mức độ lỗi của tôi là khoảng 1% so với họ. Tôi nghĩ rằng bạn cần một hệ thống lớn trước khi nó tạo ra sự khác biệt đáng kể, vì bạn cần đầu tư vào khung và chất nền để nhận lại những lợi ích chính, "mã hóa hàng loạt" của nó là kẻ thù ở đây. Khi bạn có hơn 100.000 tệp mã, bạn cần mức độ bảo trì cao hơn vì đơn giản là vượt quá khả năng của con người để thực hiện từng tệp một (và chắc chắn là vượt quá ngân sách bảo trì). Bằng cách tạo các dịch vụ cốt lõi sử dụng mã dưới dạng nội dung, bạn có thể đạt được mức chất lượng cao trong khi vẫn giữ mọi thứ chi tiết và đảm bảo việc phát hành ở mức nhỏ và có mục tiêu thay vì giảm toàn bộ hệ thống. Mỗi cái đều có cái riêng của chúng, nhưng nếu bạn là một chuyên gia CNTT, bạn hẳn đã thấy hàng triệu hệ thống dựa trên tập lệnh đang hoạt động trong các doanh nghiệp vì không ai có thể tìm thấy bất cứ thứ gì hoặc hiểu cách thức hoạt động của nó. Đó là một lời phàn nàn phổ biến mà tôi nghĩ nó không cần phải biện minh

đấtT

Tôi định nghĩa ngôn ngữ kịch bản là ngôn ngữ biên dịch thời gian chạy, nhưng ngày nay có rất nhiều sự chồng chéo. Tôi thích sự đảm bảo về xác minh thời gian biên dịch ít nhất là độ chính xác của mã hóa nhưng đó không phải là yếu tố duy nhất. Mức độ xâm lấn sâu vào hoạt động bên trong của trình biên dịch mà ngày nay các ngôn ngữ được biên dịch có xu hướng phơi bày cho phép tạo ra một loạt các cấu trúc và mẫu thiết kế cho phép lập trình trở nên "thông minh" hơn, tôi chỉ không thấy mức độ này . Đó là một hạn chế nghiêm trọng cho sự phát triển doanh nghiệp nghiêm túc. ORM là một cách tiếp cận xấu để truy cập dữ liệu trên cơ sở dữ liệu quan hệ, nhưng bạn có thể phải là nhà phát triển cơ sở dữ liệu để nhận ra lý do tại sao. Thiết kế dữ liệu và thiết kế chương trình có các ràng buộc khác nhau, các ORM thực hiện một cách bất công hoặc phải sửa đổi quá nhiều đến mức chúng không mang lại năng suất. Có nhiều vấn đề chẳng hạn như bảo mật, cách ly, hoạt động nguyên tử mà ORM bị hỏng và hãy nhớ rằng cơ sở dữ liệu là một hệ thống sống và có thể yêu cầu thay đổi giữa các lần phát hành mã như một vấn đề tất nhiên. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Đó là một chủ đề chi tiết, tôi có thể viết một cuốn sách về nó, rất xin lỗi nếu điều này không đủ thuyết phục cho bạn. Không thể nói nhiều về Python ngoài việc tôi đã nghe những điều tốt nói chung. Tôi là đầu kia của thị trường trên. Net, tôi đóng đinh những người nguồn mở hàng xóm về năng suất và mức độ lỗi của tôi là khoảng 1% so với họ. Tôi nghĩ rằng bạn cần một hệ thống lớn trước khi nó tạo ra sự khác biệt đáng kể, vì bạn cần đầu tư vào khung và chất nền để nhận lại những lợi ích chính, "mã hóa hàng loạt" của nó là kẻ thù ở đây. Khi bạn có hơn 100.000 tệp mã, bạn cần mức độ bảo trì cao hơn vì đơn giản là vượt quá khả năng của con người để thực hiện từng tệp một (và chắc chắn là vượt quá ngân sách bảo trì). Bằng cách tạo các dịch vụ cốt lõi sử dụng mã dưới dạng nội dung, bạn có thể đạt được mức chất lượng cao trong khi vẫn giữ mọi thứ chi tiết và đảm bảo việc phát hành ở mức nhỏ và có mục tiêu thay vì giảm toàn bộ hệ thống. Mỗi cái đều có cái riêng của chúng, nhưng nếu bạn là một chuyên gia CNTT, bạn hẳn đã thấy hàng triệu hệ thống dựa trên tập lệnh đang hoạt động trong các doanh nghiệp vì không ai có thể tìm thấy bất cứ thứ gì hoặc hiểu cách thức hoạt động của nó. Đó là một lời phàn nàn phổ biến mà tôi nghĩ nó không cần phải biện minh

đấtT

P. S. Tôi nghĩ rằng "các nhà phát triển nghiêm túc" đã chuyển sang Java, C# hoặc quay lại C++ (cùng với các công nghệ web liên quan của họ, v.v.). Tôi thực sự không có ý định xúc phạm nhưng ba điều này có lẽ chiếm 90% tổng số atm phát triển thương mại. Đối với tôi, C# giành chiến thắng trên mặt trận thương mại chỉ dựa vào khoản đầu tư liên tục đáng kể của Microsoft và cách tiếp cận hiện đại mới được tìm thấy. C ++ không hiệu quả lắm và Java thực sự bắt đầu trông hơi lỗi thời. Tôi vẫn làm việc ở cả ba và họ hoàn thành công việc, mỗi người đều có vị trí của mình

đấtT

P. S. Tôi nghĩ rằng "các nhà phát triển nghiêm túc" đã chuyển sang Java, C# hoặc quay lại C++ (cùng với các công nghệ web liên quan của họ, v.v.). Tôi thực sự không có ý định xúc phạm nhưng ba điều này có lẽ chiếm 90% tổng số atm phát triển thương mại. Đối với tôi, C# giành chiến thắng trên mặt trận thương mại chỉ dựa vào khoản đầu tư liên tục đáng kể của Microsoft và cách tiếp cận hiện đại mới được tìm thấy. C ++ không hiệu quả lắm và Java thực sự bắt đầu trông hơi lỗi thời. Tôi vẫn làm việc ở cả ba và họ hoàn thành công việc, mỗi người đều có vị trí của mình

đấtT

P. P. S. "Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó". Bạn nghĩ gì về khả năng bảo trì? . Nó bao gồm chi phí thay đổi và đó là chi phí chính của doanh nghiệp cho một dự án sinh hoạt. Ví dụ. Tôi có một dịch vụ với 1000 phương thức công khai và doanh nghiệp yêu cầu tôi hủy ưu tiên tất cả các cuộc gọi kéo dài hơn 2 giây. Nếu tôi phải sửa đổi bất kỳ mã nào trong 1000 lệnh gọi đó thì mã của tôi có khả năng bảo trì kém nghiêm trọng. Những gì tôi nên làm là thay đổi một mã trong đường dẫn chất nền dịch vụ của mình. I should not even be modifying the substrate I should be probably writing a statistics module and a de-prioritise module for that substrate loaded in a separate dll that can be loaded dynamically. Bây giờ thử nghiệm của tôi chỉ được tách biệt với dll này (thử nghiệm khai thác ngược) và khi sẵn sàng phát hành, tôi có thể thêm dll này và có thể thực hiện một thay đổi nhỏ về cấu hình, thế là xong, không có thử nghiệm hồi quy và không có rủi ro đối với mã hiện có, vì vậy không có lỗi sản xuất trong . Vì vậy, nhiều cơ sở mã điển hình sẽ yêu cầu thay đổi tất cả 1000 phương thức hoặc ít nhất là được đánh dấu cho hoạt động AOP. Thiết kế doanh nghiệp đòi hỏi phải dự đoán trước các yêu cầu kinh doanh "điên rồ" trong tương lai. Tôi thấy với hầu hết các ngôn ngữ kịch bản và thậm chí với Java, việc tìm kiếm các góc chèn sau này là gần như không thể. Ngay cả khi tôi có một con ngựa cái hoàn chỉnh trong C#, tôi có thể phát mã trực tiếp vào các phương thức bằng cách sử dụng sự phản chiếu, tôi chưa bao giờ thấy mức độ truy cập này trên ngôn ngữ kịch bản và ngay cả khi nó ở đó thì mã nguy hiểm sẽ được phát ra trong các hoạt động được biên dịch trong thời gian chạy . Đây chỉ là một ví dụ mà tôi có thể nghĩ ra khoảng 100. Tôi là một kiến ​​trúc sư kỹ thuật (khung và chất nền) vì vậy đây là nơi tôi "cứu" các nhà phát triển của mình khỏi việc dồn mình vào chân tường. Nếu tôi làm tốt, tôi có thể giảm công sức viết mã và thử nghiệm xuống 1% cho hệ thống "mã hóa hàng loạt". Có một cấp độ phát triển hoàn toàn khác mà hầu hết các nhà phát triển sẽ không bao giờ nhìn thấy hoặc đánh giá cao, điều này có nghĩa là họ không bao giờ được trang bị để đưa ra lựa chọn công nghệ phù hợp nhất

đấtT

P. P. S. "Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó". Bạn nghĩ gì về khả năng bảo trì? . Nó bao gồm chi phí thay đổi và đó là chi phí chính của doanh nghiệp cho một dự án sinh hoạt. Ví dụ. Tôi có một dịch vụ với 1000 phương thức công khai và doanh nghiệp yêu cầu tôi hủy ưu tiên tất cả các cuộc gọi kéo dài hơn 2 giây. Nếu tôi phải sửa đổi bất kỳ mã nào trong 1000 lệnh gọi đó thì mã của tôi có khả năng bảo trì kém nghiêm trọng. Những gì tôi nên làm là thay đổi một mã trong đường dẫn chất nền dịch vụ của mình. I should not even be modifying the substrate I should be probably writing a statistics module and a de-prioritise module for that substrate loaded in a separate dll that can be loaded dynamically. Bây giờ thử nghiệm của tôi chỉ được tách biệt với dll này (thử nghiệm khai thác ngược) và khi sẵn sàng phát hành, tôi có thể thêm dll này và có thể thực hiện một thay đổi nhỏ về cấu hình, thế là xong, không có thử nghiệm hồi quy và không có rủi ro đối với mã hiện có, vì vậy không có lỗi sản xuất trong . Vì vậy, nhiều cơ sở mã điển hình sẽ yêu cầu thay đổi tất cả 1000 phương thức hoặc ít nhất là được đánh dấu cho hoạt động AOP. Thiết kế doanh nghiệp đòi hỏi phải dự đoán trước các yêu cầu kinh doanh "điên rồ" trong tương lai. Tôi thấy với hầu hết các ngôn ngữ kịch bản và thậm chí với Java, việc tìm kiếm các góc chèn sau này là gần như không thể. Ngay cả khi tôi có một con ngựa cái hoàn chỉnh trong C#, tôi có thể phát mã trực tiếp vào các phương thức bằng cách sử dụng sự phản chiếu, tôi chưa bao giờ thấy mức độ truy cập này trên ngôn ngữ kịch bản và ngay cả khi nó ở đó thì mã nguy hiểm sẽ được phát ra trong các hoạt động được biên dịch trong thời gian chạy . Đây chỉ là một ví dụ mà tôi có thể nghĩ ra khoảng 100. Tôi là một kiến ​​trúc sư kỹ thuật (khung và chất nền) vì vậy đây là nơi tôi "cứu" các nhà phát triển của mình khỏi việc dồn mình vào chân tường. Nếu tôi làm tốt, tôi có thể giảm công sức viết mã và thử nghiệm xuống 1% cho hệ thống "mã hóa hàng loạt". Có một cấp độ phát triển hoàn toàn khác mà hầu hết các nhà phát triển sẽ không bao giờ nhìn thấy hoặc đánh giá cao, điều này có nghĩa là họ không bao giờ được trang bị để đưa ra lựa chọn công nghệ phù hợp nhất

Josh Morgan

Bài viết thú vị, tôi đã có khá nhiều kinh nghiệm trong các lĩnh vực khác nhưng tôi hơi mới đối với Node. js. Có vài điều tôi muốn làm sáng tỏ. Flash cũng luôn không đồng bộ, nó chỉ mô phỏng các luồng giống như âm thanh giống như nút thực hiện bằng cách sử dụng hàng đợi sự kiện. Tuy nhiên, tôi tin rằng đó là sự thiếu hiểu biết về kỹ thuật khi tuyên bố rằng việc tin tưởng quản lý luồng vào ngôn ngữ thế hệ thứ 3 hoặc thứ 4 sẽ tốt hơn là tin tưởng vào JRE được điều chỉnh tốt hoặc hệ điều hành được tối ưu hóa cho chipset đa lõi của nó. Làm thế nào chính xác để bạn nghĩ rằng chủ đề làm việc ở cấp độ thấp hơn dù sao? . Cũng là một sai lầm khi nói rằng một "sự kiện" mới không thêm bộ nhớ hoặc chu kỳ đồng hồ được đưa vào ngăn xếp chỉ vì các sự kiện đã nói được quản lý bởi một ngôn ngữ kịch bản được diễn giải thay vì C++ được biên dịch, tối ưu hóa. I'd bet my lunch that a well-written multi-threaded web application written in C or C++ will blow away any node. js hiệu suất khôn ngoan và thậm chí không cần truy cập vào máy chủ và kiến ​​trúc bộ xử lý đa lõi hiện tại của chúng. Nếu bạn có máy chủ 4 nhân hoặc 8 nhân chạy một luồng nút đơn. bạn chỉ bắn vào một pít-tông (khá mỉa mai khi Google gọi động cơ của họ là "V8" khi xem xét thực tế như vậy). Một điều khác cần nhận ra là trong khi Flash (hoặc thậm chí cả Java applet) chạy trong thời gian chạy của riêng chúng, thì nút cũng vậy -- nó chỉ bị ẩn đối với người dùng. Đó chẳng qua là động thái kinh doanh "tốt" (có lẽ là thù địch?) từ phía Google. Hãy trung thực ở đây, nếu tất cả các trình duyệt đều được cài đặt tự động Flash trên chúng và Apple thực sự hỗ trợ Flash trên thiết bị di động của họ, thì nút có lẽ sẽ không tồn tại ngày nay. Tôi có những lo ngại khác về bảo mật. Nó có loại bảo vệ nào chống lại kịch bản chéo trang và các cuộc tấn công khác? . ). Không có cảnh báo nào về bảo mật hoặc loại kết nối mà cửa sổ trình duyệt của tôi đang mở ra, chỉ phù hợp với hoạt động kinh doanh P2P của nó. phe hacker của tôi có thể có một ngày thực sự hay với những loại "tính năng" đó. Tôi nghi ngờ những thứ đó đã được thử nghiệm nhiều, điều đó có nghĩa là có rất nhiều chỗ cho lỗi và ở đâu có nhiều chỗ cho lỗi thì cũng có rất nhiều chỗ cho lỗ hổng. Nhưng này, ít nhất toàn bộ ngăn xếp của bạn đều ở cùng một ngôn ngữ. Có nghĩa là bạn có thể thuê những nhà phát triển ít kinh nghiệm hơn với số tiền ít hơn, phải không?

Josh Morgan

Bài viết thú vị, tôi đã có khá nhiều kinh nghiệm trong các lĩnh vực khác nhưng tôi hơi mới đối với Node. js. Có vài điều tôi muốn làm sáng tỏ. Flash cũng luôn không đồng bộ, nó chỉ mô phỏng các luồng giống như âm thanh giống như nút thực hiện bằng cách sử dụng hàng đợi sự kiện. Tuy nhiên, tôi tin rằng đó là sự thiếu hiểu biết về kỹ thuật khi tuyên bố rằng việc tin tưởng quản lý luồng vào ngôn ngữ thế hệ thứ 3 hoặc thứ 4 sẽ tốt hơn là tin tưởng vào JRE được điều chỉnh tốt hoặc hệ điều hành được tối ưu hóa cho chipset đa lõi của nó. Làm thế nào chính xác để bạn nghĩ rằng chủ đề làm việc ở cấp độ thấp hơn dù sao? . Cũng là một sai lầm khi nói rằng một "sự kiện" mới không thêm bộ nhớ hoặc chu kỳ đồng hồ được đưa vào ngăn xếp chỉ vì các sự kiện đã nói được quản lý bởi một ngôn ngữ kịch bản được diễn giải thay vì C++ được biên dịch, tối ưu hóa. I'd bet my lunch that a well-written multi-threaded web application written in C or C++ will blow away any node. js hiệu suất khôn ngoan và thậm chí không cần truy cập vào máy chủ và kiến ​​trúc bộ xử lý đa lõi hiện tại của chúng. Nếu bạn có máy chủ 4 nhân hoặc 8 nhân chạy một luồng nút đơn. bạn chỉ bắn vào một pít-tông (khá mỉa mai khi Google gọi động cơ của họ là "V8" khi xem xét thực tế như vậy). Một điều khác cần nhận ra là trong khi Flash (hoặc thậm chí cả Java applet) chạy trong thời gian chạy của riêng chúng, thì nút cũng vậy -- nó chỉ bị ẩn đối với người dùng. Đó chẳng qua là động thái kinh doanh "tốt" (có lẽ là thù địch?) từ phía Google. Hãy trung thực ở đây, nếu tất cả các trình duyệt đều được cài đặt tự động Flash trên chúng và Apple thực sự hỗ trợ Flash trên thiết bị di động của họ, thì nút có lẽ sẽ không tồn tại ngày nay. Tôi có những lo ngại khác về bảo mật. Nó có loại bảo vệ nào chống lại kịch bản chéo trang và các cuộc tấn công khác? . ). Không có cảnh báo nào về bảo mật hoặc loại kết nối mà cửa sổ trình duyệt của tôi đang mở ra, chỉ phù hợp với hoạt động kinh doanh P2P của nó. phe hacker của tôi có thể có một ngày thực sự hay với những loại "tính năng" đó. Tôi nghi ngờ những thứ đó đã được thử nghiệm nhiều, điều đó có nghĩa là có rất nhiều chỗ cho lỗi và ở đâu có nhiều chỗ cho lỗi thì cũng có rất nhiều chỗ cho lỗ hổng. Nhưng này, ít nhất toàn bộ ngăn xếp của bạn đều ở cùng một ngôn ngữ. Có nghĩa là bạn có thể thuê những nhà phát triển ít kinh nghiệm hơn với số tiền ít hơn, phải không?

iwebworld

Bài viết hay về Node JS, bạn có thể học Node JS trực tuyến tại http. //iwebworld. thông tin hoặc gửi email iwebworldinfo@gmail. com

iwebworld

Bài viết hay về Node JS, bạn có thể học Node JS trực tuyến tại http. //iwebworld. thông tin hoặc gửi email iwebworldinfo@gmail. com

Avinash Shah

Bạn có thể loại bỏ tất cả các cạm bẫy của JS bằng cách sử dụng siêu bộ của nó hay còn gọi là TypeScript

Avinash Shah

Bạn có thể loại bỏ tất cả các cạm bẫy của JS bằng cách sử dụng siêu bộ của nó hay còn gọi là TypeScript

đi trốn

Tl;dr Sử dụng nút để xử lý nặng IO và ủy quyền xử lý chuyên sâu CPU cho một cụm nút công nhân chuyên dụng (cơ sở dữ liệu cũ, xử lý phương tiện, v.v.). Đây không hẳn là thông tin mới. Tôi đã đề cập lại chủ đề này vào năm '12. http. //lập trình viên. giao dịch cổ phiếu. com/a/179499/1256 Lý tưởng nhất là các máy chủ HTTP và API hầu như không trạng thái (không bao gồm quản lý phiên) và dùng một lần. Chúng chỉ là một đường dẫn chức năng chuyển dữ liệu thô thành các biểu diễn tiêu hao. Bằng cách đó, các máy chủ dễ dàng cung cấp/hủy một cách linh hoạt để đáp ứng tính chất đột biến của nhu cầu. Tôi không chắc tại sao rất nhiều người bình luận lại tranh cãi kịch liệt ủng hộ kiến ​​trúc máy chủ đa mục đích có thể mở rộng theo chiều dọc. Về bản chất, tỷ lệ dọc sẽ luôn có giới hạn trên được xác định bởi dung lượng phần cứng. No matter how efficient the code is. Viết lên tường. Bạn có thể chi một số tiền lớn cho phần cứng và mất ngủ khi đặt câu hỏi về tính hợp lệ của đánh giá rủi ro (hay còn gọi là WAG) của bạn. At the end of the day, bare metal is a fixed asset. Trường hợp tốt nhất, nó đáp ứng nhu cầu dự kiến ​​và biện minh cho chi phí. Trường hợp xấu nhất, nó có giá cao hơn giá trị của nó hoặc thiếu khả năng đáp ứng nhu cầu. Ngoài ra, bạn có thể sử dụng điện toán phân tán và tự động hóa cơ sở hạ tầng để phát triển/thu hẹp tương ứng với nhu cầu. Đối với những người đang chiến đấu trong các cuộc chiến tôn giáo về ngôn ngữ nào là tốt nhất, nút. C#. java. Ai quan tâm. Cả 3 đều cho phép lập trình 'kiểu chức năng'. Cả 3, hỗ trợ xử lý không đồng bộ (nguyên bản hoặc thông qua tiện ích mở rộng). Tất cả 3 có thể được quản lý thông qua cung cấp. Cả 3 đều hoàn toàn hợp lệ để xây dựng cơ sở hạ tầng phân phối. Việc chọn sử dụng công cụ nào phụ thuộc vào chất lượng của các công cụ, liệu công cụ đó có được sử dụng để mở rộng cơ sở hạ tầng hiện có hay không và nhận thức của khách hàng. Xây dựng bất cứ thứ gì bạn giỏi xây dựng. Nếu bạn thực sự giỏi; . BTW, cảm ơn tác giả. Thật tuyệt khi thấy ai đó viết một bài viết toàn diện (và chủ yếu là khách quan) về chủ đề này

đi trốn

Tl;dr Sử dụng nút để xử lý nặng IO và ủy quyền xử lý chuyên sâu CPU cho một cụm nút công nhân chuyên dụng (cơ sở dữ liệu cũ, xử lý phương tiện, v.v.). Đây không hẳn là thông tin mới. Tôi đã đề cập lại chủ đề này vào năm '12. http. //lập trình viên. giao dịch cổ phiếu. com/a/179499/1256 Lý tưởng nhất là các máy chủ HTTP và API hầu như không trạng thái (không bao gồm quản lý phiên) và dùng một lần. Chúng chỉ là một đường dẫn chức năng chuyển dữ liệu thô thành các biểu diễn tiêu hao. Bằng cách đó, các máy chủ dễ dàng cung cấp/hủy một cách linh hoạt để đáp ứng tính chất đột biến của nhu cầu. Tôi không chắc tại sao rất nhiều người bình luận lại tranh cãi kịch liệt ủng hộ kiến ​​trúc máy chủ đa mục đích có thể mở rộng theo chiều dọc. Về bản chất, tỷ lệ dọc sẽ luôn có giới hạn trên được xác định bởi dung lượng phần cứng. No matter how efficient the code is. Viết lên tường. Bạn có thể chi một số tiền lớn cho phần cứng và mất ngủ khi đặt câu hỏi về tính hợp lệ của đánh giá rủi ro (hay còn gọi là WAG) của bạn. At the end of the day, bare metal is a fixed asset. Trường hợp tốt nhất, nó đáp ứng nhu cầu dự kiến ​​và biện minh cho chi phí. Trường hợp xấu nhất, nó có giá cao hơn giá trị của nó hoặc thiếu khả năng đáp ứng nhu cầu. Ngoài ra, bạn có thể sử dụng điện toán phân tán và tự động hóa cơ sở hạ tầng để phát triển/thu hẹp tương ứng với nhu cầu. Đối với những người đang chiến đấu trong các cuộc chiến tôn giáo về ngôn ngữ nào là tốt nhất, nút. C#. java. Ai quan tâm. Cả 3 đều cho phép lập trình 'kiểu chức năng'. Cả 3, hỗ trợ xử lý không đồng bộ (nguyên bản hoặc thông qua tiện ích mở rộng). Tất cả 3 có thể được quản lý thông qua cung cấp. Cả 3 đều hoàn toàn hợp lệ để xây dựng cơ sở hạ tầng phân phối. Việc chọn sử dụng công cụ nào phụ thuộc vào chất lượng của các công cụ, liệu công cụ đó có được sử dụng để mở rộng cơ sở hạ tầng hiện có hay không và nhận thức của khách hàng. Xây dựng bất cứ thứ gì bạn giỏi xây dựng. Nếu bạn thực sự giỏi; . BTW, cảm ơn tác giả. Thật tuyệt khi thấy ai đó viết một bài viết toàn diện (và chủ yếu là khách quan) về chủ đề này

đi trốn

Có, cả hai ngôn ngữ đều hỗ trợ mở rộng theo chiều ngang với cơ sở hạ tầng quản lý tin nhắn không đồng bộ. CQRS không là gì ngoài một mẫu triển khai API. CRUD là trường hợp sử dụng điển hình (đúng như vậy) nhưng Node không tự động giàn giáo 1. 1 ánh xạ giữa DB và CRUD (xem Rails/laravel/Django để biết điều đó). Nút hoàn toàn không phải là một khung, nó chỉ là một máy chủ HTTP. Bạn có thể tận dụng các khung (ví dụ Express) để làm cho cuộc sống dễ dàng hơn bằng cách cung cấp các giá trị mặc định lành mạnh và cấu trúc tốt hơn nhưng bạn vẫn phải chỉ định các tuyến API của mình theo cách thủ công. . Tiện ích mở rộng phản ứng ròng đã được chuyển sang JS. https. //www. npmjs. com/package/rx Trên thực tế, ngay cả LINQ cũng đã được chuyển sang JS (vâng, nghiêm túc đấy). http. //linqjs. mật mã. com/ "Bất kỳ ứng dụng nào có thể được viết bằng Javascript, sẽ được viết bằng Javascript" - Định luật Atwood ORM chỉ là một vấn đề vì chúng yêu cầu thêm một lớp trừu tượng từ dữ liệu cơ bản. Nếu (đọc khi nào) các mô hình dữ liệu cần thay đổi để thích ứng với nhu cầu kinh doanh, cả ORM và lược đồ cơ sở dữ liệu sẽ cần được cập nhật và kiểm tra để phản ánh các thay đổi. Đó thực sự không phải là vấn đề lớn nếu có một chiến lược cập nhật tốt. Đối với phần còn lại của nhận xét của bạn, bạn sẽ làm tốt nếu thỉnh thoảng bước ra khỏi vùng an toàn của mình để xem cách phát triển JS thực sự hoạt động. 1. Các lớp JS hiện được hỗ trợ thông qua ES6 (đồng thời, phía máy khách có sẵn thông qua polyfill). Các nguyên mẫu thực sự không khác nhiều so với các lớp về mặt đóng gói (ngoại trừ chúng linh hoạt hơn rất nhiều). Kiểm tra kiểu tĩnh thời gian biên dịch thậm chí còn được hỗ trợ thông qua TypeScript/Dart nếu đó là thứ làm nổi thuyền của bạn, thì đó không phải là mặc định. 2. TDD/BDD không phải là một tính năng dành riêng cho các ngôn ngữ được gõ tĩnh. Có rất nhiều khung thử nghiệm tuyệt vời có sẵn trong JS (cả phía máy chủ/phía máy khách). Chọn sở thích của bạn, thử nghiệm đơn vị (Mocha), thử nghiệm đơn vị theo hành vi (Chai), thử nghiệm api (SuperTest) và thử nghiệm tích hợp liên tục (TravisCI và nhiều thử nghiệm khác) đều được sử dụng rộng rãi trong cộng đồng. JSUnit (JS tương đương với JUnit/NUnit) thậm chí có sẵn nếu bạn bỏ lỡ kiểm tra đơn vị trong Java/. BỌC LƯỚI. Nếu bất cứ điều gì, thử nghiệm là một yêu cầu cơ bản của bất kỳ ứng dụng JS không tầm thường nào được đưa vào sản xuất vì bạn không có trình kiểm tra loại thời gian biên dịch để nắm trong tay. 3. Quy trình làm việc phức tạp? . Thực thi kiểu, linting, tạo tài liệu, giàn giáo, triển khai bằng một cú nhấp chuột, dịch ngôn ngữ, gói, xây dựng phân phối, quản lý gói/phụ thuộc, quản lý phát hành, v.v. 4. . co rúm lại. nếu bạn chỉ dựa vào hệ thống kiểm tra kiểu tĩnh thời gian biên dịch để xác thực đầu vào của người dùng, thì bạn đang làm sai. Xây dựng một lớp dữ liệu bằng bất kỳ ngôn ngữ nào đều yêu cầu các ràng buộc ở trên và ngoài những gì mà các loại mặc định cung cấp. Vì vậy, dù bằng cách nào, bạn sẽ phải mở rộng các mô hình dữ liệu của mình bằng các kiểm tra xác thực tùy chỉnh. The cool part about handling validation in JS is you can use the same routines to check user input on both the client/server-side. Ít trùng lặp nỗ lực hơn FTW. Trái ngược với những gì bạn nghĩ. Javascript thực sự là cách tiếp cận 'một kích thước phù hợp với tất cả' nếu bạn thích sử dụng nó như vậy. Nghiêm túc mà nói, bạn thậm chí có thể biên dịch C/C++ trực tiếp sang javascript bằng asm. js. Điều đó có nghĩa là bạn phải sử dụng nó? . Bất kỳ nhà phát triển nào có một chút ý thức sẽ không có lỗi với bạn khi chọn C #, đó là một ngôn ngữ tuyệt vời. Tôi có kinh nghiệm viết mã bằng nhiều ngôn ngữ, bao gồm xây dựng các ứng dụng máy tính để bàn không tầm thường bằng C#. Được lựa chọn, tôi muốn sử dụng Javascript hơn. Sự pha trộn của các ràng buộc lỏng lẻo hơn và các phong cách chức năng/mệnh lệnh/nguyên mẫu cho phép mức độ sáng tạo mà tôi chưa từng trải nghiệm trong bất kỳ ngôn ngữ nào khác. Các công cụ tuyệt vời, hệ thống mô-đun tuyệt vời và bản thân ngôn ngữ đang trở nên tốt hơn đáng kể với mỗi bản cập nhật

đi trốn

Có, cả hai ngôn ngữ đều hỗ trợ mở rộng theo chiều ngang với cơ sở hạ tầng quản lý tin nhắn không đồng bộ. CQRS không là gì ngoài một mẫu triển khai API. CRUD là trường hợp sử dụng điển hình (đúng như vậy) nhưng Node không tự động giàn giáo 1. 1 ánh xạ giữa DB và CRUD (xem Rails/laravel/Django để biết điều đó). Nút hoàn toàn không phải là một khung, nó chỉ là một máy chủ HTTP. Bạn có thể tận dụng các khung (ví dụ Express) để làm cho cuộc sống dễ dàng hơn bằng cách cung cấp các giá trị mặc định lành mạnh và cấu trúc tốt hơn nhưng bạn vẫn phải chỉ định các tuyến API của mình theo cách thủ công. . Tiện ích mở rộng phản ứng ròng đã được chuyển sang JS. https. //www. npmjs. com/package/rx Trên thực tế, ngay cả LINQ cũng đã được chuyển sang JS (vâng, nghiêm túc đấy). http. //linqjs. mật mã. com/ "Bất kỳ ứng dụng nào có thể được viết bằng Javascript, sẽ được viết bằng Javascript" - Định luật Atwood ORM chỉ là một vấn đề vì chúng yêu cầu thêm một lớp trừu tượng từ dữ liệu cơ bản. Nếu (đọc khi nào) các mô hình dữ liệu cần thay đổi để thích ứng với nhu cầu kinh doanh, cả ORM và lược đồ cơ sở dữ liệu sẽ cần được cập nhật và kiểm tra để phản ánh các thay đổi. Đó thực sự không phải là vấn đề lớn nếu có một chiến lược cập nhật tốt. Đối với phần còn lại của nhận xét của bạn, bạn sẽ làm tốt nếu thỉnh thoảng bước ra khỏi vùng an toàn của mình để xem cách phát triển JS thực sự hoạt động. 1. Các lớp JS hiện được hỗ trợ thông qua ES6 (đồng thời, phía máy khách có sẵn thông qua polyfill). Các nguyên mẫu thực sự không khác nhiều so với các lớp về mặt đóng gói (ngoại trừ chúng linh hoạt hơn rất nhiều). Kiểm tra kiểu tĩnh thời gian biên dịch thậm chí còn được hỗ trợ thông qua TypeScript/Dart nếu đó là thứ làm nổi thuyền của bạn, thì đó không phải là mặc định. 2. TDD/BDD không phải là một tính năng dành riêng cho các ngôn ngữ được gõ tĩnh. Có rất nhiều khung thử nghiệm tuyệt vời có sẵn trong JS (cả phía máy chủ/phía máy khách). Chọn sở thích của bạn, thử nghiệm đơn vị (Mocha), thử nghiệm đơn vị theo hành vi (Chai), thử nghiệm api (SuperTest) và thử nghiệm tích hợp liên tục (TravisCI và nhiều thử nghiệm khác) đều được sử dụng rộng rãi trong cộng đồng. JSUnit (JS tương đương với JUnit/NUnit) thậm chí có sẵn nếu bạn bỏ lỡ kiểm tra đơn vị trong Java/. BỌC LƯỚI. Nếu bất cứ điều gì, thử nghiệm là một yêu cầu cơ bản của bất kỳ ứng dụng JS không tầm thường nào được đưa vào sản xuất vì bạn không có trình kiểm tra loại thời gian biên dịch để nắm trong tay. 3. Quy trình làm việc phức tạp? . Thực thi kiểu, linting, tạo tài liệu, giàn giáo, triển khai bằng một cú nhấp chuột, dịch ngôn ngữ, gói, xây dựng phân phối, quản lý gói/phụ thuộc, quản lý phát hành, v.v. 4. . co rúm lại. nếu bạn chỉ dựa vào hệ thống kiểm tra kiểu tĩnh thời gian biên dịch để xác thực đầu vào của người dùng, thì bạn đang làm sai. Xây dựng một lớp dữ liệu bằng bất kỳ ngôn ngữ nào đều yêu cầu các ràng buộc ở trên và ngoài những gì mà các loại mặc định cung cấp. Vì vậy, dù bằng cách nào, bạn sẽ phải mở rộng các mô hình dữ liệu của mình bằng các kiểm tra xác thực tùy chỉnh. The cool part about handling validation in JS is you can use the same routines to check user input on both the client/server-side. Ít trùng lặp nỗ lực hơn FTW. Trái ngược với những gì bạn nghĩ. Javascript thực sự là cách tiếp cận 'một kích thước phù hợp với tất cả' nếu bạn thích sử dụng nó như vậy. Nghiêm túc mà nói, bạn thậm chí có thể biên dịch C/C++ trực tiếp sang javascript bằng asm. js. Điều đó có nghĩa là bạn phải sử dụng nó? . Bất kỳ nhà phát triển nào có một chút ý thức sẽ không có lỗi với bạn khi chọn C #, đó là một ngôn ngữ tuyệt vời. Tôi có kinh nghiệm viết mã bằng nhiều ngôn ngữ, bao gồm xây dựng các ứng dụng máy tính để bàn không tầm thường bằng C#. Được lựa chọn, tôi muốn sử dụng Javascript hơn. Sự pha trộn của các ràng buộc lỏng lẻo hơn và các phong cách chức năng/mệnh lệnh/nguyên mẫu cho phép mức độ sáng tạo mà tôi chưa từng trải nghiệm trong bất kỳ ngôn ngữ nào khác. Các công cụ tuyệt vời, hệ thống mô-đun tuyệt vời và bản thân ngôn ngữ đang trở nên tốt hơn đáng kể với mỗi bản cập nhật

đi trốn

Tải tệp lên. http. //howtonode. org/really-simple-file-uploads "Tất cả các hoạt động I/O được xử lý bởi Node. js đang sử dụng nhiều luồng nội bộ; . " http. // stackoverflow. com/a/22981768/290340 Libuv sử dụng nhóm luồng để xử lý các hoạt động I/O (tệp, ổ cắm, v.v.) theo cách không đồng bộ. Trong đó hầu hết các ngôn ngữ bị chặn theo mặc định trong các hoạt động I/O nặng của CPU, thì Node không. Nó chỉ kích hoạt một sự kiện khi thao tác I/O hoàn thành trên worker thread. Thư mục hoạt động. https. //github. com/gheeres/node-activedirectory https. //github. com/auth0/hộ chiếu-windowsauth

đi trốn

Tải tệp lên. http. //howtonode. org/really-simple-file-uploads "Tất cả các hoạt động I/O được xử lý bởi Node. js đang sử dụng nhiều luồng nội bộ; . " http. // stackoverflow. com/a/22981768/290340 Libuv sử dụng nhóm luồng để xử lý các hoạt động I/O (tệp, ổ cắm, v.v.) theo cách không đồng bộ. Trong đó hầu hết các ngôn ngữ bị chặn theo mặc định trong các hoạt động I/O nặng của CPU, thì Node không. Nó chỉ kích hoạt một sự kiện khi thao tác I/O hoàn thành trên worker thread. Thư mục hoạt động. https. //github. com/gheeres/node-activedirectory https. //github. com/auth0/hộ chiếu-windowsauth

đi trốn

Điểm khác biệt là Node mặc định là không đồng bộ Vì vậy, số lượng nhà phát triển thực hiện lập trình không đồng bộ bằng các ngôn ngữ khác là thiểu số nên họ không được đại diện nhiều. "Tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ có sẵn khác. " Không nói dối đâu, lúc đầu sử dụng Node là. Thách thức để nói ít nhất. Làm quen với async-by-default không phải là một quá trình chuyển đổi dễ dàng. Phần hay của Node là, trọng tâm chính của nền tảng là xây dựng máy chủ/máy khách để hệ sinh thái có rất nhiều công cụ mạnh mẽ để làm bất cứ điều gì liên quan đến phát triển web. ". have better standard libraries, tools and resources. " I'm not sure what gave you that impression. Nó không sử dụng cách tiếp cận thư viện lớp cơ sở nguyên khối-mọi thứ và nhà bếp. Bản thân lõi rất nhỏ nhưng đó là một lợi ích vì nó nhẹ hơn nhiều khi triển khai. Nó cũng bao gồm một trình quản lý gói rất mạnh mẽ, đầy đủ tính năng theo mặc định, do đó bạn sẽ phải thêm các phụ thuộc mà dự án của bạn cần. NPM (Trình quản lý gói nút) có hơn 200 nghìn gói và đang tiếp tục tăng. Vì phần lớn các mô-đun được phát triển độc lập với lõi, chúng lặp lại và cải thiện nhanh hơn nhiều so với các thư viện lõi tương đương trong các ngôn ngữ khác. Các phụ thuộc được quản lý cục bộ trên cơ sở từng dự án trong gói. tập tin json. Thông thường, việc tác giả mô-đun yêu cầu gói của họ phải được cài đặt trên toàn cầu là một hình thức tồi. Việc cài đặt các gói cục bộ sẽ ngăn xung đột phiên bản ở cấp độ toàn cầu và đảm bảo rằng -- khi bạn cài đặt một gói -- mọi thứ cần thiết để sử dụng mô-đun đều được bao gồm. Thoạt nhìn, nó có vẻ không hiệu quả vì nhiều phụ thuộc có thể có các bản sao của cùng một phụ thuộc phụ (hoặc phụ phụ thuộc, v.v.) nhưng so với chi phí bao gồm một thư viện tiêu chuẩn lớn, dung lượng lưu trữ là không đáng kể. Quy trình làm việc để thiết lập một dự án là. - sao chép nguồn - chạy 'npm install' NPM sẽ tự động tải xuống và cài đặt tất cả các phụ thuộc (bao gồm sub-deps, sub-sub-deps, v.v.). Vì các phụ thuộc (và các phiên bản cụ thể của chúng) được xác định rõ ràng trong cấu hình, nên bạn không cần kiểm tra chúng trong kiểm soát nguồn. Ngoài ra, với ES6 (bao gồm trình tải mô-đun ES6 mới) sắp được phát hành, một JSPM mới (Trình quản lý gói JavaScript) đã được tạo để quản lý các phụ thuộc javascript phía máy khách. Nhập mô-đun trong trình duyệt cuối cùng đã được chính thức hóa trong thông số ngôn ngữ, vì vậy Bower và nhiều tiêu chuẩn giả tải mô-đun (ví dụ: AMD, CommonJS, UMD) sẽ biến mất

đi trốn

Điểm khác biệt là Node mặc định là không đồng bộ Vì vậy, số lượng nhà phát triển thực hiện lập trình không đồng bộ bằng các ngôn ngữ khác là thiểu số nên họ không được đại diện nhiều. "Tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ có sẵn khác. " Không nói dối đâu, lúc đầu sử dụng Node là. Thách thức để nói ít nhất. Làm quen với async-by-default không phải là một quá trình chuyển đổi dễ dàng. Phần hay của Node là, trọng tâm chính của nền tảng là xây dựng máy chủ/máy khách để hệ sinh thái có rất nhiều công cụ mạnh mẽ để làm bất cứ điều gì liên quan đến phát triển web. ". have better standard libraries, tools and resources. " I'm not sure what gave you that impression. Nó không sử dụng cách tiếp cận thư viện lớp cơ sở nguyên khối-mọi thứ và nhà bếp. Bản thân lõi rất nhỏ nhưng đó là một lợi ích vì nó nhẹ hơn nhiều khi triển khai. Nó cũng bao gồm một trình quản lý gói rất mạnh mẽ, đầy đủ tính năng theo mặc định, do đó bạn sẽ phải thêm các phụ thuộc mà dự án của bạn cần. NPM (Trình quản lý gói nút) có hơn 200 nghìn gói và đang tiếp tục tăng. Vì phần lớn các mô-đun được phát triển độc lập với lõi, chúng lặp lại và cải thiện nhanh hơn nhiều so với các thư viện lõi tương đương trong các ngôn ngữ khác. Các phụ thuộc được quản lý cục bộ trên cơ sở từng dự án trong gói. tập tin json. Thông thường, việc tác giả mô-đun yêu cầu gói của họ phải được cài đặt trên toàn cầu là một hình thức tồi. Việc cài đặt các gói cục bộ sẽ ngăn xung đột phiên bản ở cấp độ toàn cầu và đảm bảo rằng -- khi bạn cài đặt một gói -- mọi thứ cần thiết để sử dụng mô-đun đều được bao gồm. Thoạt nhìn, nó có vẻ không hiệu quả vì nhiều phụ thuộc có thể có các bản sao của cùng một phụ thuộc phụ (hoặc phụ phụ thuộc, v.v.) nhưng so với chi phí bao gồm một thư viện tiêu chuẩn lớn, dung lượng lưu trữ là không đáng kể. Quy trình làm việc để thiết lập một dự án là. - sao chép nguồn - chạy 'npm install' NPM sẽ tự động tải xuống và cài đặt tất cả các phụ thuộc (bao gồm sub-deps, sub-sub-deps, v.v.). Vì các phụ thuộc (và các phiên bản cụ thể của chúng) được xác định rõ ràng trong cấu hình, nên bạn không cần kiểm tra chúng trong kiểm soát nguồn. Ngoài ra, với ES6 (bao gồm trình tải mô-đun ES6 mới) sắp được phát hành, một JSPM mới (Trình quản lý gói JavaScript) đã được tạo để quản lý các phụ thuộc javascript phía máy khách. Nhập mô-đun trong trình duyệt cuối cùng đã được chính thức hóa trong thông số ngôn ngữ, vì vậy Bower và nhiều tiêu chuẩn giả tải mô-đun (ví dụ: AMD, CommonJS, UMD) sẽ biến mất

đấtT

Như đã nói ở trên, các ngôn ngữ OO hiện đại có rất nhiều tùy chọn để chính thức hóa và kiểm soát mã của bạn cũng như các giải pháp mà các ngôn ngữ kịch bản không có. That's just the plain truth, no amount of griping is going to change that. Quan điểm của tôi là có rất nhiều nhà phát triển chọn công nghệ theo mức độ phổ biến hơn là sự phù hợp, đó là điều khiến họ hâm mộ các chàng trai. Công cụ phù hợp cho công việc phù hợp, áp dụng trong mọi giao dịch ngoại trừ phát triển phần mềm. Nhưng đó có lẽ là do hầu hết các nhà phát triển không phải là "Người thợ" thực thụ, mà là "Người tự làm" được tôn vinh hơn. Ngành công nghiệp đầy những người nghiệp dư, những người thậm chí không biết đủ để biết rằng họ không biết gì. Họ nghĩ bởi vì họ có thể viết câu lệnh if và vòng lặp while nên họ giỏi. công nghệ

đấtT

Như đã nói ở trên, các ngôn ngữ OO hiện đại có rất nhiều tùy chọn để chính thức hóa và kiểm soát mã của bạn cũng như các giải pháp mà các ngôn ngữ kịch bản không có. That's just the plain truth, no amount of griping is going to change that. Quan điểm của tôi là có rất nhiều nhà phát triển chọn công nghệ theo mức độ phổ biến hơn là sự phù hợp, đó là điều khiến họ hâm mộ các chàng trai. Công cụ phù hợp cho công việc phù hợp, áp dụng trong mọi giao dịch ngoại trừ phát triển phần mềm. Nhưng đó có lẽ là do hầu hết các nhà phát triển không phải là "Người thợ" thực thụ, mà là "Người tự làm" được tôn vinh hơn. Ngành công nghiệp đầy những người nghiệp dư, những người thậm chí không biết đủ để biết rằng họ không biết gì. Họ nghĩ bởi vì họ có thể viết câu lệnh if và vòng lặp while nên họ giỏi. công nghệ

đi trốn

Các hoạt động I/O cấp hệ thống (chẳng hạn như tệp, ổ cắm) trong Nút được xử lý bởi libuv sử dụng nhóm luồng nền. Sự khác biệt là, luồng chính có thể kích hoạt và quên tác vụ đối với luồng nền và luồng nền sẽ thông báo cho luồng chính (thông qua kích hoạt một sự kiện) khi thao tác hoàn tất. Ngay cả khi xử lý luồng nền, thực hiện nhiều thao tác I/O cũng không mở rộng tốt. Đối với các tác vụ sử dụng nhiều CPU trong thời gian dài (mã hóa hình ảnh/phim cũ), việc giảm tải các tác vụ cho các nút worker vẫn được ưu tiên hơn. Trong hầu hết các ngôn ngữ, các thao tác I/O được xử lý theo cách đồng bộ, vì vậy nếu chúng yêu cầu được thực hiện trên luồng chính, chúng sẽ chặn thực thi cho đến khi hoàn thành. Lý do bạn không thấy một khoảng dừng đáng chú ý trong giao diện người dùng khi điều này xảy ra là do giao diện người dùng không đồng bộ/dựa trên sự kiện và chạy trên một chuỗi tách biệt với ngữ cảnh chính

đi trốn

Các hoạt động I/O cấp hệ thống (chẳng hạn như tệp, ổ cắm) trong Nút được xử lý bởi libuv sử dụng nhóm luồng nền. Sự khác biệt là, luồng chính có thể kích hoạt và quên tác vụ đối với luồng nền và luồng nền sẽ thông báo cho luồng chính (thông qua kích hoạt một sự kiện) khi thao tác hoàn tất. Ngay cả khi xử lý luồng nền, thực hiện nhiều thao tác I/O cũng không mở rộng tốt. Đối với các tác vụ sử dụng nhiều CPU trong thời gian dài (mã hóa hình ảnh/phim cũ), việc giảm tải các tác vụ cho các nút worker vẫn được ưu tiên hơn. Trong hầu hết các ngôn ngữ, các thao tác I/O được xử lý theo cách đồng bộ, vì vậy nếu chúng yêu cầu được thực hiện trên luồng chính, chúng sẽ chặn thực thi cho đến khi hoàn thành. Lý do bạn không thấy một khoảng dừng đáng chú ý trong giao diện người dùng khi điều này xảy ra là do giao diện người dùng không đồng bộ/dựa trên sự kiện và chạy trên một chuỗi tách biệt với ngữ cảnh chính

đi trốn

Không có gì ngăn cản bạn hiển thị API dưới dạng microservice. WebKit chỉ cho phép bạn chạy ứng dụng khách JS gốc. Tôi có thể sai nhưng theo những gì tôi hiểu, không giống như trình duyệt, ứng dụng khách webkit không được hộp cát nghiêm ngặt để bạn có thể thực hiện các cuộc gọi hệ thống (ví dụ: mở/lưu tệp mà không cần người dùng nhập)

đi trốn

Không có gì ngăn cản bạn hiển thị API dưới dạng microservice. WebKit chỉ cho phép bạn chạy ứng dụng khách JS gốc. Tôi có thể sai nhưng theo những gì tôi hiểu, không giống như trình duyệt, ứng dụng khách webkit không được hộp cát nghiêm ngặt để bạn có thể thực hiện các cuộc gọi hệ thống (ví dụ: mở/lưu tệp mà không cần người dùng nhập)

đấtT

Tôi nghĩ rằng bạn đã đưa ra quan điểm của tôi cho tôi, nói ra những điều vô nghĩa thiếu suy nghĩ, cảm xúc, với rất ít sự thật, từ một tâm trí quá cuồng tín về một thứ mà nó thậm chí không thể nhìn thấy những thất bại của nó. Có vẻ như bạn đã đưa ra một vài giả định hợp lý về những gì tôi biết và không biết, tôi đã làm Javascript được 20 năm, tôi biết những hạn chế của nó, tôi có thể làm việc hiệu quả với hơn 30 ngôn ngữ, tôi sử dụng những gì phù hợp, . Bạn cần trưởng thành hoặc tìm một ngành mới để làm việc. Những người như bạn là vấn đề với Phát triển phần mềm, không biết gì về những người thậm chí không thể tạo ra một trường hợp cho một công nghệ, chứ đừng nói đến việc sử dụng một công nghệ. Please stay away from the keyboard and do the rest of us a favour

đấtT

Tôi nghĩ rằng bạn đã đưa ra quan điểm của tôi cho tôi, nói ra những điều vô nghĩa thiếu suy nghĩ, cảm xúc, với rất ít sự thật, từ một tâm trí quá cuồng tín về một thứ mà nó thậm chí không thể nhìn thấy những thất bại của nó. Có vẻ như bạn đã đưa ra một vài giả định hợp lý về những gì tôi biết và không biết, tôi đã làm Javascript được 20 năm, tôi biết những hạn chế của nó, tôi có thể làm việc hiệu quả với hơn 30 ngôn ngữ, tôi sử dụng những gì phù hợp, . Bạn cần trưởng thành hoặc tìm một ngành mới để làm việc. Những người như bạn là vấn đề với Phát triển phần mềm, không biết gì về những người thậm chí không thể tạo ra một trường hợp cho một công nghệ, chứ đừng nói đến việc sử dụng một công nghệ. Please stay away from the keyboard and do the rest of us a favour

đi trốn

Bạn có sử dụng kiểm soát phiên bản với quy trình làm việc tiêu chuẩn (quy trình làm việc Gitflow cũ) nơi các nhà phát triển thực hiện các thay đổi trên các nhánh tính năng và mã được xem xét ngang hàng trước khi được hợp nhất không? . Tất cả các ví dụ có sẵn trực tuyến đều bị hỏng khá nhiều nên tôi đã theo dõi quá trình phát triển dự án trên Github. Tỷ lệ mà các nhà phát triển cốt lõi đang đạt được trên cơ sở mã thực sự đáng chú ý. Điều tuyệt vời hơn nữa là mọi PR đều được kiểm tra đơn vị và kiểm tra tích hợp liên tục đủ tốt để mọi bản phát hành được đảm bảo hoạt động đầy đủ (theo như họ đã triển khai cho đến nay)

đi trốn

Bạn có sử dụng kiểm soát phiên bản với quy trình làm việc tiêu chuẩn (quy trình làm việc Gitflow cũ) nơi các nhà phát triển thực hiện các thay đổi trên các nhánh tính năng và mã được xem xét ngang hàng trước khi được hợp nhất không? . Tất cả các ví dụ có sẵn trực tuyến đều bị hỏng khá nhiều nên tôi đã theo dõi quá trình phát triển dự án trên Github. Tỷ lệ mà các nhà phát triển cốt lõi đang đạt được trên cơ sở mã thực sự đáng chú ý. Điều tuyệt vời hơn nữa là mọi PR đều được kiểm tra đơn vị và kiểm tra tích hợp liên tục đủ tốt để mọi bản phát hành được đảm bảo hoạt động đầy đủ (theo như họ đã triển khai cho đến nay)

đi trốn

Làm theo những gì Tracker1 đang nói. Linting tương đương với việc kiểm tra thời gian biên dịch trong JS. Tôi thậm chí còn sử dụng tiện ích mở rộng Sublime hiển thị lỗi kẻ nói dối trực tiếp trong trình soạn thảo khi tôi đang viết mã. Nếu bạn muốn kiểm tra chặt chẽ hơn, bạn có thể thêm trình kiểm tra kiểu, chẳng hạn như 'bán tiêu chuẩn', đảm bảo kiểu mã trên cơ sở toàn dự án. Điều đó có nghĩa là dấu cách không phải tab, thụt lề 2 dấu cách, hàm nhất quán, dấu ngoặc nhọn, v.v. Kiểm tra kiểu tốt cho các lỗi bề ngoài (biến chưa khởi tạo cũ, nhánh chết, giá trị không hợp lệ) nhưng cuối cùng bạn sẽ phải xác minh mã không có lỗi logic thông qua kiểm tra đơn vị, kiểm tra tích hợp liên tục, kiểm tra api

đi trốn

Làm theo những gì Tracker1 đang nói. Linting tương đương với việc kiểm tra thời gian biên dịch trong JS. Tôi thậm chí còn sử dụng tiện ích mở rộng Sublime hiển thị lỗi kẻ nói dối trực tiếp trong trình soạn thảo khi tôi đang viết mã. Nếu bạn muốn kiểm tra chặt chẽ hơn, bạn có thể thêm trình kiểm tra kiểu, chẳng hạn như 'bán tiêu chuẩn', đảm bảo kiểu mã trên cơ sở toàn dự án. Điều đó có nghĩa là dấu cách không phải tab, thụt lề 2 dấu cách, hàm nhất quán, dấu ngoặc nhọn, v.v. Kiểm tra kiểu tốt cho các lỗi bề ngoài (biến chưa khởi tạo cũ, nhánh chết, giá trị không hợp lệ) nhưng cuối cùng bạn sẽ phải xác minh mã không có lỗi logic thông qua kiểm tra đơn vị, kiểm tra tích hợp liên tục, kiểm tra api

đi trốn

Nút sử dụng I/O dựa trên sự kiện không đồng bộ thông qua libuv (bao gồm một nhóm luồng dành riêng cho các yêu cầu I/O). Luồng chính hoàn toàn không bị chặn trong quá trình hoạt động I/O. Nó hoạt động giống như cách cụm ngoại trừ nó được tích hợp vào Node. Kiểm tra một trong những bài thuyết trình trên libuv để biết thêm chi tiết

đi trốn

Nút sử dụng I/O dựa trên sự kiện không đồng bộ thông qua libuv (bao gồm một nhóm luồng dành riêng cho các yêu cầu I/O). Luồng chính hoàn toàn không bị chặn trong quá trình hoạt động I/O. Nó hoạt động giống như cách cụm ngoại trừ nó được tích hợp vào Node. Kiểm tra một trong những bài thuyết trình trên libuv để biết thêm chi tiết

đi trốn

Hiệu suất khôn ngoan, PayPal dường như nghĩ những điều tốt về Node http. //đồng ghi chú. blogspot. com/2013/12/paypals-nodejs-versus-java-benchmark. html Để bảo mật, mô-đun 'cors' có thể cắm vào Express và có thể được sử dụng cho tất cả các nội dung kiểm soát CORS thông thường. Mô-đun 'mũ bảo hiểm' -- cũng có thể cắm vào Express -- hiển thị một bộ nhỏ các tính năng để bảo vệ chống lại những người dùng độc hại bao gồm bảo vệ tập lệnh chéo trang bổ sung. Tôi không chắc mình có gọi một nhà phát triển Fullstack JS là 'thiếu kinh nghiệm' hay không. Có một sự hiểu biết vững chắc về nhiều lĩnh vực trong một hệ sinh thái phát triển không ngừng phát triển thật khó chịu. bạn biết đấy, "10 năm kinh nghiệm so với 1 năm kinh nghiệm 10 lần"

đi trốn

Hiệu suất khôn ngoan, PayPal dường như nghĩ những điều tốt về Node http. //đồng ghi chú. blogspot. com/2013/12/paypals-nodejs-versus-java-benchmark. html Để bảo mật, mô-đun 'cors' có thể cắm vào Express và có thể được sử dụng cho tất cả các nội dung kiểm soát CORS thông thường. Mô-đun 'mũ bảo hiểm' -- cũng có thể cắm vào Express -- hiển thị một bộ nhỏ các tính năng để bảo vệ chống lại những người dùng độc hại bao gồm bảo vệ tập lệnh chéo trang bổ sung. Tôi không chắc mình có gọi một nhà phát triển Fullstack JS là 'thiếu kinh nghiệm' hay không. Có một sự hiểu biết vững chắc về nhiều lĩnh vực trong một hệ sinh thái phát triển không ngừng phát triển thật khó chịu. bạn biết đấy, "10 năm kinh nghiệm so với 1 năm kinh nghiệm 10 lần"

Josh Morgan

Nút. js thậm chí đã không tồn tại được 10 năm (thật buồn cười khi tôi đã thấy các bài đăng công việc thực sự yêu cầu 10 năm kinh nghiệm với nó). Tôi hiểu rằng việc theo kịp sự phát triển của công nghệ là một thách thức và sau 20 năm nữa, tôi có thể nói với bạn rằng vào thời điểm bạn hoàn toàn cảm thấy thoải mái với bất kỳ "full stack" nào thì nó sẽ ít liên quan hơn vì công nghệ luôn phát triển. Sẽ không có gì thay đổi được điều đó, đó chỉ là cách mọi thứ vận hành. Tuy nhiên, bạn không thể thực sự có bánh của bạn và ăn nó ở đó. Công nghệ mới ít được thử nghiệm hơn và do đó kém an toàn hơn, nhưng công nghệ cũ hơn không có nhiều tính năng. Luôn luôn có một sự đánh đổi ở đó. Bất cứ ai tuyên bố khác đang bán cho bạn thứ gì đó

Josh Morgan

Nút. js thậm chí đã không tồn tại được 10 năm (thật buồn cười khi tôi đã thấy các bài đăng công việc thực sự yêu cầu 10 năm kinh nghiệm với nó). Tôi hiểu rằng việc theo kịp sự phát triển của công nghệ là một thách thức và sau 20 năm nữa, tôi có thể nói với bạn rằng vào thời điểm bạn hoàn toàn cảm thấy thoải mái với bất kỳ "full stack" nào thì nó sẽ ít liên quan hơn vì công nghệ luôn phát triển. Sẽ không có gì thay đổi được điều đó, đó chỉ là cách mọi thứ vận hành. Tuy nhiên, bạn không thể thực sự có bánh của bạn và ăn nó ở đó. Công nghệ mới ít được thử nghiệm hơn và do đó kém an toàn hơn, nhưng công nghệ cũ hơn không có nhiều tính năng. Luôn luôn có một sự đánh đổi ở đó. Bất cứ ai tuyên bố khác đang bán cho bạn thứ gì đó

Anil Verma

Tôi được bán trên Node. JS (nếu ứng dụng của bạn đang xây dựng các ứng dụng mạng có khả năng mở rộng cao), Node. JS là con đường để đi vào năm 2015. No wonder why so many startups and large corporations are adopting it. C ++, Java, Ruby và Python có vị trí của chúng trong các lĩnh vực tương ứng. Các công ty và sản phẩm mới sẽ được xây dựng trên nhiều ngôn ngữ. Tôi dự đoán việc áp dụng ROR sẽ vẫn cao trong những năm tới để xây dựng các ứng dụng web (đơn giản vì các nhà phát triển ROR dễ dàng có sẵn và thời gian đưa ra thị trường quá ngắn). Bài báo xuất sắc mặc dù Tomislav

Anil Verma

Tôi được bán trên Node. JS (nếu ứng dụng của bạn đang xây dựng các ứng dụng mạng có khả năng mở rộng cao), Node. JS là con đường để đi vào năm 2015. No wonder why so many startups and large corporations are adopting it. C ++, Java, Ruby và Python có vị trí của chúng trong các lĩnh vực tương ứng. Các công ty và sản phẩm mới sẽ được xây dựng trên nhiều ngôn ngữ. Tôi dự đoán việc áp dụng ROR sẽ vẫn cao trong những năm tới để xây dựng các ứng dụng web (đơn giản vì các nhà phát triển ROR dễ dàng có sẵn và thời gian đưa ra thị trường quá ngắn). Bài báo xuất sắc mặc dù Tomislav

Daniel Jawna

rất đúng. Công việc của tôi là bảo trì các ứng dụng cũ, thường là truy cập SQL Server dB's + ms hoặc giao diện người dùng php. Những thứ này thường được làm bởi "cháu trai giỏi máy tính". Không có khóa ngoại, nhưng chức năng ngày + giờ tùy chỉnh. bài viết của bạn là tâm trạng của tôi chính xác

Daniel Jawna

rất đúng. Công việc của tôi là bảo trì các ứng dụng cũ, thường là truy cập SQL Server dB's + ms hoặc giao diện người dùng php. Những thứ này thường được làm bởi "cháu trai giỏi máy tính". Không có khóa ngoại, nhưng chức năng ngày + giờ tùy chỉnh. bài viết của bạn là tâm trạng của tôi chính xác

JPoet

Tôi thấy Java rất kém hiệu quả và rất tốn kém đối với nhiều công việc tẻ nhạt ở mức độ thấp. C ++ dành cho các lập trình viên có thể xử lý truy cập/con trỏ bộ nhớ. Hầu hết các lập trình viên của công ty không thể. Ngày trước, bạn có PL/1 và C cho kỹ sư phần mềm và COBOL cho lập trình viên công nghệ thông tin

JPoet

Tôi thấy Java rất kém hiệu quả và rất tốn kém đối với nhiều công việc tẻ nhạt ở mức độ thấp. C ++ dành cho các lập trình viên có thể xử lý truy cập/con trỏ bộ nhớ. Hầu hết các lập trình viên của công ty không thể. Ngày trước, bạn có PL/1 và C cho kỹ sư phần mềm và COBOL cho lập trình viên công nghệ thông tin

joselie castañeda

cảm ơn. điều này rất hữu ích vì tôi sẽ tạo một ứng dụng doanh nghiệp tính toán nặng. i think i'll try node. js trên ứng dụng khác. bây giờ, tôi sẽ sử dụng ruby ​​​​trên đường ray

joselie castañeda

cảm ơn. điều này rất hữu ích vì tôi sẽ tạo một ứng dụng doanh nghiệp tính toán nặng. i think i'll try node. js trên ứng dụng khác. bây giờ, tôi sẽ sử dụng ruby ​​​​trên đường ray

Túlio Spuri

Khi bài báo này được viết?

Túlio Spuri

Khi bài báo này được viết?

vũ khí

Bài báo tuyệt vời

vũ khí

Bài báo tuyệt vời

Olivier

Cảm ơn vì bài viết này, tôi nghĩ rằng lập luận về cùng một ngôn ngữ cho front và dev là điều tồi tệ nhất mà tôi có thể nghe hoặc đọc. Có tổ chức và mã hóa tốt với js là những điều khủng khiếp hơn xuất hiện trong một nhóm. Tôi làm việc từ năm ngoái trong dự án phụ trợ và đôi khi điều này sẽ được mã hóa với khung trưởng thành như django, mất quá nhiều thời gian để hiểu hàng trăm lỗi. Nơi mongodb cảm thấy mát mẻ? . Tôi thực sự nghĩ rằng nút js là một trò đùa lớn và không hay lắm. Trình quản lý gói cung cấp cho chúng tôi một số gói thú vị để vá và ẩn mặt xấu của nút nhưng không có gì để làm về địa ngục gọi lại. Cuối cùng, mã trông giống như một hộp cát lớn hơn tôi không muốn mở tệp để gỡ lỗi hoặc thêm một số dòng mã. Vì vậy, kết luận của tôi là dành cho ứng dụng nhỏ tại sao không nhưng đối với dự án lớn và phát triển không sử dụng cũng như nodejs và mongodb. Trân trọng

Olivier

Cảm ơn vì bài viết này, tôi nghĩ rằng lập luận về cùng một ngôn ngữ cho front và dev là điều tồi tệ nhất mà tôi có thể nghe hoặc đọc. Có tổ chức và mã hóa tốt với js là những điều khủng khiếp hơn xuất hiện trong một nhóm. Tôi làm việc từ năm ngoái trong dự án phụ trợ và đôi khi điều này sẽ được mã hóa với khung trưởng thành như django, mất quá nhiều thời gian để hiểu hàng trăm lỗi. Nơi mongodb cảm thấy mát mẻ? . Tôi thực sự nghĩ rằng nút js là một trò đùa lớn và không hay lắm. Trình quản lý gói cung cấp cho chúng tôi một số gói thú vị để vá và ẩn mặt xấu của nút nhưng không có gì để làm về địa ngục gọi lại. Cuối cùng, mã trông giống như một hộp cát lớn hơn tôi không muốn mở tệp để gỡ lỗi hoặc thêm một số dòng mã. Vì vậy, kết luận của tôi là dành cho ứng dụng nhỏ tại sao không nhưng đối với dự án lớn và phát triển không sử dụng cũng như nodejs và mongodb. Trân trọng

buffonomics

Đây là một nhận xét khá thiếu thông tin vì ES6 vẫn hoạt động tốt như một năm trước. Bên cạnh OO từ ES6, còn có TypeScript bổ sung thêm OO cấp doanh nghiệp hơn và có thể thực thi kiểu gõ tĩnh cho JavaScript. Thích. NET được biên dịch thành clr thô, TypeScript cũng có thể được "phiên mã" thành Javascript thô. Hiện tại, NodeJS cho phép thực hiện gần như tất cả những điều này với việc sử dụng tài nguyên máy chủ thậm chí còn tốt hơn và không bị khóa hệ điều hành. Hãy nghĩ đến việc cắt giảm chi phí cơ sở hạ tầng của bạn hơn 2000% vì bạn thực sự không cần phải mở rộng quy mô theo chiều dọc hoặc trả tiền cho những chi phí đó. NET trên mỗi nút quy mô. Ngay cả khi bạn đang đi theo con đường Mono, lol. Tôi sẽ để bạn tự nghiên cứu cách so sánh đó. Fintech companies like Paypal that know a thing or 2 about load are happily doing great things with node as well so I highly doubt this comment of yours comes from a place of knowledge about what the NodeJS eco-system truly has to offer the enterprising product built in "this era", with a focus in micro-services (in the true-est sense of the word) and not "monolithic services" as you might be more used to. Ngoài ra, bất kể bạn có thể có ý kiến ​​cá nhân nào về ORM, thực tế hợp lý của tất cả là ORMS sử dụng nhiều tài nguyên bộ nhớ hơn mức cần thiết để chạy phụ trợ. Họ cũng đánh vào nguồn dữ liệu của bạn nhiều hơn mức cần thiết. Bạn cũng đã nói điều gì đó liên quan đến bộ nhớ đệm và ORM mà tôi đoán bạn đang đề cập đến bộ nhớ đệm cấp ORM (e. g. Bộ đệm L1/2 trong chế độ Ngủ đông). Tôi hy vọng bạn hiểu rằng bạn KHÔNG THỰC SỰ CẦN ORM để thực hiện bộ nhớ đệm cho bạn. Bạn có thể làm điều này bằng cách sử dụng các công cụ tách rời hiệu quả và đẹp mắt. và tại đó linh hoạt hơn. Điều quan trọng cần ghi nhớ là ngay cả bây giờ, vẫn có người bảo vệ Fortran là công cụ thực sự duy nhất để xây dựng phần mềm. Mọi thứ di chuyển khá nhanh trong ngành này. Niềm tự hào là điều dễ hiểu, nhưng lời khuyên của tôi dành cho bạn là hãy tham gia vào ít nhất 1 thế giới công nghệ mới nhiều nhất là vài năm một lần. Bạn sẽ ở lại có liên quan và cảm ơn tôi sau

buffonomics

Đây là một nhận xét khá thiếu thông tin vì ES6 vẫn hoạt động tốt như một năm trước. Bên cạnh OO từ ES6, còn có TypeScript bổ sung thêm OO cấp doanh nghiệp hơn và có thể thực thi kiểu gõ tĩnh cho JavaScript. Thích. NET được biên dịch thành clr thô, TypeScript cũng có thể được "phiên mã" thành Javascript thô. Hiện tại, NodeJS cho phép thực hiện gần như tất cả những điều này với việc sử dụng tài nguyên máy chủ thậm chí còn tốt hơn và không bị khóa hệ điều hành. Hãy nghĩ đến việc cắt giảm chi phí cơ sở hạ tầng của bạn hơn 2000% vì bạn thực sự không cần phải mở rộng quy mô theo chiều dọc hoặc trả tiền cho những chi phí đó. NET trên mỗi nút quy mô. Ngay cả khi bạn đang đi theo con đường Mono, lol. Tôi sẽ để bạn tự nghiên cứu cách so sánh đó. Fintech companies like Paypal that know a thing or 2 about load are happily doing great things with node as well so I highly doubt this comment of yours comes from a place of knowledge about what the NodeJS eco-system truly has to offer the enterprising product built in "this era", with a focus in micro-services (in the true-est sense of the word) and not "monolithic services" as you might be more used to. Ngoài ra, bất kể bạn có thể có ý kiến ​​cá nhân nào về ORM, thực tế hợp lý của tất cả là ORMS sử dụng nhiều tài nguyên bộ nhớ hơn mức cần thiết để chạy phụ trợ. Họ cũng đánh vào nguồn dữ liệu của bạn nhiều hơn mức cần thiết. Bạn cũng đã nói điều gì đó liên quan đến bộ nhớ đệm và ORM mà tôi đoán bạn đang đề cập đến bộ nhớ đệm cấp ORM (e. g. Bộ đệm L1/2 trong chế độ Ngủ đông). Tôi hy vọng bạn hiểu rằng bạn KHÔNG THỰC SỰ CẦN ORM để thực hiện bộ nhớ đệm cho bạn. Bạn có thể làm điều này bằng cách sử dụng các công cụ tách rời hiệu quả và đẹp mắt. và tại đó linh hoạt hơn. Điều quan trọng cần ghi nhớ là ngay cả bây giờ, vẫn có người bảo vệ Fortran là công cụ thực sự duy nhất để xây dựng phần mềm. Mọi thứ di chuyển khá nhanh trong ngành này. Niềm tự hào là điều dễ hiểu, nhưng lời khuyên của tôi dành cho bạn là hãy tham gia vào ít nhất 1 thế giới công nghệ mới nhiều nhất là vài năm một lần. Bạn sẽ ở lại có liên quan và cảm ơn tôi sau

biên tập

Tôi thực sự muốn có thể dùng thử Node. js nhưng thật khó để có được một cái gì đó đang chạy. Cài đặt một ứng dụng "đơn giản" luôn dẫn đến một danh sách những việc bạn cần làm, cài đặt toàn cầu (không phải lúc nào cũng có thể), chỉnh sửa tệp, cố gắng tìm hiểu ý nghĩa của các nhà phát triển chết tiệt trong hướng dẫn ít ỏi của họ. Nó sẽ nhanh chóng trở nên tồi tệ nếu bạn làm sai một điều nhỏ nhất. Nếu nó tuyệt vời như vậy, tại sao không ai tìm ra cách tạo các trình cài đặt đơn giản với thứ này?

biên tập

Tôi thực sự muốn có thể dùng thử Node. js nhưng thật khó để có được một cái gì đó đang chạy. Cài đặt một ứng dụng "đơn giản" luôn dẫn đến một danh sách những việc bạn cần làm, cài đặt toàn cầu (không phải lúc nào cũng có thể), chỉnh sửa tệp, cố gắng tìm hiểu ý nghĩa của các nhà phát triển chết tiệt trong hướng dẫn ít ỏi của họ. Nó sẽ nhanh chóng trở nên tồi tệ nếu bạn làm sai một điều nhỏ nhất. Nếu nó tuyệt vời như vậy, tại sao không ai tìm ra cách tạo các trình cài đặt đơn giản với thứ này?

Alexis Menest

Nền tảng blog ma https. //github. com/TryGhost/Ghost/blob/master/gói. json

Alexis Menest

Nền tảng blog ma https. //github. com/TryGhost/Ghost/blob/master/gói. json

David

Vâng, thật tuyệt nếu có một buổi hẹn hò. Tôi cho rằng họ không hiển thị nó vì họ biết mọi người có thành kiến ​​như thế nào đối với thông tin mới - nhưng sẽ không có ý nghĩa gì nếu che giấu nó trong một bài báo về công nghệ đang phát triển nhanh chóng

David

Vâng, thật tuyệt nếu có một buổi hẹn hò. Tôi cho rằng họ không hiển thị nó vì họ biết mọi người có thành kiến ​​như thế nào đối với thông tin mới - nhưng sẽ không có ý nghĩa gì nếu che giấu nó trong một bài báo về công nghệ đang phát triển nhanh chóng

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com thì sao?

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com thì sao?

chaitanya

Này Tomislav, Bài báo tuyệt vời. Tôi muốn biết rằng nếu giả sử tôi muốn nhận đầu ra phần cứng bên ngoài trong ứng dụng của mình, e. g, máy quét hoặc chữ ký điện tử (nếu người dùng đang thực hiện chữ ký điện tử hoặc nhận bản sao được quét từ máy quét), thì tôi có thể truy cập trực tiếp vào ứng dụng của mình không?

chaitanya

Này Tomislav, Bài báo tuyệt vời. Tôi muốn biết rằng nếu giả sử tôi muốn nhận đầu ra phần cứng bên ngoài trong ứng dụng của mình, e. g, máy quét hoặc chữ ký điện tử (nếu người dùng đang thực hiện chữ ký điện tử hoặc nhận bản sao được quét từ máy quét), thì tôi có thể truy cập trực tiếp vào ứng dụng của mình không?

Misha R

TypeScript is syntactic sugar wrapper on top of standard JavaScript and compiles into standard JavaScript. Nó được phát minh để làm cho mã có thể bảo trì được và cho phép nó được sử dụng giống như một ngôn ngữ lập trình thực sự. Cho rằng bạn phải sử dụng JS khi thích hợp, nó làm cho việc viết nó trở nên quen thuộc hơn với các lập trình viên thực thụ và làm cho nó có thể bảo trì được. Điều đó nói rằng, mọi thứ JS và Node đều phù hợp với các ứng dụng web mỏng, nhẹ cần được kết hợp với nhau một cách nhanh chóng và hiệu quả, cho những thứ như ASP. NET, JSP, Ruby, v.v. hơi quá mức cần thiết. Tin rằng người ta không thể sử dụng Node thần kỳ mới cho mọi thứ chỉ vì một anh chàng có thể viết cả front và back end là nghiệp dư

Misha R

TypeScript is syntactic sugar wrapper on top of standard JavaScript and compiles into standard JavaScript. Nó được phát minh để làm cho mã có thể bảo trì được và cho phép nó được sử dụng giống như một ngôn ngữ lập trình thực sự. Cho rằng bạn phải sử dụng JS khi thích hợp, nó làm cho việc viết nó trở nên quen thuộc hơn với các lập trình viên thực thụ và làm cho nó có thể bảo trì được. Điều đó nói rằng, mọi thứ JS và Node đều phù hợp với các ứng dụng web mỏng, nhẹ cần được kết hợp với nhau một cách nhanh chóng và hiệu quả, cho những thứ như ASP. NET, JSP, Ruby, v.v. hơi quá mức cần thiết. Tin rằng người ta không thể sử dụng Node thần kỳ mới cho mọi thứ chỉ vì một anh chàng có thể viết cả front và back end là nghiệp dư

ellisgl

Đóng gói một ngôn ngữ bằng một ngôn ngữ khác mà bạn phải dịch sẽ thêm chi phí. Ngoài ra có những thứ không dịch được, chỉ là trong cuộc sống thực, dịch giữa các ngôn ngữ, bạn mất một cái gì đó. Trong trường hợp này, bạn mất tốc độ (phải dịch từ cái này sang cái khác) và tối ưu hóa, vì lý do một. ORM không làm tất cả. Ban đầu, tôi dành cho ORM, sau đó tôi tìm hiểu sâu về nó và bạn kết thúc với câu "Tôi làm điều này như thế nào?", "Ồ, bạn không thể dễ dàng, bạn phải thực hiện 10 truy vấn khác", hoặc bạn kết thúc . ORM đơn giản là "Chọn blah blah từ bảng trong đó x = y". Yếu tố đổi thưởng nhỏ duy nhất của một số ORM là chúng sẽ chuyển đổi ngôn ngữ của chúng sang bất kỳ DB nào. Nhưng nếu bạn được trả tiền để làm việc trên một ứng dụng cấp doanh nghiệp, thì bạn chỉ đang xử lý 1 - 3 cơ sở dữ liệu, được sử dụng cho những thứ riêng biệt. Nếu bạn có 500 nhân viên và 10.000 khách hàng, ORM có thể bị tắc nghẽn

ellisgl

Đóng gói một ngôn ngữ bằng một ngôn ngữ khác mà bạn phải dịch sẽ thêm chi phí. Ngoài ra có những thứ không dịch được, chỉ là trong cuộc sống thực, dịch giữa các ngôn ngữ, bạn mất một cái gì đó. Trong trường hợp này, bạn mất tốc độ (phải dịch từ cái này sang cái khác) và tối ưu hóa, vì lý do một. ORM không làm tất cả. Ban đầu, tôi dành cho ORM, sau đó tôi tìm hiểu sâu về nó và bạn kết thúc với câu "Tôi làm điều này như thế nào?", "Ồ, bạn không thể dễ dàng, bạn phải thực hiện 10 truy vấn khác", hoặc bạn kết thúc . ORM đơn giản là "Chọn blah blah từ bảng trong đó x = y". Yếu tố đổi thưởng nhỏ duy nhất của một số ORM là chúng sẽ chuyển đổi ngôn ngữ của chúng sang bất kỳ DB nào. Nhưng nếu bạn được trả tiền để làm việc trên một ứng dụng cấp doanh nghiệp, thì bạn chỉ đang xử lý 1 - 3 cơ sở dữ liệu, được sử dụng cho những thứ riêng biệt. Nếu bạn có 500 nhân viên và 10.000 khách hàng, ORM có thể bị tắc nghẽn

quả cầu Nils

Này, có thư viện/công cụ nào bạn đã sử dụng để tạo đồ họa không?

quả cầu Nils

Này, có thư viện/công cụ nào bạn đã sử dụng để tạo đồ họa không?

Praveen kumar Pamani

Cảm ơn bạn vì bài viết này, tôi sẽ đề xuất bài viết này nếu mọi người muốn biết node là gì và chúng ta có thể làm gì với nodejs

Praveen kumar Pamani

Cảm ơn bạn vì bài viết này, tôi sẽ đề xuất bài viết này nếu mọi người muốn biết node là gì và chúng ta có thể làm gì với nodejs

dohkoo

Bài viết hay, cảm ơn vì cái nhìn tổng quan. http. //www. steshadoku. com

dohkoo

Bài viết hay, cảm ơn vì cái nhìn tổng quan. http. //www. steshadoku. com

subkuchsell. com

cảm ơn vì bài viết tuyệt vời thực sự rất hữu ích để hiểu nút. js subkuchsell. com

subkuchsell. com

cảm ơn vì bài viết tuyệt vời thực sự rất hữu ích để hiểu nút. js subkuchsell. com

Tomislav Capan

Vâng, đây là sự thật, bài viết được tác giả và xuất bản vào tháng 8 năm 2013. (xin lỗi vì đã xác nhận muộn như vậy, chưa thấy điều này sớm hơn)

Tomislav Capan

Vâng, đây là sự thật, bài viết được tác giả và xuất bản vào tháng 8 năm 2013. (xin lỗi vì đã xác nhận muộn như vậy, chưa thấy điều này sớm hơn)

người chơi gôn484

Trong vũ trụ nào Mongodb có thể được gọi là DB đối tượng? . Đó là DB hướng tài liệu không phải DB hướng đối tượng. I just don't want any of the kiddies to get confused

người chơi gôn484

Trong vũ trụ nào Mongodb có thể được gọi là DB đối tượng? . Đó là DB hướng tài liệu không phải DB hướng đối tượng. I just don't want any of the kiddies to get confused

người chơi gôn484

Chúng tôi đã chuyển sang một ngôn ngữ cho phụ trợ và giao diện người dùng nhưng chúng tôi quyết định giữ lại ngôn ngữ chạy nhanh như chớp trong thời gian chạy và có loại an toàn cũng như hỗ trợ các ORM tiêu chuẩn với tính năng tải chậm, v.v. , Chúng tôi không muốn vứt bỏ tất cả những thứ đó, đó là điều bạn phải làm khi sử dụng giải pháp JS trên phần phụ trợ của mình. Java trên phần phụ trợ là điều không cần bàn cãi (miễn là bạn không quá kỹ sư và làm phức tạp quá mức ứng dụng của mình với bộ nhớ và CPU đang làm cạn kiệt Spring). Chìa khóa để sử dụng Java cho giao diện người dùng là sử dụng một khung công tác Java thực hiện tất cả JS cho bạn - vì vậy bạn có thể sống trong một thế giới không phải xử lý JS và gắn bó với mã được biên dịch, an toàn về kiểu chữ, phù hợp với doanh nghiệp. Giải pháp này cũng có thể mở rộng - J2SE đã hỗ trợ phân cụm trong gần hai thập kỷ nay. Một khung giao diện người dùng Java như vậy đáp ứng tất cả các nhu cầu JS của chúng tôi và cung cấp cho chúng tôi tất cả tính năng 'cập nhật một phần' với mô hình điều khiển sự kiện AJAX với tùy chọn websockets là Wicket

người chơi gôn484

Chúng tôi đã chuyển sang một ngôn ngữ cho phụ trợ và giao diện người dùng nhưng chúng tôi quyết định giữ lại ngôn ngữ chạy nhanh như chớp trong thời gian chạy và có loại an toàn cũng như hỗ trợ các ORM tiêu chuẩn với tính năng tải chậm, v.v. , Chúng tôi không muốn vứt bỏ tất cả những thứ đó, đó là điều bạn phải làm khi sử dụng giải pháp JS trên phần phụ trợ của mình. Java trên phần phụ trợ là điều không cần bàn cãi (miễn là bạn không quá kỹ sư và làm phức tạp quá mức ứng dụng của mình với bộ nhớ và CPU đang làm cạn kiệt Spring). Chìa khóa để sử dụng Java cho giao diện người dùng là sử dụng một khung công tác Java thực hiện tất cả JS cho bạn - vì vậy bạn có thể sống trong một thế giới không phải xử lý JS và gắn bó với mã được biên dịch, an toàn về kiểu chữ, phù hợp với doanh nghiệp. Giải pháp này cũng có thể mở rộng - J2SE đã hỗ trợ phân cụm trong gần hai thập kỷ nay. Một khung giao diện người dùng Java như vậy đáp ứng tất cả các nhu cầu JS của chúng tôi và cung cấp cho chúng tôi tất cả tính năng 'cập nhật một phần' với mô hình điều khiển sự kiện AJAX với tùy chọn websockets là Wicket

Rumana Amin

Xin chào Tomislav, bài viết của bạn rất hay và nhiều thông tin. Nó đã giúp tôi rất nhiều để hiểu về Node. js và nó sử dụng

Rumana Amin

Xin chào Tomislav, bài viết của bạn rất hay và nhiều thông tin. Nó đã giúp tôi rất nhiều để hiểu về Node. js và nó sử dụng

đại bàng chiến tranh

Câu trả lời đơn giản là không sử dụng Node. js cho điều đó. Bạn đang thiếu phần nào trong đó? . dễ dàng. Thực hiện một câu lệnh THAM GIA lớn trên một triệu hàng trên RDBS? . Bác sĩ phẫu thuật không làm việc với cưa máy. Các lập trình viên cũng không nên

đại bàng chiến tranh

Câu trả lời đơn giản là không sử dụng Node. js cho điều đó. Bạn đang thiếu phần nào trong đó? . dễ dàng. Thực hiện một câu lệnh THAM GIA lớn trên một triệu hàng trên RDBS? . Bác sĩ phẫu thuật không làm việc với cưa máy. Các lập trình viên cũng không nên

người chơi gôn484

You underate ORM as most of the people who have never built an OO system with a decent highly performant ORM that rocks do (and by 'decent' ORM I'm NOT referring to the ORM most people think of using, Hibernate. )

người chơi gôn484

You underate ORM as most of the people who have never built an OO system with a decent highly performant ORM that rocks do (and by 'decent' ORM I'm NOT referring to the ORM most people think of using, Hibernate. )

người chơi gôn484

Tôi đồng ý - bài viết này và các nhận xét liên quan của các chàng trai hâm mộ JS xác nhận nỗi sợ hãi của tôi rằng hầu hết các ứng dụng JavaScript phải có các mô hình miền thiếu máu (https. //martinfowler. com/bliki/AnemiaDomainModel. html) khá tầm thường và hầu như ít biểu thức hơn - tất cả công việc sẽ được thực hiện trong logic nghiệp vụ tách rời (không được đóng gói và chắc chắn không đa hình)

người chơi gôn484

Tôi đồng ý - bài viết này và các nhận xét liên quan của các chàng trai hâm mộ JS xác nhận nỗi sợ hãi của tôi rằng hầu hết các ứng dụng JavaScript phải có các mô hình miền thiếu máu (https. //martinfowler. com/bliki/AnemiaDomainModel. html) khá tầm thường và hầu như ít biểu thức hơn - tất cả công việc sẽ được thực hiện trong logic nghiệp vụ tách rời (không được đóng gói và chắc chắn không đa hình)

người chơi gôn484

Tôi đoán trải nghiệm của bạn với 'ORM' chỉ giới hạn ở Hibernate. Tôi đã có một trải nghiệm tương tự cho đến khi tôi nghĩ rằng phải có những ORM tốt hơn ngoài kia - hãy nhìn xung quanh - những ORM khác tồn tại

người chơi gôn484

Tôi đoán trải nghiệm của bạn với 'ORM' chỉ giới hạn ở Hibernate. Tôi đã có một trải nghiệm tương tự cho đến khi tôi nghĩ rằng phải có những ORM tốt hơn ngoài kia - hãy nhìn xung quanh - những ORM khác tồn tại

người chơi gôn484

Điểm hay Adin - Tôi sắp làm những cái giống nhau. Liên quan đến tuyên bố của bài báo rằng các khung truyền thống "sinh ra một luồng mới cho mỗi kết nối (yêu cầu)". Vì vậy, rất sai. Chắc hẳn đã khiến nhiều người tức giận khi thấy một lỗi như vậy mà a) tác giả biết rõ ràng là sai và kiên trì với quan điểm hoặc b) chưa bao giờ sử dụng bất kỳ khung phụ trợ nào khác và vì vậy không nhận ra rằng mình đã sai. Sự kết hợp của kết nối với yêu cầu cũng rất thú vị. Kiến thức của anh ấy không mở rộng để hiểu khái niệm kết nối "keep lives". Một kết nối không có mối quan hệ 1-1 với các yêu cầu như anh ấy đề xuất. Loại quan điểm sai lệch, méo mó này về mức độ thông minh, trưởng thành, phát triển cao của các khuôn khổ (ví dụ:. , Java/Tomcat và tôi chắc chắn. net/ASP) khiến tôi cảm thấy như bài viết này bị vấy bẩn và không đại diện cho sự thật về các lựa chọn thay thế. Liên quan đến việc loại bỏ tâm lý Yêu cầu/Phản hồi - nhiều khung hiện tại cũng đã thực hiện điều này và tạo ra một kiến ​​trúc hướng thành phần hỗ trợ các bản cập nhật dựa trên mô hình không đồng bộ. ví dụ. , Java Wicket or Angular JS. Nó gần giống như chạy JS (một loại ngôn ngữ không an toàn, không phải OO - nếu bạn là người tin tưởng rằng tính kế thừa 'nguyên mẫu' thủ công, tự lắp ráp theo tinh thần OO thực sự) trên máy chủ không phải là một khái niệm có đủ giá trị mà không cần vặn vẹo . Nó là như vậy hoặc có thể nó là như vậy

người chơi gôn484

Điểm hay Adin - Tôi sắp làm những cái giống nhau. Liên quan đến tuyên bố của bài báo rằng các khung truyền thống "sinh ra một luồng mới cho mỗi kết nối (yêu cầu)". Vì vậy, rất sai. Chắc hẳn đã khiến nhiều người tức giận khi thấy một lỗi như vậy mà a) tác giả biết rõ ràng là sai và kiên trì với quan điểm hoặc b) chưa bao giờ sử dụng bất kỳ khung phụ trợ nào khác và vì vậy không nhận ra rằng mình đã sai. Sự kết hợp của kết nối với yêu cầu cũng rất thú vị. Kiến thức của anh ấy không mở rộng để hiểu khái niệm kết nối "keep lives". Một kết nối không có mối quan hệ 1-1 với các yêu cầu như anh ấy đề xuất. Loại quan điểm sai lệch, méo mó này về mức độ thông minh, trưởng thành, phát triển cao của các khuôn khổ (ví dụ:. , Java/Tomcat và tôi chắc chắn. net/ASP) khiến tôi cảm thấy như bài viết này bị vấy bẩn và không đại diện cho sự thật về các lựa chọn thay thế. Liên quan đến việc loại bỏ tâm lý Yêu cầu/Phản hồi - nhiều khung hiện tại cũng đã thực hiện điều này và tạo ra một kiến ​​trúc hướng thành phần hỗ trợ các bản cập nhật dựa trên mô hình không đồng bộ. ví dụ. , Java Wicket or Angular JS. Nó gần giống như chạy JS (một loại ngôn ngữ không an toàn, không phải OO - nếu bạn là người tin tưởng rằng tính kế thừa 'nguyên mẫu' thủ công, tự lắp ráp theo tinh thần OO thực sự) trên máy chủ không phải là một khái niệm có đủ giá trị mà không cần vặn vẹo . Nó là như vậy hoặc có thể nó là như vậy

người chơi gôn484

Không phải mọi khách hàng có phiên hoạt động đều cần được phân bổ chuỗi riêng của họ - các chuỗi được chia sẻ và mỗi người dùng chỉ cần một chuỗi cho các yêu cầu dịch vụ. Các yêu cầu đến trong các đợt ngắn và không cần phải kết nối một luồng quá lâu nếu mã phía sau đang thực thi bằng ngôn ngữ được biên dịch, tối ưu hóa cao và cơ sở dữ liệu nhanh. Vì lý do này, bạn không thể nói "Hệ thống A có thể hỗ trợ 10.000 luồng do đó hệ thống chỉ có thể hỗ trợ 10.000 máy khách". Số lượng khách hàng được hỗ trợ là các đơn đặt hàng lớn hơn số lượng luồng có sẵn do tính đa dạng. Hầu hết các giao diện người dùng, nếu được viết tốt, chỉ 'điện thoại về nhà' cho máy chủ khi thực sự cần thiết - không phải "mọi lúc"

người chơi gôn484

Không phải mọi khách hàng có phiên hoạt động đều cần được phân bổ chuỗi riêng của họ - các chuỗi được chia sẻ và mỗi người dùng chỉ cần một chuỗi cho các yêu cầu dịch vụ. Các yêu cầu đến trong các đợt ngắn và không cần phải kết nối một luồng quá lâu nếu mã phía sau đang thực thi bằng ngôn ngữ được biên dịch, tối ưu hóa cao và cơ sở dữ liệu nhanh. Vì lý do này, bạn không thể nói "Hệ thống A có thể hỗ trợ 10.000 luồng do đó hệ thống chỉ có thể hỗ trợ 10.000 máy khách". Số lượng khách hàng được hỗ trợ là các đơn đặt hàng lớn hơn số lượng luồng có sẵn do tính đa dạng. Hầu hết các giao diện người dùng, nếu được viết tốt, chỉ 'điện thoại về nhà' cho máy chủ khi thực sự cần thiết - không phải "mọi lúc"

người chơi gôn484

Nó giống như nút. js mọi người nghĩ rằng JS là ngôn ngữ duy nhất hỗ trợ đồng thời (mặc dù họ quảng bá giải pháp máy chủ web một luồng -WTF?) và không chặn I/O - tất nhiên không phải vậy nhưng bạn có vẻ rất hào hứng với những thứ như vậy mà tôi có thể

người chơi gôn484

Nó giống như nút. js mọi người nghĩ rằng JS là ngôn ngữ duy nhất hỗ trợ đồng thời (mặc dù họ quảng bá giải pháp máy chủ web một luồng -WTF?) và không chặn I/O - tất nhiên không phải vậy nhưng bạn có vẻ rất hào hứng với những thứ như vậy mà tôi có thể

Tomislav Capan

Tất nhiên bạn hiểu đây là hình minh họa. Trong thực tế, đó là một nhóm luồng, bị giới hạn bởi bộ nhớ khả dụng và có độ lớn theo thứ tự nhỏ hơn những gì giao diện sự kiện có thể hỗ trợ. Cảm ơn vì nhận xét, mặc dù

Tomislav Capan

Tất nhiên bạn hiểu đây là hình minh họa. Trong thực tế, đó là một nhóm luồng, bị giới hạn bởi bộ nhớ khả dụng và có độ lớn theo thứ tự nhỏ hơn những gì giao diện sự kiện có thể hỗ trợ. Cảm ơn vì nhận xét, mặc dù

Trưởng khoa Radcliffe

Chết tiệt, đây là một oldie nhưng goodie. Tôi nói chuyện như thế này, và có thể mượn slide của bạn. Theo những ý định ban đầu này của nút để thực hiện những điều tuyệt vời như ghi db theo hàng đợi và đẩy máy chủ, thật đáng ngạc nhiên là hầu hết các ứng dụng nút ngày nay vẫn được xây dựng trên mô hình yêu cầu/phản hồi và chờ đợi ghi db một cách đồng bộ (nhưng không theo khối)

Trưởng khoa Radcliffe

Chết tiệt, đây là một oldie nhưng goodie. Tôi nói chuyện như thế này, và có thể mượn slide của bạn. Theo những ý định ban đầu này của nút để thực hiện những điều tuyệt vời như ghi db theo hàng đợi và đẩy máy chủ, thật đáng ngạc nhiên là hầu hết các ứng dụng nút ngày nay vẫn được xây dựng trên mô hình yêu cầu/phản hồi và chờ đợi ghi db một cách đồng bộ (nhưng không theo khối)

Ulyana

Nội thất tuyệt vời, cảm ơn vì bài viết. Node. js có rất nhiều lợi thế. nó nhẹ, hiệu quả và cung cấp khả năng sử dụng Javascript trên cả giao diện người dùng và phụ trợ mở ra những khả năng mới. Tuy nhiên, nó cũng có nhược điểm bạn cần lưu ý. Chúng tôi đã cố gắng mô tả một số trong bài viết https. //www. chuyên gia mạng. co/blog/pros-cons-use-node. js-backend Ý kiến ​​​​của bạn sẽ được đánh giá cao

Ulyana

Nội thất tuyệt vời, cảm ơn vì bài viết. Node. js có rất nhiều lợi thế. nó nhẹ, hiệu quả và cung cấp khả năng sử dụng Javascript trên cả giao diện người dùng và phụ trợ mở ra những khả năng mới. Tuy nhiên, nó cũng có nhược điểm bạn cần lưu ý. Chúng tôi đã cố gắng mô tả một số trong bài viết https. //www. chuyên gia mạng. co/blog/pros-cons-use-node. js-backend Ý kiến ​​​​của bạn sẽ được đánh giá cao

Maq Said

Điều tuyệt vời. MongoDB tôi chưa bao giờ khám phá. Bạn có thể nói thêm về nó không và tại sao nó hoạt động tốt với Node. js

Maq Said

Điều tuyệt vời. MongoDB tôi chưa bao giờ khám phá. Bạn có thể nói thêm về nó không và tại sao nó hoạt động tốt với Node. js

Misha Kov

Đây chính xác là bài viết tôi đang tìm kiếm, Ví dụ về nơi Node. js có thể được sử dụng. Cảm ơn

Misha Kov

Đây chính xác là bài viết tôi đang tìm kiếm, Ví dụ về nơi Node. js có thể được sử dụng. Cảm ơn

Jessica Barnes

Node.js has the concept of asynchronous execution of Input-output based events through a thread pool. And it concentrates in execution and topping well for low-CPU, highly I/O-bound operations. Just starting to work on Node.js will allow a developers to analyze how to exploit it for maximum performance.

Jessica Barnes

Node.js has the concept of asynchronous execution of Input-output based events through a thread pool. And it concentrates in execution and topping well for low-CPU, highly I/O-bound operations. Just starting to work on Node.js will allow a developers to analyze how to exploit it for maximum performance.

Janguk James Lee

Đây là một bài viết khá hay thúc đẩy tôi tiếp nhận Node. js

Janguk James Lee

Đây là một bài viết khá hay thúc đẩy tôi tiếp nhận Node. js

Magdalena Mbn

nếu họ không thể học cách xử lý con trỏ thì họ không thể lập trình

Magdalena Mbn

nếu họ không thể học cách xử lý con trỏ thì họ không thể lập trình

web đặt hàng

TwaT - bạn có thể cho tôi biết quán rượu / quán bar nào bạn ghé thăm để tôi có thể tránh bạn không. Tôi sẽ không ngạc nhiên nếu bạn OrgASM khi bạn đọc lại bình luận của mình

web đặt hàng

TwaT - bạn có thể cho tôi biết quán rượu / quán bar nào bạn ghé thăm để tôi có thể tránh bạn không. Tôi sẽ không ngạc nhiên nếu bạn OrgASM khi bạn đọc lại bình luận của mình

philippe

Tôi muốn có nhiều Java hơn cho phía máy khách hơn là nhiều Javascript hơn cho phía máy chủ. Tái cấu trúc Javascript là một cơn ác mộng. Bạn nào làm phần mềm 4000 - 10000 class như mình thì biết mình đang nói cái gì. Tôi thấy việc quản lý luồng là một điểm cộng (nếu bạn nhắm mục tiêu chạy một trang web như Facebook thì bạn không quan tâm. Nội dung tĩnh của bạn sẽ sử dụng đám mây bùng phát là 4000 kết nối CÙNG LÚC chỉ là lưu lượng truy cập điên cuồng nên tôi sẽ không ảnh hưởng đến khả năng bảo trì VS khả năng mở rộng) Ít nhất là không hợp lệ từ các ứng dụng mạng nội bộ. Tôi tò mò liệu phiên bản tương lai của Tomcat có sử dụng mẫu lò phản ứng hay không, bản thân Java cũng cung cấp hỗ trợ cho việc này. Bạn có thể xử lý nội dung tĩnh bằng Nginx có mẫu lò phản ứng được triển khai https. //www. pascaldimassimo. com/2011/02/10/java-and-the-reactor-pattern Vẫn cho các trang động, tôi chưa tìm thấy bất kỳ manh mối nào. Một chủ đề không giữ bối cảnh phiên vì vậy tôi thực sự nghi ngờ về việc có 2Mb trong đó. Trừ khi được mã hóa kém

philippe

Tôi muốn có nhiều Java hơn cho phía máy khách hơn là nhiều Javascript hơn cho phía máy chủ. Tái cấu trúc Javascript là một cơn ác mộng. Bạn nào làm phần mềm 4000 - 10000 class như mình thì biết mình đang nói cái gì. Tôi thấy việc quản lý luồng là một điểm cộng (nếu bạn nhắm mục tiêu chạy một trang web như Facebook thì bạn không quan tâm. Nội dung tĩnh của bạn sẽ sử dụng đám mây bùng phát là 4000 kết nối CÙNG LÚC chỉ là lưu lượng truy cập điên cuồng nên tôi sẽ không ảnh hưởng đến khả năng bảo trì VS khả năng mở rộng) Ít nhất là không hợp lệ từ các ứng dụng mạng nội bộ. Tôi tò mò liệu phiên bản tương lai của Tomcat có sử dụng mẫu lò phản ứng hay không, bản thân Java cũng cung cấp hỗ trợ cho việc này. Bạn có thể xử lý nội dung tĩnh bằng Nginx có mẫu lò phản ứng được triển khai https. //www. pascaldimassimo. com/2011/02/10/java-and-the-reactor-pattern Vẫn cho các trang động, tôi chưa tìm thấy bất kỳ manh mối nào. Một chủ đề không giữ bối cảnh phiên vì vậy tôi thực sự nghi ngờ về việc có 2Mb trong đó. Trừ khi được mã hóa kém

Cody Donelson

Sự kiện mặc dù bài viết đã được vài năm nhưng nó đưa ra một số điểm tuyệt vời về Node. js. Đọc qua các bình luận, tôi đã thấy một số bài đăng về cách Node. js là một điều tuyệt vời và những thứ khác về cách các ngôn ngữ hàng đầu là C#, Java hoặc Ruby. Chúng tôi biết rằng JavaScript sẽ mang đến một số phức tạp vì nó liên quan đến Lập trình hướng đối tượng, Ánh xạ quan hệ đối tượng, cơ sở dữ liệu quan hệ, v.v. Tôi nghĩ rằng hầu hết các nhà phát triển/người quản lý dự án đang đánh mất điều gì tạo nên JavaScript và Node. js (cũng như AngularJS) thật tuyệt vời. Chúng tôi có thể triển khai ngôn ngữ phía máy khách ở phía máy chủ và làm cho nó thực hiện chính xác như bất kỳ ngôn ngữ phía máy chủ nào khác. Cá nhân tôi thích sử dụng Node. js, mặc dù thật khó để tôi hoàn toàn chìm đắm trong một ngôn ngữ không có kiểu chữ. Khi tôi hiểu được thực tế rằng bầu trời là giới hạn đối với các đối tượng của tôi và tôi không phải ánh xạ các đối tượng của mình từ loại này sang loại khác (như bạn làm trong C# hoặc Java), khả năng viết mã của tôi đã thực hiện . Gần đây tôi đã dạy một vài kỹ thuật viên PC tại công ty mà tôi làm việc về lập trình. Sếp của tôi rất kiên quyết rằng Node. js là con đường của tương lai (đặc biệt là việc ngừng sử dụng các trình cắm Java trong những năm tới) Tôi có xu hướng đồng ý. Tôi không hiểu tại sao lại có một cuộc tranh luận như vậy khi có liên quan đến các đối tượng trong Node. js/JavaScript. Tôi thấy việc sử dụng các đối tượng dễ dàng hơn và tôi có thể sử dụng chúng linh hoạt hơn VÌ có JavaScript. Tôi sẽ sớm triển khai các thuộc tính HTML trong các đối tượng cho các ứng dụng Express 4 của mình. Tôi nhận thấy rằng PUG (trước đây là Jade) cực kỳ có khả năng xử lý các đối tượng và mảng, do đó, giúp ai đó dễ dàng thay đổi động loại, giá trị hoặc thẻ dựa trên đối tượng được gửi qua GET hoặc . Tôi tin rằng một khi mọi người tham gia với sự hiểu biết về cách Node. js hoạt động, cách bạn có thể triển khai hiệu quả các tiêu chuẩn thường được thực thi bằng ngôn ngữ đánh máy và thực tế là Node. js có một số điều kỳ quặc về nó, liệu chúng ta có thực sự có thể tiến lên phía trước và làm cho ngôn ngữ này trở nên mạnh mẽ như các ngôn ngữ trước nó không. Cuối cùng, tôi sẽ nói thêm rằng khả năng sử dụng Node. js hầu như ở mọi nơi làm cho nó tốt hơn nhiều. Cho dù đó là ứng dụng Express được triển khai trên máy chủ Linux, ứng dụng Electron được triển khai trên máy chủ đầu cuối, Node. js thực tế là một sự phù hợp hoàn hảo cho bất kỳ khối lượng công việc nào cần phải hoàn thành

Cody Donelson

Sự kiện mặc dù bài viết đã được vài năm nhưng nó đưa ra một số điểm tuyệt vời về Node. js. Đọc qua các bình luận, tôi đã thấy một số bài đăng về cách Node. js là một điều tuyệt vời và những thứ khác về cách các ngôn ngữ hàng đầu là C#, Java hoặc Ruby. Chúng tôi biết rằng JavaScript sẽ mang đến một số phức tạp vì nó liên quan đến Lập trình hướng đối tượng, Ánh xạ quan hệ đối tượng, cơ sở dữ liệu quan hệ, v.v. Tôi nghĩ rằng hầu hết các nhà phát triển/người quản lý dự án đang đánh mất điều gì tạo nên JavaScript và Node. js (cũng như AngularJS) thật tuyệt vời. Chúng tôi có thể triển khai ngôn ngữ phía máy khách ở phía máy chủ và làm cho nó thực hiện chính xác như bất kỳ ngôn ngữ phía máy chủ nào khác. Cá nhân tôi thích sử dụng Node. js, mặc dù thật khó để tôi hoàn toàn chìm đắm trong một ngôn ngữ không có kiểu chữ. Khi tôi hiểu được thực tế rằng bầu trời là giới hạn đối với các đối tượng của tôi và tôi không phải ánh xạ các đối tượng của mình từ loại này sang loại khác (như bạn làm trong C# hoặc Java), khả năng viết mã của tôi đã thực hiện . Gần đây tôi đã dạy một vài kỹ thuật viên PC tại công ty mà tôi làm việc về lập trình. Sếp của tôi rất kiên quyết rằng Node. js là con đường của tương lai (đặc biệt là việc ngừng sử dụng các trình cắm Java trong những năm tới) Tôi có xu hướng đồng ý. Tôi không hiểu tại sao lại có một cuộc tranh luận như vậy khi có liên quan đến các đối tượng trong Node. js/JavaScript. Tôi thấy việc sử dụng các đối tượng dễ dàng hơn và tôi có thể sử dụng chúng linh hoạt hơn VÌ có JavaScript. Tôi sẽ sớm triển khai các thuộc tính HTML trong các đối tượng cho các ứng dụng Express 4 của mình. Tôi nhận thấy rằng PUG (trước đây là Jade) cực kỳ có khả năng xử lý các đối tượng và mảng, do đó, giúp ai đó dễ dàng thay đổi động loại, giá trị hoặc thẻ dựa trên đối tượng được gửi qua GET hoặc . Tôi tin rằng một khi mọi người tham gia với sự hiểu biết về cách Node. js hoạt động, cách bạn có thể triển khai hiệu quả các tiêu chuẩn thường được thực thi bằng ngôn ngữ đánh máy và thực tế là Node. js có một số điều kỳ quặc về nó, liệu chúng ta có thực sự có thể tiến lên phía trước và làm cho ngôn ngữ này trở nên mạnh mẽ như các ngôn ngữ trước nó không. Cuối cùng, tôi sẽ nói thêm rằng khả năng sử dụng Node. js hầu như ở mọi nơi làm cho nó tốt hơn nhiều. Cho dù đó là ứng dụng Express được triển khai trên máy chủ Linux, ứng dụng Electron được triển khai trên máy chủ đầu cuối, Node. js thực tế là một sự phù hợp hoàn hảo cho bất kỳ khối lượng công việc nào cần phải hoàn thành

Gage Poon

Nhanh như chớp, nhẹ, phát triển mượt mà và hiệu suất tốt hơn, đây là một số thay đổi mang tính cách mạng do Node js mang lại trong lĩnh vực phát triển web. Node js mang đến sự tự do sáng tạo, nguồn tài nguyên phong phú như NPM (Trình quản lý gói nút), là thư viện chia sẻ các mô-đun và công cụ. Ngoài ra, các ứng dụng web được phát triển bằng khung phát triển web này có khả năng mở rộng hơn. Khung JavaScript này rất phổ biến trong số các phần khởi động. Tuy nhiên, những tên tuổi lớn như Netflix, Paypal, eBay, Microsoft, Uber, DivBox. trong vv. cũng đang sử dụng khung phát triển web giàu tính năng này

Gage Poon

Nhanh như chớp, nhẹ, phát triển mượt mà và hiệu suất tốt hơn, đây là một số thay đổi mang tính cách mạng do Node js mang lại trong lĩnh vực phát triển web. Node js mang đến sự tự do sáng tạo, nguồn tài nguyên phong phú như NPM (Trình quản lý gói nút), là thư viện chia sẻ các mô-đun và công cụ. Ngoài ra, các ứng dụng web được phát triển bằng khung phát triển web này có khả năng mở rộng hơn. Khung JavaScript này rất phổ biến trong số các phần khởi động. Tuy nhiên, những tên tuổi lớn như Netflix, Paypal, eBay, Microsoft, Uber, DivBox. trong vv. cũng đang sử dụng khung phát triển web giàu tính năng này

rajivkumar bonam

node js là gì cách viết mã trong node js

rajivkumar bonam

node js là gì cách viết mã trong node js

Chế độ quân chủ dẫn đến tự do

Great article, thanks

Chế độ quân chủ dẫn đến tự do

Great article, thanks

csps1343

Nice node.js tutorials, thanks for sharing.

csps1343

Nice node.js tutorials, thanks for sharing.

Rahul Raut

thank you so much. learn node https://monkelite.com/what-is-node-js-learn-step-by-step/

Rahul Raut

thank you so much. learn node https://monkelite.com/what-is-node-js-learn-step-by-step/

Chapter247- Software Dev

"Why The Hell Would I Use Node.js? A Case-by-Case Tutorial". Every beginner must required to read this article. It's so easy to understand main Node.Js concept and programming overviews. Hire Node js development company

Sam Watt

Wow, this is a very detailed and insightful article based on cases. I loved reading it, and hoping to see more such articles. Thank you

ThinkStart Pvt Ltd

Useful post. Thanks you for sharing this wonderful information

w3villa

Hi, I like to read your informative blog. Thanks for sharing

Marie adams

I made several successful investments with this broker before losing 40% of my savings to the trading scam. It cost me so much money and pain to invest in an investment that was not even real. I was able to recover the majority of the funds, and we are still attempting to recover the rest. I highly recommend SECURE TO INVEST WELL for anyone involved in an online trading scam Trading scam $350,000 recovered BELOW IS THEIR CONTACT. secure2investwell@gmail. comcall/whatsapp. +14638887391

Marie adams

I made several successful investments with this broker before losing 40% of my savings to the trading scam. It cost me so much money and pain to invest in an investment that was not even real. I was able to recover the majority of the funds, and we are still attempting to recover the rest. I highly recommend SECURE TO INVEST WELL for anyone involved in an online trading scam Trading scam $350,000 recovered BELOW IS THEIR CONTACT. secure2investwell@gmail. comcall/whatsapp. +14638887391

Joshua Flynn

Very well written but you could do the same thing using a regular lamp stack with JQuery via AJAX calls like all instant messengers in the past have done with no complications? Even after reading this article I still believe that a Lamp stack with JavaScript and AJAX calls could do the job just as easily but without the complications of understanding the overly complex ecosystem that Node has become. I have read hundreds of articles around the web about why someone should use node but they all cover something that could be done with technology we had back in the 90s. so what is so special about node that I should learn it verses staying with 30 year old technology that has powered the same types of applications that you mentioned in this article 15 years before node came about and back when dial-up was fast. So if it was fast enough to do the same thing over a dial up connection what has node done too improve the ecosystem of the internet

How does Node. js execute?

How to run js file using node?

Where does Node. js run?

How does Node. js work internally?