4 ms·

I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and on

I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If thats worth it is something that depends on what you try to achive, I guess. I personally would not pick JS (nor TS) for the backend.

biztos 4y ago
And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
- ggktk 4y ago
  Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
  - jpgvm 4y ago
    There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.
    - afiori 4y ago
      Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS). In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)
  - marcosdumay 4y ago
    WASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS. Rust, for example, has a huge package with interfaces for every DOM function.
- szundi 4y ago
  I am waiting to be able to run the JVM and have client side swing again in WASM
  - pjmlp 4y ago
    Why waiting when it is already available?
- marcosdumay 4y ago
  I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot. But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it. Wasm would be much more compelling if it was target by higher level languages.
jpgvm 4y ago
I think this has been a huge failing of our industry of late. The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth as a result of switching. (as a side note I also think it's contributed to developer title inflation) Learning a new language and its tooling is comparatively easy compared to learning the required domain knowledge to be effective in a new area. i.e transition from frontend -> backend or visa versa has very little to do with the language or tooling. Your average frontend dev doesn't know squat about RDBMS schema design or query optimisation, probably aren't familar with backend observability patterns like logging, metrics and tracing, most likely have very little experience thinking about consistency and concurrency in distributed systems, etc, etc. Just like the backend dev is going to struggle with the constraints of working in a frontend context, understanding UI interactions, optimizing for browser paint performance, dealing with layout and responsiveness, etc. Meanwhile if you know say Java and some scripting language, say Python and you end up a new job doing backend in JS it's not going to take long for you to pick up JS and hit the ground running because you are going to encounter exactly the same stuff just different syntax and runtime. Backend being substantially divorced from frontend isn't a bad thing, it's generally a good thing that results in nice clean separation of concerns and healthy push-pull in design decisions about where certain logic and responsibilities should lie etc.
- bigDinosaur 4y ago
  Most 'fullstack' positions don't have nearly the complexity where worrying about concurrency etc. is actually that relevant. The idea that most frontend devs have any knowledge about optimising for browser paint performance beyond using the correct CSS or framework is funny ;-)
  - jpgvm 4y ago
    I know, we have seen insane developer inflation the last 10 years. The bar is generally just a lot lower now across the board. We have people with the title "Senior Engineer" that still regularly need mentorship and peer-programming sessions. The title I have now (Principal Engineer) I feel like I don't deserve, it was reserved for folks I looked up to when I was starting and I don't think I have reached their level. Yet at the same time it's essentially necessary to distinguish myself from what is now considered "Senior". I have a separate rant for the lack of proper juniors and lack of structured mentoring etc but that is for another day.
kristopolous 4y ago
It's a taxonomy problem. The chunking unit is programming languages which means as long as you can call the task the specific programming language, people will believe it's the same thing. In reality you have a hammer expert and are in the business of making everything look like a nail. So now we have complicated bloated applications of JavaScript in places where it's absolutely inappropriate and you need far more skill to navigate those waters then someone who uses more appropriate tools. It's a perversion in the name of simplicity because we're forcing too coarse of a model on too fine of a problem and as a result everything explodes in complexity, takes too long, is too expensive and comes out working like trash. We could do better but first we have to eat crow and admit how foundationally wrong we were and frankly things aren't bad enough to make that mandatory so the circus continues just like it did when we tried to make everything OOP and it made the same smell. They're useful tools, but that's their perimeter; they aren't zeitgeists... well they shouldn't be.
marcosdumay 4y ago
> which is a fair point It's a very effective way to make sure your team is only composed by junior developers.

biztos 4y ago

And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?

ggktk 4y ago
Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
- jpgvm 4y ago
  There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.
  - afiori 4y ago
    Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS). In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)
- marcosdumay 4y ago
  WASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS. Rust, for example, has a huge package with interfaces for every DOM function.
szundi 4y ago
I am waiting to be able to run the JVM and have client side swing again in WASM
- pjmlp 4y ago
  Why waiting when it is already available?
marcosdumay 4y ago
I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot. But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it. Wasm would be much more compelling if it was target by higher level languages.

jpgvm 4y ago

I think this has been a huge failing of our industry of late. The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth as a result of switching. (as a side note I also think it's contributed to developer title inflation) Learning a new language and its tooling is comparatively easy compared to learning the required domain knowledge to be effective in a new area. i.e transition from frontend -> backend or visa versa has very little to do with the language or tooling. Your average frontend dev doesn't know squat about RDBMS schema design or query optimisation, probably aren't familar with backend observability patterns like logging, metrics and tracing, most likely have very little experience thinking about consistency and concurrency in distributed systems, etc, etc. Just like the backend dev is going to struggle with the constraints of working in a frontend context, understanding UI interactions, optimizing for browser paint performance, dealing with layout and responsiveness, etc. Meanwhile if you know say Java and some scripting language, say Python and you end up a new job doing backend in JS it's not going to take long for you to pick up JS and hit the ground running because you are going to encounter exactly the same stuff just different syntax and runtime. Backend being substantially divorced from frontend isn't a bad thing, it's generally a good thing that results in nice clean separation of concerns and healthy push-pull in design decisions about where certain logic and responsibilities should lie etc.

bigDinosaur 4y ago
Most 'fullstack' positions don't have nearly the complexity where worrying about concurrency etc. is actually that relevant. The idea that most frontend devs have any knowledge about optimising for browser paint performance beyond using the correct CSS or framework is funny ;-)
- jpgvm 4y ago
  I know, we have seen insane developer inflation the last 10 years. The bar is generally just a lot lower now across the board. We have people with the title "Senior Engineer" that still regularly need mentorship and peer-programming sessions. The title I have now (Principal Engineer) I feel like I don't deserve, it was reserved for folks I looked up to when I was starting and I don't think I have reached their level. Yet at the same time it's essentially necessary to distinguish myself from what is now considered "Senior". I have a separate rant for the lack of proper juniors and lack of structured mentoring etc but that is for another day.

kristopolous 4y ago

It's a taxonomy problem. The chunking unit is programming languages which means as long as you can call the task the specific programming language, people will believe it's the same thing. In reality you have a hammer expert and are in the business of making everything look like a nail. So now we have complicated bloated applications of JavaScript in places where it's absolutely inappropriate and you need far more skill to navigate those waters then someone who uses more appropriate tools. It's a perversion in the name of simplicity because we're forcing too coarse of a model on too fine of a problem and as a result everything explodes in complexity, takes too long, is too expensive and comes out working like trash. We could do better but first we have to eat crow and admit how foundationally wrong we were and frankly things aren't bad enough to make that mandatory so the circus continues just like it did when we tried to make everything OOP and it made the same smell. They're useful tools, but that's their perimeter; they aren't zeitgeists... well they shouldn't be.

marcosdumay 4y ago

> which is a fair point It's a very effective way to make sure your team is only composed by junior developers.