4 ms·

The best thing that happened to me as a JavaScript developer was being exposed to other languages. Especially the not-so-fancy Java and C++, really opened my mi

by fridek 11y ago

The best thing that happened to me as a JavaScript developer was being exposed to other languages. Especially the not-so-fancy Java and C++, really opened my mind about structuring code and planning for a long-term project. Knowing JavaScript and JavaScript frameworks is surprisingly useless for the type of work JS devs usually handle. The documentation often consists of TodoMVC type of examples and approaches. Hardly anyone explains how patterns like DDD, SOLID, advanced REST, etc. fit into this. The highly appraised Flux is in reality just a pub/sub system like many on backend (and still it's a huge step forward - it admits JS systems are large and complex). I'm just looking at a system design graph, preparing for a new job. There are about 30 nodes representing multiple services, databases, load balancers and processes on the backend. There are two for frontend - one says "JS" and the other "JSON". This is how most people think about frontend and to be a great JavaScript developer just don't be one of them.

jakub_g 11y ago
I agree a lot with it. I also think it's useful to work with at least one statically-typed language (like Java for example) because it teaches some good maintainability practices. In JS world, I've seen far too often creating objects in random places, as a map of parameters, passing them around, and injecting new keys to the object in other random places, and when such an object goes around too much and is augmented randomly in a myriad of ways, it's really hard to reason about it. In Java, you'd typically create a separate class for such an object, create fields, assign types to them and document them, and have a constructor which populates the fields with sensible defaults if not provided. Sometimes it's an overkill to do it this way, but often it pays off with a better understanding of the data model. In JS you have a lot of freedom, but too much freedom leads often to a mess when enough people are working on the code.
- Roboprog 11y ago
  I enjoy the freedom to use a map/object/parameter object as named parameters, speaking as somebody who has suffered through much Java ceremony. That said, JSDoc helps a lot: make a @typedef comment for parameter objects at the top of a file, then use the type in the @param annotations of the relevant functions. Makes understanding the JS code in an IDE much easer, as well as having something worth generating HTML documentation from.
dj_doh 11y ago
I second this. Sometime back I did Python for a production work. That for the first time gave me a true sense of Object-based inheritance v/s class based inheritance. Prior to that I used take JS way as-is. But wholeheartedly, may be not so much.
notNow 11y ago
Why would a front-end system be more complex than its back-end counterpart? It just doesn't make any sense.
- fridek 11y ago
  I never said it should be more complex. It, however, should be also structured somehow. There is a persistence layer, models, collections, services reasoning about them and pipelines aggregating and rendering things. Well written JavaScript is reasonably fast and it now makes sense to optimize transported information size. Many calculations can be done front-end side then, which accidentally is also more cost-effective, since data center usage is paid, while user CPUs are more or less free (and not doing much while browsing anyway).

by fridek 11y ago

jakub_g 11y ago

I agree a lot with it. I also think it's useful to work with at least one statically-typed language (like Java for example) because it teaches some good maintainability practices. In JS world, I've seen far too often creating objects in random places, as a map of parameters, passing them around, and injecting new keys to the object in other random places, and when such an object goes around too much and is augmented randomly in a myriad of ways, it's really hard to reason about it. In Java, you'd typically create a separate class for such an object, create fields, assign types to them and document them, and have a constructor which populates the fields with sensible defaults if not provided. Sometimes it's an overkill to do it this way, but often it pays off with a better understanding of the data model. In JS you have a lot of freedom, but too much freedom leads often to a mess when enough people are working on the code.

Roboprog 11y ago
I enjoy the freedom to use a map/object/parameter object as named parameters, speaking as somebody who has suffered through much Java ceremony. That said, JSDoc helps a lot: make a @typedef comment for parameter objects at the top of a file, then use the type in the @param annotations of the relevant functions. Makes understanding the JS code in an IDE much easer, as well as having something worth generating HTML documentation from.

dj_doh 11y ago

I second this. Sometime back I did Python for a production work. That for the first time gave me a true sense of Object-based inheritance v/s class based inheritance. Prior to that I used take JS way as-is. But wholeheartedly, may be not so much.

notNow 11y ago

Why would a front-end system be more complex than its back-end counterpart? It just doesn't make any sense.

fridek 11y ago
I never said it should be more complex. It, however, should be also structured somehow. There is a persistence layer, models, collections, services reasoning about them and pipelines aggregating and rendering things. Well written JavaScript is reasonably fast and it now makes sense to optimize transported information size. Many calculations can be done front-end side then, which accidentally is also more cost-effective, since data center usage is paid, while user CPUs are more or less free (and not doing much while browsing anyway).