7 ms·

Ask HN: Can you help me understand modern web development?

• acemarke 4y ago
  I'm not quite sure I entirely follow the question, but I'm happy to try to answer (and also chat more directly over in the Reactiflux Discord where I usually hang out, if that's easier - https://www.reactiflux.com https://www.reactiflux.com , can ping me @acemarke in a channel like #general-tech ). I'm sort of wondering if part of the confusion is seeing the name `node_modules`. The `node_modules` folder _was_ originally created as the place for the NPM package manager to install packages that were, yes, _only_ for use inside the Node JS runtime. _However_... in today's development world, _all_ libraries your app depends on, both for building the project _and_ for runtime behavior, get installed into the `node_modules` folder of a project. That includes libraries that _only_ run under Node, libraries that _only_ run in a browser, and libraries that can be used on either side. So, think of the `node_modules` folder not as strictly "a place to install packages that only run under Node", but rather "a place to install _all_ packages used in this JS project, of any kind". As an example: the React library is normally used for client-side rendering. If I do `npm install react`, it will get extracted to `./node_modules/react/`. I then do `import React from "react"` in my client-side only code, and a bundler like Webpack will end up adding the React library code to my final generated browser JS bundle when I run the build step. On the other hand, you can _also_ use React on the server side as well, such as pre-generating HTML while handling an HTTP request, and you would again do `import React from "react"` in server-side code too. At the same time, the Lodash utility lib (which is generic JS code that can be used anywhere) and the Webpack bundler (which is a build/dev-time only tool) would _also_ all get installed to their respective folders in `node_modules`, along with any other libraries they themselves depend on. You might want to read through my "How Web Apps Work" series to see how some of these different pieces come together: https://blog.isquaredsoftware.com/series/how-web-apps-work https://blog.isquaredsoftware.com/series/how-web-apps-work
• lmiller1990 4y ago
  I tried to explain a bit about how we came from a single index.js to the modern workflow work webpack etc in this video, maybe it’s useful for you: https://m.youtube.com/watch?v=QliwSwWHJoQ https://m.youtube.com/watch?v=QliwSwWHJoQ
• dantate 4y ago
  Do you want to know about development or how a website works from the ground up. It sounds like you're confused in a few places.
• supermatt 4y ago
  > but can't understand how/why you'd need a nodejs library that will provide some frontend functionalities NPM (node package manager) is a bit misleading here as they arent necessarily modules FOR node. They are often just javascript modules (usually in commonJS format) conforming to the NPM package format. > How does it work ? The files, including your code and the referenced modules and their dependencies (usually) go through a build step (using 3rd party tools), which creates a single (but can be multiple) file containing (effectively) a map of all the bundled files and a function to handle the module loading. This file is then run in the browser (which will either execute the program, or expose the programs API/entrypoints in some way). i.e. it allows you to create your code in a structured way, but then "bundles" up the code in a way to run it in the browser.
• Hbruz0 4y ago
  OP here. Your comments are helpful so far. To clarify some things: I know how a website works (HTML/CSS/JS, even with PHP & MYSQL or Node and a database) so I think my main confusion comes from frontend frameworks like React, Angular, Vue etc. Are they run on the server then the rendered version is sent to the client ? I've used browserify before and I thought it was "hacky", is this similar to how things are done usually ? Thanks for your replies, I have seen great resources linked in the comments
  • acemarke 4y ago
    Yeah, one of my "How Web Apps Work" posts covers much of this question: https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-client-dev-deployment/ https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-... Quick sequence walkthrough, for the typical "Client-Side Rendering (CSR)" scenario: - Ahead of time, on a developer build system: the original app source code is run through a full compilation process, including stripping out types, processing assets like images and CSS, bundling the hundreds/thousands of original source files into a handful of merged files to minimize downloads, and minifying it to shrink download size. (Once upon a time this was done with Browserify. Today, it's typically a build toolchain based around Webpack, such as Create-React-App, Next.js, or the Angular CLI, or a similar toolchain using tools like newer / faster tools ESBuild or SWC.) - These "static files" are deployed to some web server system, and the server software waits for a user to request that page. - Browser requests a site for the first time. Server returns a small HTML page that has links to the primary page CSS, and the pre-built JS app bundle files. - Browser loads the JS, and the client-side app code bootstraps itself. It attaches itself to a given DOM node (usually an empty div that just acts as a placeholder), and does an initial render, generating all of the initial DOM content as it works through the component tree - Now that the UI is initialized, the UI framework waits for user interactions, at which point it applies state updates, checks to see what the UI should look like _now_ based on the component tree, and efficiently updates the DOM to match the desired results. There's also "Static Site Generation (SSG)", where the same React/Vue/Angular/Svelte UI components can be used to generate plain HTML files ahead of time, and "Server-Side Rendering (SSR)", where those same UI components can be used to render HTML as a string on the server on demand in response to a page request.