4 ms·

> Any project I work on is connected to a million different tools, workflows and services, I was just skimming and read that, and I thought "he is working in J

> Any project I work on is connected to a million different tools, workflows and services, I was just skimming and read that, and I thought "he is working in Javascript" and yep, later on that's it. I stay away from the Javascript/TS ecosystem (npm et al). I program mostly in Go, but also quite a bit in Typescript. I would learn/use (even if for personal projects) more boring tech stacks, like Java/C#/Go/PL-SQL/T-SQL. For myself, Go has extremely stable tools that just work and have well-known limitations. Consider a lateral move within tech.

anthropodie 4y ago
I do the same but Go can't help me with frontend, right? What do you do?
- nicoburns 4y ago
  If you don’t like JS/TS then just don’t do front end? There’s plenty of backend only jobs.
  - steve1977 4y ago
    Or remember that there are actually frontends other than web browsers.
    - Pet_Ant 4y ago
      Yes, there are web browsers and then there are electron ones.
- cnity 4y ago
  It's worth stating: you can write frontends without buying into the ecosystem at large. I've been working on a multiplayer video game using Go + websockets in the backend, and a JS frontend with zero dependencies. IMO JS is really fun to program this way. You program straight to the capabilities of the browser. All of the problems people promised I'd face by avoiding their framework of choice didn't show up after all.
- napsterbr 4y ago
  I once suffered from Javascript fatigue, had to work with frontend anyways, and had the privilege of picking my own tools. That's when I started experimenting with Elm, Bucklescript (now ReScript) and Clojurescript. It was a very insightful journey that made me enjoy frontend development again. Today, Clojurescript is my favorite method of working with frontend code and, as long as I can pick my own tools, that's the one I'm sticking with. For those suffering of Javascript fatigue, I highly recommend playing around with these alternatives. Try doing a simple, small side project in them. It may reignite your joy for programing and who knows, maybe you can find a job to work full-time with these tools.
- xyzzy4747 4y ago
  Just learn Next.js (Vercel), TypeScript, and MUI and don’t use anything else. Make sure you also understand CSS flex-box and such.
  - Cerpicio 4y ago
    [upvoting solely for your username]
- kardianos 4y ago
  For the front-end I write SPAs. I rely on the TS compiler to bundle into a single JS file, so I avoid bundler (etc). I build a simple framework that meets my needs that I can essentially vendor and keep in my head. I'm would love to use an established framework rather then my own (don't get me wrong, there are serious downsides to rolling my own), but it must be small enough I can read it easily in a single sitting. I will not touch the NPM ecosystem. I sometimes will pull a dependency in by manually copying in the parts I need (preserving licenses, etc). There are real downsides to doing what I do, but I do it to keep myself sane. I do not touch the npm ecosystem. I also review every line of code I pull in from any language (Go, TS, etc). An ecosystem that makes this difficult or impossible is just a non-starter.
  - dtagames 4y ago
    This is been the sanity-saving solution for me. I roll 100% of my own stuff in TS and web components. It sounds awful -- unless you compare it with fighting someone else's dragons. This way, the only dragons I have are ones I created and ones I can slay. The more I write my things in functional style and build only exactly what my application needs, the company's "framework" continues to evolve AND our apps continue to work! No one is going to change any of the "ecosystem" out from under me because there isn't one. Everything is compiled in Vite (automatically and hot reloaded) and I only ship a minified, static, single index.html file with my entire app in it. There are no globals that I didn't make, no functions that are required unless I required them, etc. It's a HUGE timesaver when debugging or adding new things the team requests. I'm able to continue to write new, cool stuff in both our public-facing web app and in our internal web tool (game dev), both on the same framework.
- marcus_holmes 4y ago
  I stay away from all the JS dependency bullshit as much as possible. I use vanilla JS & CSS wherever possible, usually in a Go template. If I have to create a SPA then I use Vue - I've found it's the least complex of the front-end frameworks. I build it using ESBuild from the flat JS files downloaded from the Vue site and stay as far from yarn/npm as possible. I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.
  - cnity 4y ago
    Any Go WASM solution will come with big performance costs and complexity that are worth considering: 1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal. 2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run. 3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API. I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck
    - marcus_holmes 4y ago
      I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet. Everything else is spot on, that's the pain!
      - cnity 4y ago
        You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment. 0: https://tinygo.org/ https://tinygo.org/
zikero 4y ago
No viable alternative to JS/TS for web (client side) unfortunately.
- jamal-kumar 4y ago
  I mean, making a career pivot away from front end is technically an alternative
- dgb23 4y ago
  You can make interactive web sites with a minimal amount of JS (et al). For example the mentioned Go has a HTML templating package in the std library. You could use something like htmx (the creator is a regular on here) which is a very small, very convenient library that gets you 80% of the way for your typical web application. For the rest, you can always just stick with plain old DOM manipulation or write web components if you want something that's more re-usable and general. No build step or transpilation shenanigans required here.
- kerkeslager 4y ago
  Sure, but you don't have to do it the way most JS projects do it. I've made a career writing Django apps. In most cases, the JS I write is limited to vanilla JS with no JS dependencies (the minification is done by a Python library which might depend on JS, but it's abstracted away enough that I don't have to know). There needs to be a serious amount of justification to even install Node/NPM as part of a project. The vast majority of work is done on the backend, with JS only being used for UX. I used to pull in React+ReactDOM on some projects, but Web components are paving the way for that to no longer be necessary. As I mentioned elsewhere, it's possible to pull all of pip into a Python project and have all the same problems, but the culture around Python isn't quite as myopic as the JS community, so I've generally been able to keep dependencies more sparse when working on Python teams.
- ibz 4y ago
  WASM?
jamal-kumar 4y ago
Getting proficient with Go has been the best move of my career to date. It's such a productive language, and you don't have the same drowning in dependencies problems whatsoever becuase the stdlib and a few packages around it are just so strong. I like being able to show off a very small go.mod to a boss who's been putting up with NPM hell for the better part of a decade. I like typescript, I've tried Deno but it's just insane to me how people get caught up in all the hype around the NPM ecosystem only to end up crashing into walls like 'entire system shutting down' with no idea how to fix it. Friend who came before me hit me up asking about a 'linux problem' and it was just webpack crashing his entire computer with semaphore exhaustion. I keep that stuff confined to where it was spawned from, in the browser, anywhere else just doesn't feel sane to me.
weatherlite 4y ago
You're just lucky to work in a company with a good codebase. I'm sure there's plenty toxic environments with shitty codebases written in Go where you wouldn't like working there at all. You're giving too much credit to how much the programming language matters imo.
- cloverich 4y ago
  You are correct to an extent, but its a fallacy to assume the language and tooling have no impact on the culture or people it attracts. Go is very specifically not "elegant", it has a stdlib where npm has hundreds of dependencies which differ between projects. Errors in JS (Ruby, etc) can come from unexpected places, but the code can elegantly hide them. In Go they are in your face at all times -- but then they rarely surprise you. etc. Its a series of trade offs that are more than simple choices IMO, they target and attract different audiences. And to an extent many people will likely gel better with one than the other. Its only a piece of the puzzle to be sure and the people and company matter more, but I strongly disagree that languages / frameworks matter little. I think those with big differences (Node/Ruby vs Go) there's probably a substantial difference in "average" workplace culture.
  - weatherlite 4y ago
    > You are correct to an extent, but its a fallacy to assume the language and tooling have no impact on the culture or people it attracts If the company is doing anything web related it will have JS people somewhere right? And it might also choose to make everyone full stack (so doing both Go and JS) or making some of the teams hybrid. That's quite common. I don't really see much difference between a company that chooses Go to a company that chooses Node (or Ruby, whatever), they both have their pros and cons and it doesn't tell me that much about the people I'll be working with.
throwaway020623 4y ago
I have several side projects where I use a simple Spring Boot backend and I feel I can focus more on the fun part (solving problems). It just works! There is also a huge eco system of good quality open source libraries compared to some of the newer backend languages. This feeling is absent from React-based apps. The React eco system has been around for many years now, but is missing many of the advantages age typically brings. The eco system feels much more fragile and driven by hype. I simply don't trust things to work as smoothly. Maybe this instability is what keeps React popular? If it becomes more stable, it will not generate as much hype and developers move to the next big thing.
- ragnarsson 4y ago
  My experience with React has been different hence commenting here. That is just not true. I have used react with nextjs in the past but moved to remix. Moving to a new framework requires you to learn it, quite similar to learning a new language but it is much better than manually creating webpack loaders. I had a decent experience with nextjs but my experience with remix has been better. I used Spring Boot at work and I have worked with backend libraries like Express(JS), Flask(Python), Gin(go) all the experiences have been much better than using Spring Boot. Java takes too long to compile, dependecy injection in Spring just seems to take forever, and overall Java is very very verbose. Just to create a stupid API, you have to create a new class for request, one for response, controller, service. I can do it if I am paid for it but using that for side projects, a big NO.
  - throwaway020623 4y ago
    I think we have different ideas about what a good development environment is, and that is ok. We have our preferences and we can't argue with that. I would like to comment on how you feel Java compilation is slow. Incremental compilation while developing is fast and doesn't affect my productivity (your experience may differ). Triggering a single threaded full build with one of my services (1000+ files and 80k lines) took less than 30 seconds on my laptop (18s with parallel compilation). But I never do that locally, as incremental compilations are almost instant. If you need to download dependencies and run tests, the number is higher, but that is not specific for Java

anthropodie 4y ago

I do the same but Go can't help me with frontend, right? What do you do?

nicoburns 4y ago
If you don’t like JS/TS then just don’t do front end? There’s plenty of backend only jobs.
- steve1977 4y ago
  Or remember that there are actually frontends other than web browsers.
  - Pet_Ant 4y ago
    Yes, there are web browsers and then there are electron ones.
cnity 4y ago
It's worth stating: you can write frontends without buying into the ecosystem at large. I've been working on a multiplayer video game using Go + websockets in the backend, and a JS frontend with zero dependencies. IMO JS is really fun to program this way. You program straight to the capabilities of the browser. All of the problems people promised I'd face by avoiding their framework of choice didn't show up after all.
napsterbr 4y ago
I once suffered from Javascript fatigue, had to work with frontend anyways, and had the privilege of picking my own tools. That's when I started experimenting with Elm, Bucklescript (now ReScript) and Clojurescript. It was a very insightful journey that made me enjoy frontend development again. Today, Clojurescript is my favorite method of working with frontend code and, as long as I can pick my own tools, that's the one I'm sticking with. For those suffering of Javascript fatigue, I highly recommend playing around with these alternatives. Try doing a simple, small side project in them. It may reignite your joy for programing and who knows, maybe you can find a job to work full-time with these tools.
xyzzy4747 4y ago
Just learn Next.js (Vercel), TypeScript, and MUI and don’t use anything else. Make sure you also understand CSS flex-box and such.
- Cerpicio 4y ago
  [upvoting solely for your username]
kardianos 4y ago
For the front-end I write SPAs. I rely on the TS compiler to bundle into a single JS file, so I avoid bundler (etc). I build a simple framework that meets my needs that I can essentially vendor and keep in my head. I'm would love to use an established framework rather then my own (don't get me wrong, there are serious downsides to rolling my own), but it must be small enough I can read it easily in a single sitting. I will not touch the NPM ecosystem. I sometimes will pull a dependency in by manually copying in the parts I need (preserving licenses, etc). There are real downsides to doing what I do, but I do it to keep myself sane. I do not touch the npm ecosystem. I also review every line of code I pull in from any language (Go, TS, etc). An ecosystem that makes this difficult or impossible is just a non-starter.
- dtagames 4y ago
  This is been the sanity-saving solution for me. I roll 100% of my own stuff in TS and web components. It sounds awful -- unless you compare it with fighting someone else's dragons. This way, the only dragons I have are ones I created and ones I can slay. The more I write my things in functional style and build only exactly what my application needs, the company's "framework" continues to evolve AND our apps continue to work! No one is going to change any of the "ecosystem" out from under me because there isn't one. Everything is compiled in Vite (automatically and hot reloaded) and I only ship a minified, static, single index.html file with my entire app in it. There are no globals that I didn't make, no functions that are required unless I required them, etc. It's a HUGE timesaver when debugging or adding new things the team requests. I'm able to continue to write new, cool stuff in both our public-facing web app and in our internal web tool (game dev), both on the same framework.
marcus_holmes 4y ago
I stay away from all the JS dependency bullshit as much as possible. I use vanilla JS & CSS wherever possible, usually in a Go template. If I have to create a SPA then I use Vue - I've found it's the least complex of the front-end frameworks. I build it using ESBuild from the flat JS files downloaded from the Vue site and stay as far from yarn/npm as possible. I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.
- cnity 4y ago
  Any Go WASM solution will come with big performance costs and complexity that are worth considering: 1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal. 2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run. 3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API. I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck
  - marcus_holmes 4y ago
    I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet. Everything else is spot on, that's the pain!
    - cnity 4y ago
      You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment. 0: https://tinygo.org/ https://tinygo.org/

zikero 4y ago

No viable alternative to JS/TS for web (client side) unfortunately.

jamal-kumar 4y ago
I mean, making a career pivot away from front end is technically an alternative
dgb23 4y ago
You can make interactive web sites with a minimal amount of JS (et al). For example the mentioned Go has a HTML templating package in the std library. You could use something like htmx (the creator is a regular on here) which is a very small, very convenient library that gets you 80% of the way for your typical web application. For the rest, you can always just stick with plain old DOM manipulation or write web components if you want something that's more re-usable and general. No build step or transpilation shenanigans required here.
kerkeslager 4y ago
Sure, but you don't have to do it the way most JS projects do it. I've made a career writing Django apps. In most cases, the JS I write is limited to vanilla JS with no JS dependencies (the minification is done by a Python library which might depend on JS, but it's abstracted away enough that I don't have to know). There needs to be a serious amount of justification to even install Node/NPM as part of a project. The vast majority of work is done on the backend, with JS only being used for UX. I used to pull in React+ReactDOM on some projects, but Web components are paving the way for that to no longer be necessary. As I mentioned elsewhere, it's possible to pull all of pip into a Python project and have all the same problems, but the culture around Python isn't quite as myopic as the JS community, so I've generally been able to keep dependencies more sparse when working on Python teams.
ibz 4y ago
WASM?

jamal-kumar 4y ago

Getting proficient with Go has been the best move of my career to date. It's such a productive language, and you don't have the same drowning in dependencies problems whatsoever becuase the stdlib and a few packages around it are just so strong. I like being able to show off a very small go.mod to a boss who's been putting up with NPM hell for the better part of a decade. I like typescript, I've tried Deno but it's just insane to me how people get caught up in all the hype around the NPM ecosystem only to end up crashing into walls like 'entire system shutting down' with no idea how to fix it. Friend who came before me hit me up asking about a 'linux problem' and it was just webpack crashing his entire computer with semaphore exhaustion. I keep that stuff confined to where it was spawned from, in the browser, anywhere else just doesn't feel sane to me.

weatherlite 4y ago

You're just lucky to work in a company with a good codebase. I'm sure there's plenty toxic environments with shitty codebases written in Go where you wouldn't like working there at all. You're giving too much credit to how much the programming language matters imo.

cloverich 4y ago
You are correct to an extent, but its a fallacy to assume the language and tooling have no impact on the culture or people it attracts. Go is very specifically not "elegant", it has a stdlib where npm has hundreds of dependencies which differ between projects. Errors in JS (Ruby, etc) can come from unexpected places, but the code can elegantly hide them. In Go they are in your face at all times -- but then they rarely surprise you. etc. Its a series of trade offs that are more than simple choices IMO, they target and attract different audiences. And to an extent many people will likely gel better with one than the other. Its only a piece of the puzzle to be sure and the people and company matter more, but I strongly disagree that languages / frameworks matter little. I think those with big differences (Node/Ruby vs Go) there's probably a substantial difference in "average" workplace culture.
- weatherlite 4y ago
  > You are correct to an extent, but its a fallacy to assume the language and tooling have no impact on the culture or people it attracts If the company is doing anything web related it will have JS people somewhere right? And it might also choose to make everyone full stack (so doing both Go and JS) or making some of the teams hybrid. That's quite common. I don't really see much difference between a company that chooses Go to a company that chooses Node (or Ruby, whatever), they both have their pros and cons and it doesn't tell me that much about the people I'll be working with.

throwaway020623 4y ago

I have several side projects where I use a simple Spring Boot backend and I feel I can focus more on the fun part (solving problems). It just works! There is also a huge eco system of good quality open source libraries compared to some of the newer backend languages. This feeling is absent from React-based apps. The React eco system has been around for many years now, but is missing many of the advantages age typically brings. The eco system feels much more fragile and driven by hype. I simply don't trust things to work as smoothly. Maybe this instability is what keeps React popular? If it becomes more stable, it will not generate as much hype and developers move to the next big thing.

ragnarsson 4y ago
My experience with React has been different hence commenting here. That is just not true. I have used react with nextjs in the past but moved to remix. Moving to a new framework requires you to learn it, quite similar to learning a new language but it is much better than manually creating webpack loaders. I had a decent experience with nextjs but my experience with remix has been better. I used Spring Boot at work and I have worked with backend libraries like Express(JS), Flask(Python), Gin(go) all the experiences have been much better than using Spring Boot. Java takes too long to compile, dependecy injection in Spring just seems to take forever, and overall Java is very very verbose. Just to create a stupid API, you have to create a new class for request, one for response, controller, service. I can do it if I am paid for it but using that for side projects, a big NO.
- throwaway020623 4y ago
  I think we have different ideas about what a good development environment is, and that is ok. We have our preferences and we can't argue with that. I would like to comment on how you feel Java compilation is slow. Incremental compilation while developing is fast and doesn't affect my productivity (your experience may differ). Triggering a single threaded full build with one of my services (1000+ files and 80k lines) took less than 30 seconds on my laptop (18s with parallel compilation). But I never do that locally, as incremental compilations are almost instant. If you need to download dependencies and run tests, the number is higher, but that is not specific for Java