4 ms·

> Then JavaScript and its modern frameworks ate backend, frontend, and everything in between, and it was time to re-become a web developer in 2017 — who writes

> Then JavaScript and its modern frameworks ate backend, frontend, and everything in between, and it was time to re-become a web developer in 2017 — who writes JavaScript. Gee, I always thought that Javascript was a mediocre language, sufficient for its initial purpose. I assumed that node.js was just someone's idea of "wouldn't it be neat if I could have this on the backend too and use the same representation of data on backend + frontend?" I have to admit it sure does sound popular these days. But I still am under the impression (delusion?) that a dedicated backend implementation in a better-suited-language is what I really need. That said, I have little experience with web dev.

Silhouette 10y ago
I think it's important to keep some perspective here. JavaScript is a popular language for one major reason: for native front-end web development, it has effectively been the only language. If you didn't want to use plug-ins, you were going to use JS. If you wanted to use some other language, it was going to be transpiled to JS. Node is also popular for one major reason: it's the same language that people who do front-end work already know, but running on the back-end. You can (mostly) use the same libraries on either side. You can take someone who's familiar with one side, and they can reasonably quickly be productive writing code for the other. None of this changes the fact that JavaScript is a very mediocre language by modern standards. Like many popular languages, it has improved over time, but like many popular languages that have been around for a while, it has a lot of fundamental warts that you can never fully escape. Neither does any of this change the fact that JavaScript's surrounding tool and library ecosystem is very mediocre by modern standards. The lack of stability, standardisation and longevity cripples progress and results in huge amounts of duplicated or otherwise wasted effort. This is partly a cultural thing, and partly due to technical limitations in a language that was never designed for programming in the large but is now being pressed into service in that role. JavaScript is the language of the moment because web development is the high profile field of the moment, but don't let the blog posts fool you. Enthusiastic but often inexperienced developers working in JavaScript write as if everything else is somehow old-fashioned and out-of-date, yet many ideas hailed as radical advances in the JS community have been absolutely routine in most of the programming world for decades. There are plenty of people getting on with doing useful work -- often much more productively -- using those oh so horrible, old-fashioned, out-of-date tools. They just don't need to shout from the rooftops that they now have a standard way to import code from one file and call it from another one, or to combine code from multiple files but strip out parts that are never used to keep the size of the output down, or to separate input, output and data processing, because the rest of the world was learning these lessons in the 1970s and 1980s. :-)
- tannhaeuser 10y ago
  I partly agree with you but I still like JavaScript and the ecosystem around it. There's something to be said wrt. "worse is better" when it comes to JavaScript, as in "JavaScript is such a crappy language that it has managed to go unnoticed by architecture astronauts for most of the time". By which I mean, JavaScript front-end code of the jquery-era is extremely compact and to the point, avoiding metadata layers and other bloat. In judging JavaScript backend code, lack of experience of developers should be taken into account, who mostly came from front-end developer roles.
disease 10y ago
I have 10+ years of web dev experience and have been underwhelmed with node on the backend. One of the supposed strengths is I/O scalability but in my experience it has little advantage over the JVM or .net so why not just use one of those and get both I/O and computation scaling. I also have not been as impressed with the backend code you can find in node compared to just about anything else. Useful projects are abandoned or obsoleted, documentation can be very poor and the pointless churn is well documented here and elsewhere. Basically all problems you'd expect without a standard library or corporate backing. Though those things hardly seem necessary given the high quality of Elixir/Phoenix or Rails. I guess what I'm trying to say here is you'll be better off using just about anything else on the backend. The only positives that come to mind is having ES6/TS/JSON everywhere and perhaps socket.io is a better option than some JVM/.net server/client communication libraries.
virmundi 10y ago
Node was a good idea for highly connected IO based networking. It think it goes a bit far when used for web development (rendering performs on the main loop). As far as reuse goes, no idea. I've heard mixed reviews. I do know that missing a var or a let can cause big, hard to trace state issues on the server.
- nawitus 10y ago
  "rendering performs on the main loop" - rendering on the backend is not a good idea, just use static templating (e.g. serve a static index.html file to the browser).
  - empthought 10y ago
    There is no practical difference to the server whether it converts data to JSON or converts data to semantic HTML. Either one is rendering, or neither is.

Silhouette 10y ago

I think it's important to keep some perspective here. JavaScript is a popular language for one major reason: for native front-end web development, it has effectively been the only language. If you didn't want to use plug-ins, you were going to use JS. If you wanted to use some other language, it was going to be transpiled to JS. Node is also popular for one major reason: it's the same language that people who do front-end work already know, but running on the back-end. You can (mostly) use the same libraries on either side. You can take someone who's familiar with one side, and they can reasonably quickly be productive writing code for the other. None of this changes the fact that JavaScript is a very mediocre language by modern standards. Like many popular languages, it has improved over time, but like many popular languages that have been around for a while, it has a lot of fundamental warts that you can never fully escape. Neither does any of this change the fact that JavaScript's surrounding tool and library ecosystem is very mediocre by modern standards. The lack of stability, standardisation and longevity cripples progress and results in huge amounts of duplicated or otherwise wasted effort. This is partly a cultural thing, and partly due to technical limitations in a language that was never designed for programming in the large but is now being pressed into service in that role. JavaScript is the language of the moment because web development is the high profile field of the moment, but don't let the blog posts fool you. Enthusiastic but often inexperienced developers working in JavaScript write as if everything else is somehow old-fashioned and out-of-date, yet many ideas hailed as radical advances in the JS community have been absolutely routine in most of the programming world for decades. There are plenty of people getting on with doing useful work -- often much more productively -- using those oh so horrible, old-fashioned, out-of-date tools. They just don't need to shout from the rooftops that they now have a standard way to import code from one file and call it from another one, or to combine code from multiple files but strip out parts that are never used to keep the size of the output down, or to separate input, output and data processing, because the rest of the world was learning these lessons in the 1970s and 1980s. :-)

tannhaeuser 10y ago
I partly agree with you but I still like JavaScript and the ecosystem around it. There's something to be said wrt. "worse is better" when it comes to JavaScript, as in "JavaScript is such a crappy language that it has managed to go unnoticed by architecture astronauts for most of the time". By which I mean, JavaScript front-end code of the jquery-era is extremely compact and to the point, avoiding metadata layers and other bloat. In judging JavaScript backend code, lack of experience of developers should be taken into account, who mostly came from front-end developer roles.

disease 10y ago

I have 10+ years of web dev experience and have been underwhelmed with node on the backend. One of the supposed strengths is I/O scalability but in my experience it has little advantage over the JVM or .net so why not just use one of those and get both I/O and computation scaling. I also have not been as impressed with the backend code you can find in node compared to just about anything else. Useful projects are abandoned or obsoleted, documentation can be very poor and the pointless churn is well documented here and elsewhere. Basically all problems you'd expect without a standard library or corporate backing. Though those things hardly seem necessary given the high quality of Elixir/Phoenix or Rails. I guess what I'm trying to say here is you'll be better off using just about anything else on the backend. The only positives that come to mind is having ES6/TS/JSON everywhere and perhaps socket.io is a better option than some JVM/.net server/client communication libraries.

virmundi 10y ago

Node was a good idea for highly connected IO based networking. It think it goes a bit far when used for web development (rendering performs on the main loop). As far as reuse goes, no idea. I've heard mixed reviews. I do know that missing a var or a let can cause big, hard to trace state issues on the server.

nawitus 10y ago
"rendering performs on the main loop" - rendering on the backend is not a good idea, just use static templating (e.g. serve a static index.html file to the browser).
- empthought 10y ago
  There is no practical difference to the server whether it converts data to JSON or converts data to semantic HTML. Either one is rendering, or neither is.