3 ms·
I'm kind of a broken record in this sense, but I'll say again that one can pay too much attention to HN and, if they do, they might come to believe that PHP and
by ravenstine 6y ago
I'm kind of a broken record in this sense, but I'll say again that one can pay too much attention to HN and, if they do, they might come to believe that PHP and Ruby are far too slow for most cases and that only serious developers write their backend in Elixir, Python, or Rust, use NoSQL, integrate Kafka for a data pipeline, build frontends in TypeScript or Elm with Svelte, WebPack or GTFO, and containerize everything and scale out with K8s.
99% of the developers here aren't even close to needing to think in terms of that scale, beyond simply not doing dumb things in your code that can happen no matter what tools you use. Hell, there are whole companies that don't need to do these things. A few companies I've worked for or contracted with were bogged down, IMO, because someone couldn't settle for "adequate", making the company suffer because their architecture is so hard to figure out.
I like using "boring" tech(in particular Ember.js, Node.js, Ruby, CouchDB and PostgresSQL/SQLite) because if something gets the job done in a reasonable amount of time, most of which I think comes down to having a competency with a set of tools, then I really don't care very much for drinking from the firehose of frameworks and libraries.
Letting go of ego is tough but, when you do, you're freed from the need to be "like Twitter" or "like Uber" and instead just build things using tools you are genuinely interested in or work for you. It's one thing if you really have the desire to be the kind of wizard to work at Google(and not be relegated to writing shell scripts all day), but if that isn't for you that's fine because the vast majority of jobs out there don't need an archmage.
What most companies need is someone who is going to KISS and not eff things up. If you can do that, you'll have a hard time getting fired even if you sometimes slack off.
- mattlondon 6y agoValid comments but there really is no reason not to use Typescript these days if you are considering JavaScript. Even for small/single-person projects there is no reason not to use it given its benefits and the fact that it takes 10 minutes to learn if you are a JavaScript developer already.
- brendanmc6 6y agoI’ll die on that hill— back when I was interviewing for my next frontend position I told all my prospects I wasn’t interested in working for them if they aren’t using TypeScript or at least open to migrating. There really is no reason to use plain JS for anything!
- schwartzworld 6y ago> There really is no reason to use plain JS for anything unless you don't want to compile your code. I can spin up little projects that don't need a build step just fine.
- schwartzworld 6y agoTypescript programming invariably results in time spent figuring out how to properly type otherwise valid JavaScript code, ie debugging code that doesn't wind up in your app. In a large app, the types can be their own special form of spaghetti. The typing system is clunky and inelegant compared to Elm, which is what I would use for a non-JavaScript frontend. I'd never greenfield a project with TS if I could avoid it.
- emilecantin 6y ago> In a large app, the types can be their own special form of spaghetti. I have a relatively neutral opinion of Typescript, but oh boy does that quote ring true. TS can be a very nice safety net when refactoring (just fix all the type errors, and the app should mostly work as it did before), but you can also very well paint yourself in a corner with similar-but-slightly-different types all over the place that'd just work if it was in JS.
- stank345 6y agoYeah, agreed, but it's nice that it gives you the flexibility to be able to throw a `// @ts-ignore` in there and tell the compiler not to worry about it. I've definitely done that when consuming wonky libraries with messed up type definitions.
- stank345 6y agoI agree that TypeScript's type system is clunky compared to Elm, but being able to add a good amount of type safety with such a small learning curve and a large ecosystem at your disposal is a massive win. And Elm has its own problems (breaking changes, awkwardness of ports, lack of libraries).
- nicoburns 6y agoI think that 'boring' technologies are actually the HN consensus. Few technologies get more praise on HN than Postgres (or even SQLite), and frameworks like Rails, Django, and Laravel also get a lot of positive reviews. Sometimes newer technologies get hyped, but interestingly the most popular ones like React and Rust are also quite boring in many senses (React introduced a new model of programming web views, but stuck to plain JavaScript concepts, didn't try to reinvent the wheel for every component (e.g. like Angular having it'a own special http library) and has been incredibly reliable with few breaking changes from day 1. Rust introduced the idea of a borrow checker, but otherwise intentional borrows most of it'a ideas from other langauges and doesn't try to invent new ways of doing things, and again is incredobly stable and reliable from an implementation point of view)
- rmdashrfstar 6y agoWhat’s not “boring” about developing a backend in Rust? Rust is one of the most boring languages I can think of.