3 ms·

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do

by devxpy 8y ago

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it! P.S. I don’t, but most people I have met seem to have this kind of mentality.

thrower123 8y ago
Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've got, but it is assuredly not good. Hopefully WebAssembly comes to fruition and we can leave this dark era behind.
- minor3rd 8y ago
  > to do some trivial UI work on the front-end If that takes you forever, consider that it may also be your lack of familiarity as much as the lack of type system/compiler. Despite my preference for the back end, I have spent plenty of time on the front end and can pump out changes very quickly.
- wild_preference 8y ago
  But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me. At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native on Android and iOS. Look at other clients people development for like iOS. It's not easier. And any gains in ease of use are traded off because you're developing for a platform that not everyone uses. Also, continuing with iOS, things like CoreData and the entire UI abstraction are super OOP and not very pleasant (especially the former). And it's nontrivial and a lot more warty to switch out abstractions (like using Rx) or use something other than Swift. So that things are harder that you moved from backend to client development isn't a very scathing review of Javascript because client development isn't easy.
  - devxpy 8y ago
    Look at flutter. Please.
    - wild_preference 8y ago
      Like everything, it has trade-offs and is not a free abstraction.
  - bacro 8y ago
    That is why I love React Native. Things like laying out screens is simple using flex and position properties. Laying out in iOS? Not as simple with those atrocities like auto layout, constraints...
- untog 8y ago
  That isn't surprising because the backend is simple and the frontend is not. By that, I mean that you get to choose your entire playing field on the backend. What language are you going to use? What database? What OS will it run on? What (reliable) network connection? All can be tailored to your heart's desire. No such luck on the frontend. Your code is going to run on a diverse set of clients, which you have no control over. The connection quality might be awful. The CPU on the device might be awful, or it might have low memory. As much as people like to crap on JavaScript, it isn't the reason the front-end is difficult to program for. And WebAssembly isn't going to solve all of these issues either.
  - devxpy 8y ago
    These technical problems you present, are difficult but solvable if a big player is willing to pitch in. I don't like to target specific words, but the problems you specify apply to JS as much as they do to any other language. A C/rust like language has far better CPU/memory efficiency than JS. A batteries included language like python might even be better at network latency since it doesn't have to bundle in the code that should've been in a stdlib, not client code. We use different languages because they are good at different things. The browser doesn't seem to respect this Philosophy :(

by devxpy 8y ago

thrower123 8y ago

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've got, but it is assuredly not good. Hopefully WebAssembly comes to fruition and we can leave this dark era behind.

minor3rd 8y ago
> to do some trivial UI work on the front-end If that takes you forever, consider that it may also be your lack of familiarity as much as the lack of type system/compiler. Despite my preference for the back end, I have spent plenty of time on the front end and can pump out changes very quickly.
wild_preference 8y ago
But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me. At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native on Android and iOS. Look at other clients people development for like iOS. It's not easier. And any gains in ease of use are traded off because you're developing for a platform that not everyone uses. Also, continuing with iOS, things like CoreData and the entire UI abstraction are super OOP and not very pleasant (especially the former). And it's nontrivial and a lot more warty to switch out abstractions (like using Rx) or use something other than Swift. So that things are harder that you moved from backend to client development isn't a very scathing review of Javascript because client development isn't easy.
- devxpy 8y ago
  Look at flutter. Please.
  - wild_preference 8y ago
    Like everything, it has trade-offs and is not a free abstraction.
- bacro 8y ago
  That is why I love React Native. Things like laying out screens is simple using flex and position properties. Laying out in iOS? Not as simple with those atrocities like auto layout, constraints...
untog 8y ago
That isn't surprising because the backend is simple and the frontend is not. By that, I mean that you get to choose your entire playing field on the backend. What language are you going to use? What database? What OS will it run on? What (reliable) network connection? All can be tailored to your heart's desire. No such luck on the frontend. Your code is going to run on a diverse set of clients, which you have no control over. The connection quality might be awful. The CPU on the device might be awful, or it might have low memory. As much as people like to crap on JavaScript, it isn't the reason the front-end is difficult to program for. And WebAssembly isn't going to solve all of these issues either.
- devxpy 8y ago
  These technical problems you present, are difficult but solvable if a big player is willing to pitch in. I don't like to target specific words, but the problems you specify apply to JS as much as they do to any other language. A C/rust like language has far better CPU/memory efficiency than JS. A batteries included language like python might even be better at network latency since it doesn't have to bundle in the code that should've been in a stdlib, not client code. We use different languages because they are good at different things. The browser doesn't seem to respect this Philosophy :(