6 ms·

Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route? Heck, even Deno would have been a more compelling platfo

Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route? Heck, even Deno would have been a more compelling platform. If all this is is composing plain ol’ HTML, which are just strings, any language will do. We have file based routing in Go in less than 10 lines of code connecting filesystem calls to Go’s template package. We have live reload with Air, too, and the builds times are under a second. Another nice thing with go is Filesystem embedding, so we build the HTML strings straight into the binary and deploy the binary as is.

Scarbutt 4y ago
React/nodejs is nice if you do SSR for everything too since you can use some hydration to improve the UX and write all your view code (server and browser) in a single place with the same language. Nodejs is a performant runtime and React is not only for creating SPAs. How do you plan to add JS to your Go web app?
- diceduckmonk 4y ago
  > 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.
azangru 4y ago
> Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route? You don't need to be building an SPA in order to want to have some client-side javascript. And you may want to use some third-party libraries for your client-side javascript. Npm is a decent distribution channel / dependency manager for that purpose.
pabs3 4y ago
> composing plain ol’ HTML, which are just strings That way lies XSS attacks, might be better to have a DOM of some kind in your language.
- diceduckmonk 4y ago
  The template library in Go’s standard library handles XSS. Being a JavaScript-based doesn't preclude you from XSS, either.
- pdimitar 4y ago
  Not a month goes by without any random web framework receiving a security update regarding XSS and the like. You're better protected using web frameworks than trying to reinvent things by yourself, surely, but also let's not believe in miracles.
hombre_fatal 4y ago
Well, this isn’t just server side HTML includes, so your commentary seems like a rambling about your favorite language. It’s a framework that lets you write JS functions that are used to render HTML on the server but also run on the client for progressive enhancement which is what your Go pitch does not do.
- diceduckmonk 4y ago
  > client for progressive enhancement which is what your Go pitch does not do. We have progressive enhancement in our Go app based on HTMX. Also see Rails/Turbo and Pheonix/Elixir. Also, before the era of JS devs who only know the hammer of React and React-inspired HTML rendering libraries, there was PJAX to do progressive enhancement. It's not that hard of a problem to motivate reinventing the wheel HTML rendering wheel with yet-another-JavaScript-framework. In that light, it's probably better to just stick to React which provides a superset of functionality and is battle-tested, but I digress. Most of the original complexity of PJAX was smoothing out browser inconsistencies. It's way easier to add progressive enhancement with standardized HTML5 libraries. https://pjax.herokuapp.com/ https://pjax.herokuapp.com/ Observe how this JS library's source repo doesn't have a package.json and the vendor directory is rather shallow. The first commit was before Node.js even existed. As for HTMX, it's a JavaScript library. It's 10kB with zero dependencies, and you can just drop-it in with a script tag. I never criticized JS or a particular JS library. My original comment is about the dependency hell (and quality) of Node packages. > framework that lets you write JS functions Why is it important to have a framework and to write it is as JS function? That's an incidental detail if the goal is to compose HTML. > rambling about your favorite language. No, JavaScript is my favorite language. I just don't like NPM culture. We chose Go because it made sense for our use-case, as opposed to Node.js being an automatic default just because it's a frontend hammer.
  - alluro2 4y ago
    NPM is just a package manager - I don't get why it's blamed for everything wrong with the world. You can find same issues / challenges / dependency "hell" with any other popular language and its packages or equivalent. Maven certainly comes to mind.

Scarbutt 4y ago

React/nodejs is nice if you do SSR for everything too since you can use some hydration to improve the UX and write all your view code (server and browser) in a single place with the same language. Nodejs is a performant runtime and React is not only for creating SPAs. How do you plan to add JS to your Go web app?

diceduckmonk 4y ago
> 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.

azangru 4y ago

> Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route? You don't need to be building an SPA in order to want to have some client-side javascript. And you may want to use some third-party libraries for your client-side javascript. Npm is a decent distribution channel / dependency manager for that purpose.

pabs3 4y ago

> composing plain ol’ HTML, which are just strings That way lies XSS attacks, might be better to have a DOM of some kind in your language.

diceduckmonk 4y ago
The template library in Go’s standard library handles XSS. Being a JavaScript-based doesn't preclude you from XSS, either.
pdimitar 4y ago
Not a month goes by without any random web framework receiving a security update regarding XSS and the like. You're better protected using web frameworks than trying to reinvent things by yourself, surely, but also let's not believe in miracles.

hombre_fatal 4y ago

Well, this isn’t just server side HTML includes, so your commentary seems like a rambling about your favorite language. It’s a framework that lets you write JS functions that are used to render HTML on the server but also run on the client for progressive enhancement which is what your Go pitch does not do.

diceduckmonk 4y ago
> client for progressive enhancement which is what your Go pitch does not do. We have progressive enhancement in our Go app based on HTMX. Also see Rails/Turbo and Pheonix/Elixir. Also, before the era of JS devs who only know the hammer of React and React-inspired HTML rendering libraries, there was PJAX to do progressive enhancement. It's not that hard of a problem to motivate reinventing the wheel HTML rendering wheel with yet-another-JavaScript-framework. In that light, it's probably better to just stick to React which provides a superset of functionality and is battle-tested, but I digress. Most of the original complexity of PJAX was smoothing out browser inconsistencies. It's way easier to add progressive enhancement with standardized HTML5 libraries. https://pjax.herokuapp.com/ https://pjax.herokuapp.com/ Observe how this JS library's source repo doesn't have a package.json and the vendor directory is rather shallow. The first commit was before Node.js even existed. As for HTMX, it's a JavaScript library. It's 10kB with zero dependencies, and you can just drop-it in with a script tag. I never criticized JS or a particular JS library. My original comment is about the dependency hell (and quality) of Node packages. > framework that lets you write JS functions Why is it important to have a framework and to write it is as JS function? That's an incidental detail if the goal is to compose HTML. > rambling about your favorite language. No, JavaScript is my favorite language. I just don't like NPM culture. We chose Go because it made sense for our use-case, as opposed to Node.js being an automatic default just because it's a frontend hammer.
- alluro2 4y ago
  NPM is just a package manager - I don't get why it's blamed for everything wrong with the world. You can find same issues / challenges / dependency "hell" with any other popular language and its packages or equivalent. Maven certainly comes to mind.