4 ms·

I am also a classic web developer, still using vanilla javascript and trying to do as much as possible with just html and css. I feel I can solve any problem fa

by olavgg 8y ago

I am also a classic web developer, still using vanilla javascript and trying to do as much as possible with just html and css. I feel I can solve any problem fast, quick and with minimal amount of code and bugs. For the recent years I have hired a few javascript developers and a common pattern I see is that the reason why they want to use overcomplicated toolset, is because this helps improving their CV so they are easier to sell. CV building is a thing, and developers also want to stay relevant in the future. For example I went through software developer job listings in my area. Of 100 listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any kind of frontend development like html/css/jquery. The rest is classical back end positions. There is a HUGE demand for frontend expertise these days. If you as a consultant want to sell yourself as a kickass rockstar frontend developer, you want as much React experience as possible on your CV. Some will even turn you down because of the fear of damaging their CV by just doing vanilla javascript work.

JohnFen 8y ago
> still using vanilla javascript and trying to do as much as possible with just html and css. Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much. If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.
bernawil 8y ago
Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.
- mosdl 8y ago
  React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
  - phponpcp 8y ago
    Yeah I dont know about that. If you've ever had to deal with optimizing event delegation and updating the DOM without causing massive repaints you'd change your tune.
  - bernawil 8y ago
    Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done: 1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements. some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away. I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.
bitwize 8y ago
Ah, good old Resume Driven Development. I've seen it and even done a little of it.

by olavgg 8y ago

JohnFen 8y ago

> still using vanilla javascript and trying to do as much as possible with just html and css. Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much. If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.

bernawil 8y ago

Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.

mosdl 8y ago
React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
- phponpcp 8y ago
  Yeah I dont know about that. If you've ever had to deal with optimizing event delegation and updating the DOM without causing massive repaints you'd change your tune.
- bernawil 8y ago
  Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done: 1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements. some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away. I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.

bitwize 8y ago

Ah, good old Resume Driven Development. I've seen it and even done a little of it.