A software engineer interested in solving real problems, developer productivity & learning languages for fun. Primarily working on Node.js, React & databases. Current Interest: Rustlang
I have worked on both ends and I'm more comfortable in backend. I will list them as below:
1) Asynchronous nature: Non-js backend devs think programs are sequential. fetch(url) will directly return value. This is a myth which will make a lot of people skeptical.
2) CSS: There are great resources which different parts of css. Ex: learn everything about position in 5 minutes, Learn flexbox in 15 mins. But comprehensive learning of CSS AND/OR styling is very hard and needs people to invest lot of time.
These two combined can make a great impact on backend devs learning frontend.
Did you say that non-js backend dev don't understand async or that it's a myth people belive? I'm mean first case is offff so much I can't see it. Asyc has been on back long before js existed. It just wasn't considered as useful as today. Hint Erlang and check it's year of development
A software engineer interested in solving real problems, developer productivity & learning languages for fun. Primarily working on Node.js, React & databases. Current Interest: Rustlang
I meant to say that people who are used to traditional backend programming languages like java where the frameworks like spring abstract away the parts which make a server take multiple requests, scale etc. So the code almost executes sequentially in a single path/request. When it comes to frontend, there's a promise.then which we need to call to make it sequential.
I do understand that java had these things known as Futures all the way, but no. of people who use it might not be that big, at least as per my knowledge. So, for me coming from java background initial parts of my career, that was a major place for confusion. That too when there were so many ways to make an api call like xhr, fetch, axios and es6 was kind of new & the confusion between callbacks and promises made me frontend quite hard to master.
Java did lag a bit for async adopting as a language. That's a fair point. However start of Java implemented "Green threads" so read about that one if you already didn't.
However developer lacking the desire to use it is not. RxJava and project Reactor were quite there. Aside from Java which WAS always slow in adopting something (now it's a bit faster but maybe slower to implement), you did have numerous things starting from C# who first implemented async/await keywords (not the idea), as best to my knowelege 2012 official release with 5.0. That's just keyword talk. Scala did a lot also.
So before JavaScript jumped the hype many languages had in fact a whole community asking for async behaviour as pretty as async/await keywords in C# or they started propagating new programming religion about functional and Erlan or it's ruby-ish syntax Elixir and told people OO is bad and horrible and such such. It really depends where you work what kind of image you'll get for this. If you worked with telecoms in Java you would think devs always wanted it. I worked mostly with Java and it's still getting a slow phase there but not because of dev, rather old non easy up-gradable projects. It's not just writting couple of lines it's refactoring the way your libs for connections work and all the things management doesn't like to pay for. It's a bit misleading to think JS had any major impact on adopting it.
Before web there was a lot of UI and... well threads. So idea was there. They knew about async stuff. Just picked wrong tools for certain jobs. Or tools were too much lagging in releasing promised.
Now to push back to topic UI was one of the most influential things to push "async" requirements it just didn't start with the web nor JS. It was poorly implemented but hey we're talking about timeline.
A software engineer interested in solving real problems, developer productivity & learning languages for fun. Primarily working on Node.js, React & databases. Current Interest: Rustlang
Yeah I do agree. when I started maybe 6 years back or so java was where I started with minimal knowledge of async. Maybe that's the reason I found it hard to start. Thanks for the great info.
Cheers
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have worked on both ends and I'm more comfortable in backend. I will list them as below:
1) Asynchronous nature: Non-js backend devs think programs are sequential.
fetch(url) will directly return value. This is a myth which will make a lot of people skeptical.2) CSS: There are great resources which different parts of css. Ex:
learn everything about position in 5 minutes,Learn flexbox in 15 mins. But comprehensive learning of CSS AND/OR styling is very hard and needs people to invest lot of time.These two combined can make a great impact on backend devs learning frontend.
Did you say that non-js backend dev don't understand async or that it's a myth people belive? I'm mean first case is offff so much I can't see it. Asyc has been on back long before js existed. It just wasn't considered as useful as today. Hint Erlang and check it's year of development
I meant to say that people who are used to traditional backend programming languages like java where the frameworks like spring abstract away the parts which make a server take multiple requests, scale etc. So the code almost executes sequentially in a single path/request. When it comes to frontend, there's a promise.then which we need to call to make it sequential.
I do understand that java had these things known as
Futuresall the way, but no. of people who use it might not be that big, at least as per my knowledge. So, for me coming from java background initial parts of my career, that was a major place for confusion. That too when there were so many ways to make an api call like xhr, fetch, axios and es6 was kind of new & the confusion between callbacks and promises made me frontend quite hard to master.Java did lag a bit for async adopting as a language. That's a fair point. However start of Java implemented "Green threads" so read about that one if you already didn't.
However developer lacking the desire to use it is not. RxJava and project Reactor were quite there. Aside from Java which WAS always slow in adopting something (now it's a bit faster but maybe slower to implement), you did have numerous things starting from C# who first implemented async/await keywords (not the idea), as best to my knowelege 2012 official release with 5.0. That's just keyword talk. Scala did a lot also.
So before JavaScript jumped the hype many languages had in fact a whole community asking for async behaviour as pretty as async/await keywords in C# or they started propagating new programming religion about functional and Erlan or it's ruby-ish syntax Elixir and told people OO is bad and horrible and such such. It really depends where you work what kind of image you'll get for this. If you worked with telecoms in Java you would think devs always wanted it. I worked mostly with Java and it's still getting a slow phase there but not because of dev, rather old non easy up-gradable projects. It's not just writting couple of lines it's refactoring the way your libs for connections work and all the things management doesn't like to pay for. It's a bit misleading to think JS had any major impact on adopting it.
Before web there was a lot of UI and... well threads. So idea was there. They knew about async stuff. Just picked wrong tools for certain jobs. Or tools were too much lagging in releasing promised.
Now to push back to topic UI was one of the most influential things to push "async" requirements it just didn't start with the web nor JS. It was poorly implemented but hey we're talking about timeline.
Yeah I do agree. when I started maybe 6 years back or so java was where I started with minimal knowledge of async. Maybe that's the reason I found it hard to start. Thanks for the great info.
Cheers