4 ms·

> How do you plan to add JS to your Go web app? This is what I mean by Node.js being a hammer and everything looks like a nail. You don’t need Node.js to writ

> How do you plan to add JS to your Go web app? This is what I mean by Node.js being a hammer and everything looks like a nail. You don’t need Node.js to write JavaScript.

nawgz 4y ago
> You don’t need Node.js to write JavaScript Yes, but you generally do need NodeJS to access NPM packages, which will provide a ton of JavaScript functionality for free. To the user who posed this question, I'm sure what they meant could be more charitably read as: "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" You've certainly listed some upsides to Go, but then your response to someone requesting a more honest analysis of the downsides is "Node.js devs are idiots". Hm.
- diceduckmonk 4y ago
  I didn't say Node.js devs are idiots. My argument is that Node.js devs only knows Node.js and sees everything as a nail. You are projecting that that equates to idiocacy, and I won't argue. > "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" For our project, a search engine with interactive filtering capabilities, we don't plan or need to. With SSR, most logic is already handled by the server. This is a CRUD app. The set of libraries available in NPM that we might be interested would be a handful to zero. If it's that critical, we can just add a script tag. If it's a useful abstraction, it should be available on CDN. If it's not, and it's not succumbing to dependency hell, we can just copy and paste from NPM or Github. The JavaScript aspect is to add interactivity, and that's available thru DOM APIs and VanillaJS. NPM is besides the point. I exit here because you're going in a circle presuming that it's not feasible to build web applications without Node.js' "thriving" ecosystem. Amazon, Google, and so many other apps precede Node.js. I shipped JavaScript-enriched web applications at a few of those companies without having to use NPM as the package manager. Here is one of the most powerful text editors for the web (I've load tested that it can handle 80million+ line buffers, whereas VSCode edges out at <5million natively): https://github.com/ajaxorg/ace https://github.com/ajaxorg/ace. It's a pretty complex JavaScript application but you can develop without ever needing to "build". They use NPM to run tests and some devtools like Eslint, but we've still managed to minification/bundling in Go. I'm building a JavaScript-based text editor, too. Taking inspiration from Ace.js, it uses Makefile to "build". You can just run a static file server such as Python SimpleHTTPServer to host all the files in the directory. I still have and componentized HTML/CSS that are lazy-loaded, separated JS files, thanks to <500 bytes VanillaJS runtime based on HTMX. I do reach for libraries. For that, I look to https://js1k.com/ https://js1k.com/ for inspiration. The libraries there have zero-dependencies. Their source code all fit in screen and I can just copy the relevant bits. This is very similar to pulling in dependencies in Go in that it's humanly possible to do a supply chain security audit, unlike the nature of NPM packages. Currently the text editor with handwritten VanillaJS + copy-pasted libraries can handle 120+ million line buffers. Serious apps and businesses can be built without NPM. Inferring from HackerNews' JavaScript source, and the fact that it's written in Lisp, I doubt HN uses NPM. This doesn't stop HackerNews from being useful and valuable.
  - solardev 4y ago
    As someone who uses the JS ecosystem day in and day out (without either particular love or hated for it), I just wanted to say: Thanks for a detailed and informative post! It's neat to hear about other web stacks and their various pros and cons. Different projects and teams have different requirements, and it's interesting to hear about other approaches.
  - nawgz 4y ago
    > I didn't say Node.js devs are idiots No, you said: "You don’t need Node.js to write JavaScript." Then, as evidence, you said your simple CRUD app doesn't need JS, linked me to some NodeJS projects, and told me that the web was working before NodeJS. Technically true points but not really supporting the idea that Go is the correct language to write web apps with JS in. I don't blame you for exiting, it's not a cohesive conversation, but your quick dismissal of a question about NodeJS that you proceeded to undermine by showing me how most people use NodeJS to write their JS projects is... confusing
    - pdimitar 4y ago
      > Technically true points but not really supporting the idea that Go is the correct language to write web apps with JS in. If the project is live and is serving its purpose, and if that doesn't convince you that $INSERT_LANGUAGE is the correct language (whatever that means) then I don't know what will. Care to clarify that "correct language" thing?
      - nawgz 4y ago
        Perhaps "canonical" would be a better word, and as your links suggested, the canonical way to work on JavaScript-language capabilities is to use a JavaScript interpreter you can run outside the browser. Not sure Go has one of those wired.
        pdimitar 4y ago
        I didn't post any links and I seriously lost the thread of the conversation here. Why would you need to run a JS interpreter to be able to include JS in a website?... Confusing.

> How do you plan to add JS to your Go web app? This is what I mean by Node.js being a hammer and everything looks like a nail. You don’t need Node.js to write JavaScript.

nawgz 4y ago

> You don’t need Node.js to write JavaScript Yes, but you generally do need NodeJS to access NPM packages, which will provide a ton of JavaScript functionality for free. To the user who posed this question, I'm sure what they meant could be more charitably read as: "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" You've certainly listed some upsides to Go, but then your response to someone requesting a more honest analysis of the downsides is "Node.js devs are idiots". Hm.

diceduckmonk 4y ago
I didn't say Node.js devs are idiots. My argument is that Node.js devs only knows Node.js and sees everything as a nail. You are projecting that that equates to idiocacy, and I won't argue. > "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" For our project, a search engine with interactive filtering capabilities, we don't plan or need to. With SSR, most logic is already handled by the server. This is a CRUD app. The set of libraries available in NPM that we might be interested would be a handful to zero. If it's that critical, we can just add a script tag. If it's a useful abstraction, it should be available on CDN. If it's not, and it's not succumbing to dependency hell, we can just copy and paste from NPM or Github. The JavaScript aspect is to add interactivity, and that's available thru DOM APIs and VanillaJS. NPM is besides the point. I exit here because you're going in a circle presuming that it's not feasible to build web applications without Node.js' "thriving" ecosystem. Amazon, Google, and so many other apps precede Node.js. I shipped JavaScript-enriched web applications at a few of those companies without having to use NPM as the package manager. Here is one of the most powerful text editors for the web (I've load tested that it can handle 80million+ line buffers, whereas VSCode edges out at <5million natively): https://github.com/ajaxorg/ace https://github.com/ajaxorg/ace. It's a pretty complex JavaScript application but you can develop without ever needing to "build". They use NPM to run tests and some devtools like Eslint, but we've still managed to minification/bundling in Go. I'm building a JavaScript-based text editor, too. Taking inspiration from Ace.js, it uses Makefile to "build". You can just run a static file server such as Python SimpleHTTPServer to host all the files in the directory. I still have and componentized HTML/CSS that are lazy-loaded, separated JS files, thanks to <500 bytes VanillaJS runtime based on HTMX. I do reach for libraries. For that, I look to https://js1k.com/ https://js1k.com/ for inspiration. The libraries there have zero-dependencies. Their source code all fit in screen and I can just copy the relevant bits. This is very similar to pulling in dependencies in Go in that it's humanly possible to do a supply chain security audit, unlike the nature of NPM packages. Currently the text editor with handwritten VanillaJS + copy-pasted libraries can handle 120+ million line buffers. Serious apps and businesses can be built without NPM. Inferring from HackerNews' JavaScript source, and the fact that it's written in Lisp, I doubt HN uses NPM. This doesn't stop HackerNews from being useful and valuable.
- solardev 4y ago
  As someone who uses the JS ecosystem day in and day out (without either particular love or hated for it), I just wanted to say: Thanks for a detailed and informative post! It's neat to hear about other web stacks and their various pros and cons. Different projects and teams have different requirements, and it's interesting to hear about other approaches.
- nawgz 4y ago
  > I didn't say Node.js devs are idiots No, you said: "You don’t need Node.js to write JavaScript." Then, as evidence, you said your simple CRUD app doesn't need JS, linked me to some NodeJS projects, and told me that the web was working before NodeJS. Technically true points but not really supporting the idea that Go is the correct language to write web apps with JS in. I don't blame you for exiting, it's not a cohesive conversation, but your quick dismissal of a question about NodeJS that you proceeded to undermine by showing me how most people use NodeJS to write their JS projects is... confusing
  - pdimitar 4y ago
    > Technically true points but not really supporting the idea that Go is the correct language to write web apps with JS in. If the project is live and is serving its purpose, and if that doesn't convince you that $INSERT_LANGUAGE is the correct language (whatever that means) then I don't know what will. Care to clarify that "correct language" thing?
    - nawgz 4y ago
      Perhaps "canonical" would be a better word, and as your links suggested, the canonical way to work on JavaScript-language capabilities is to use a JavaScript interpreter you can run outside the browser. Not sure Go has one of those wired.
      - pdimitar 4y ago
        I didn't post any links and I seriously lost the thread of the conversation here. Why would you need to run a JS interpreter to be able to include JS in a website?... Confusing.