5 ms·

But "Javascript makes you build shit software" isn't actionable in the sense that its definitely incorrect.

gameswithgo 7y ago
There is some truth to it. The whole ecosystem encourages a lot of things that are bad for developing simple, stable, good performing systems. I don't go anywhere near that world unless I have to for these reasons. You get all the downsides of dynamic language ecosystems, with worse compile times than Rust (webpack etc).
- rhengles 7y ago
  In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify. I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity. It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence. [0] https://news.ycombinator.com/item?id=20270816 https://news.ycombinator.com/item?id=20270816
- scarface74 7y ago
  I try to know just enough of the $cool_kids front end stack to pass an interview, but I’m very honest - I don’t like front end development and that’s not my forte. Besides, front end developers are a dime a dozen. Your typical software as a service CRUD company, is looking for mere competence and pays at that rate. I have no interest in competing in a commodity market.
cwp 7y ago
It's not Javascript that makes you write shit software. It's trying to write software that runs correctly on a wide variety of platforms that you don't control. reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.
- dsego 7y ago
  It's definitely not about the environment. Yes, there are browser inconsistencies, but for the most part, this is not a major issue today. The problem of js apps is handling asynchronicity, having to fetch data from the server and managing UI state and in the case of an SPA, having to take care of routing, permissions, timeouts, errors etc. When you sum it all up, you end up with a front-end that mostly needs to replicate all logic from the server, apart from running the sql queries. On the other side, when you render on the server, everything is already there. It's easy to write logic when the data you need is an sql query away and all you need to do is spit out some html. What gets a bit complex is keeping working state between pages and this usually requires handling sessions, cookies etc.
  - cwp 7y ago
    Well, the environment isn't the only factor, but it's the biggest one. You have to take care of routing, permissions, timeouts, errors etc on the server as well. Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client. If you have a UI, you're going to have to manage UI state somewhere. Even if you have no client-side code, you've marshal that state into strings to send to the client, and then parse it all out again on the server when you get the next request. Remember hidden form fields? Heck, this very site has some pretty interesting history about attempts to solve that problem elegantly. It was a PITA. Ultimately, none of that has to do with Javascript; it's inherent in a client-server architecture. The one thing that is specific to JS is asynchronicity. If you don't like that, ok, fair enough, but that's a matter of taste. It has advantages as well as disadvantages, and with Promises and async/await, it's actually pretty elegant. It's certainly not the case that asynchronicity makes you write shit code.
throwaway5d097 7y ago
It's actionable in the sense that it's definitely^Woften correct.

There is some truth to it. The whole ecosystem encourages a lot of things that are bad for developing simple, stable, good performing systems. I don't go anywhere near that world unless I have to for these reasons. You get all the downsides of dynamic language ecosystems, with worse compile times than Rust (webpack etc).

rhengles 7y ago
In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify. I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity. It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence. [0] https://news.ycombinator.com/item?id=20270816 https://news.ycombinator.com/item?id=20270816
scarface74 7y ago
I try to know just enough of the $cool_kids front end stack to pass an interview, but I’m very honest - I don’t like front end development and that’s not my forte. Besides, front end developers are a dime a dozen. Your typical software as a service CRUD company, is looking for mere competence and pays at that rate. I have no interest in competing in a commodity market.

cwp 7y ago

It's not Javascript that makes you write shit software. It's trying to write software that runs correctly on a wide variety of platforms that you don't control. reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.

dsego 7y ago
It's definitely not about the environment. Yes, there are browser inconsistencies, but for the most part, this is not a major issue today. The problem of js apps is handling asynchronicity, having to fetch data from the server and managing UI state and in the case of an SPA, having to take care of routing, permissions, timeouts, errors etc. When you sum it all up, you end up with a front-end that mostly needs to replicate all logic from the server, apart from running the sql queries. On the other side, when you render on the server, everything is already there. It's easy to write logic when the data you need is an sql query away and all you need to do is spit out some html. What gets a bit complex is keeping working state between pages and this usually requires handling sessions, cookies etc.
- cwp 7y ago
  Well, the environment isn't the only factor, but it's the biggest one. You have to take care of routing, permissions, timeouts, errors etc on the server as well. Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client. If you have a UI, you're going to have to manage UI state somewhere. Even if you have no client-side code, you've marshal that state into strings to send to the client, and then parse it all out again on the server when you get the next request. Remember hidden form fields? Heck, this very site has some pretty interesting history about attempts to solve that problem elegantly. It was a PITA. Ultimately, none of that has to do with Javascript; it's inherent in a client-server architecture. The one thing that is specific to JS is asynchronicity. If you don't like that, ok, fair enough, but that's a matter of taste. It has advantages as well as disadvantages, and with Promises and async/await, it's actually pretty elegant. It's certainly not the case that asynchronicity makes you write shit code.

throwaway5d097 7y ago

It's actionable in the sense that it's definitely^Woften correct.