7 ms·

For me 2012 was the year I stopped any frontend work at all. As I remember, things felt very easy and natural when all I had to do was output html using templat

by kh_hk 4y ago

For me 2012 was the year I stopped any frontend work at all. As I remember, things felt very easy and natural when all I had to do was output html using templates, write CSS and add some touches of javascript here and there, either using jquery or mootools. Maybe a websocket to display something coming from a process. Then there was backbone, history push state, more frameworks, client side rendering, meteor, and a lot of impressive stuff. Very impressive stuff that felt needlessly complicated and made me procrastinate every time I tried to learn it. Nowadays, every time I look at a react codebase I feel certain emotions I can only describe as disgust. Maybe I have only seen bad codebases.

wildrhythms 4y ago
Not sure what you find 'disgusting' about a function that returns HTML; if anything it is more 'natural' than the templating and jQuery amalgamations of the past.
brailsafe 4y ago
I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems. For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way. It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would. Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things. I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.
- kh_hk 4y ago
  On the contrary, I enjoy a good discussion! I do totally get the point of using a framework like React or Vue to manage state on a complex app. I do purposefully call them apps, because websites are a more general term. Hand woven javascript UI, even if it was using an utility framework like mootools could get out of hand pretty easily. I recall things like extjs that were also popular. Following my own example, managing push state by hand was tricky. So I did buy in on the premise that an opinionated way of structuring help and more importantly state was necessary. But I have been consistently failing to learn any new frontend tool ever since. This was not terrible professionally, since I mostly do what most refer to backend or systems. But still it is a bit frustrating not being able to follow along. Maybe it would be easier if this was 'it' when I started learning as sometimes it's difficult to forget and relearn. Speaking of React / Vue codebases, I have thrice tried to contribute some changes or fix a bug on different projects and the amount of boilerplate I had to go through felt completely unnecessary and overkill. Maybe the pattern on these never 'clicked' or I was very unlucky to stumble unto bad examples. It's very easy to dismiss something one does not understand as unnecessary complex so I am still open minded about it. The feeling of disgust when I see the many levels of inference, types and juggling state around for UX that I see as pretty basic persists, though. I like the result, I abhor the execution.
  - soneca 4y ago
    I would think that “feeling disgust” and ”being open minded” are mutually exclusive. So my impression from your post is that you are not being honest (to us or to yourself) about being open minded.
    - kh_hk 4y ago
      I do not see why these are exclusive: When I read the code, I can't control feeling disgusted by what I see. Specially how every base starts with an opinionated and strong "this is how it's done" style, just to devolve into copypaste and hacks because someone didn't understand state, reductors, types, dispatchers, ... but I am open minded about acknowledging that the problem might be mine, be it because of stubborness on not getting it, or being extremely unlucky on what projects I stumble upon.
pjmlp 4y ago
Same here, I went back to native desktop development, and nowadays I am mostly focused on backends in what concerns Web development. If I need to do WebUI stuff on my own, it is classical vanilajs with SSR in Java/.NET frameworks.
schwartzworld 4y ago
React is awesome, but there is a learning curve to using it well, moreso since hooks came out. Being able to define your view as a pure function based on your state is a very powerful.l abstraction, but it took me about 2 years to learn to wield it well.
moffkalast 4y ago
> Maybe I have only seen bad codebases Maybe there are no good react codebases because it encourages bad code. The whole concept of having both code and structure definitions in the same file is just flawed at its core. Like deliberately writing all your js in html script tags for some reason, except with functional-style syntax that just makes it look more cryptic to newcomers for no reason at all.
j45 4y ago
Building front end apps has become more complex than it used to be 20 years ago to effectively output the same html. Granted there is a level of interactivity that is different for the complexity, mostly I look forward to the grand complexities of todays frameworks to continue to simplicity and be approachable.
- wildrhythms 4y ago
  As soon as you need to 1) render a list of widgets asynchronously, 2) update widget #182 of 250 without re-rendering the whole widget tree, you start to realize that these front-end frameworks have solved the problems that we used to spend hours writing fiddly and confusing jQuery functions to address.
  - j45 4y ago
    No doubt. Still things get more complex before they get streamlined. Frameworks like svelte, vue, and even flutter to a degree feel different than react when putting together similar experiences in some cases.
whostolemyhat 4y ago
- kh_hk 4y ago
  javascript is a fine language. Language is not the same as code, just as language is not the same as literature.
jb3689 4y ago
The thing that bothers me about React and other frameworks is the look of the code. React components look like every other React component. There are few signals of “hey, I’m a dropdown” or “hey, I’m a table” due to caked on layers of abstraction and indirection. One thing I like about serverside code is that a tree processor looks like a tree processor while a state machine looks like a state machine. I don’t have to think hard and can use pattern recognition
jpcapdevila 4y ago
Maybe you will like https://svelte.dev/ https://svelte.dev/, I find it more close to good old html. For example, a component that is not interactive is basically an html file with an <style> tag and some html markup.
- oaiey 4y ago
  I feel the OP. It is not about HTML alone. It is about the lack of understanding of the full picture. About the fact, that you cannot rationalize everything. That everything is three layers away. The problem with the OP feeling (and mine) is that there are shoulders of giants. You either stand on them or not. If you are not, you start on much lower level of features ;)
  - jpcapdevila 4y ago
    Makes sense and I agree. For simple things I still do vanilla js. As soon as I need to re-use components or shared state between pages I go with sveltekit.
tomhoward 4y ago
It was much the opposite for me. I started building websites amaterishly from about 1995, and professionally from about 2001, and always hated how complicated and messy my code became any time I wanted to build rich functionality (i.e., a web-app rather than a website). That first changed for me when I discovered ExtJS (now Sencha) in 2007, then later Angular and finally React in 2017. These days I work almost daily on a React web-app I've built for displaying realtime weather/climate data for farmers, and it continues to be a very pleasing codebase to work with, more so than any I've worked on before.

by kh_hk 4y ago

wildrhythms 4y ago

Not sure what you find 'disgusting' about a function that returns HTML; if anything it is more 'natural' than the templating and jQuery amalgamations of the past.

brailsafe 4y ago

I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems. For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way. It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would. Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things. I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.

kh_hk 4y ago
On the contrary, I enjoy a good discussion! I do totally get the point of using a framework like React or Vue to manage state on a complex app. I do purposefully call them apps, because websites are a more general term. Hand woven javascript UI, even if it was using an utility framework like mootools could get out of hand pretty easily. I recall things like extjs that were also popular. Following my own example, managing push state by hand was tricky. So I did buy in on the premise that an opinionated way of structuring help and more importantly state was necessary. But I have been consistently failing to learn any new frontend tool ever since. This was not terrible professionally, since I mostly do what most refer to backend or systems. But still it is a bit frustrating not being able to follow along. Maybe it would be easier if this was 'it' when I started learning as sometimes it's difficult to forget and relearn. Speaking of React / Vue codebases, I have thrice tried to contribute some changes or fix a bug on different projects and the amount of boilerplate I had to go through felt completely unnecessary and overkill. Maybe the pattern on these never 'clicked' or I was very unlucky to stumble unto bad examples. It's very easy to dismiss something one does not understand as unnecessary complex so I am still open minded about it. The feeling of disgust when I see the many levels of inference, types and juggling state around for UX that I see as pretty basic persists, though. I like the result, I abhor the execution.
- soneca 4y ago
  I would think that “feeling disgust” and ”being open minded” are mutually exclusive. So my impression from your post is that you are not being honest (to us or to yourself) about being open minded.
  - kh_hk 4y ago
    I do not see why these are exclusive: When I read the code, I can't control feeling disgusted by what I see. Specially how every base starts with an opinionated and strong "this is how it's done" style, just to devolve into copypaste and hacks because someone didn't understand state, reductors, types, dispatchers, ... but I am open minded about acknowledging that the problem might be mine, be it because of stubborness on not getting it, or being extremely unlucky on what projects I stumble upon.

pjmlp 4y ago

Same here, I went back to native desktop development, and nowadays I am mostly focused on backends in what concerns Web development. If I need to do WebUI stuff on my own, it is classical vanilajs with SSR in Java/.NET frameworks.

schwartzworld 4y ago

React is awesome, but there is a learning curve to using it well, moreso since hooks came out. Being able to define your view as a pure function based on your state is a very powerful.l abstraction, but it took me about 2 years to learn to wield it well.

moffkalast 4y ago

> Maybe I have only seen bad codebases Maybe there are no good react codebases because it encourages bad code. The whole concept of having both code and structure definitions in the same file is just flawed at its core. Like deliberately writing all your js in html script tags for some reason, except with functional-style syntax that just makes it look more cryptic to newcomers for no reason at all.

j45 4y ago

Building front end apps has become more complex than it used to be 20 years ago to effectively output the same html. Granted there is a level of interactivity that is different for the complexity, mostly I look forward to the grand complexities of todays frameworks to continue to simplicity and be approachable.

wildrhythms 4y ago
As soon as you need to 1) render a list of widgets asynchronously, 2) update widget #182 of 250 without re-rendering the whole widget tree, you start to realize that these front-end frameworks have solved the problems that we used to spend hours writing fiddly and confusing jQuery functions to address.
- j45 4y ago
  No doubt. Still things get more complex before they get streamlined. Frameworks like svelte, vue, and even flutter to a degree feel different than react when putting together similar experiences in some cases.

whostolemyhat 4y ago

kh_hk 4y ago
javascript is a fine language. Language is not the same as code, just as language is not the same as literature.

jb3689 4y ago

The thing that bothers me about React and other frameworks is the look of the code. React components look like every other React component. There are few signals of “hey, I’m a dropdown” or “hey, I’m a table” due to caked on layers of abstraction and indirection. One thing I like about serverside code is that a tree processor looks like a tree processor while a state machine looks like a state machine. I don’t have to think hard and can use pattern recognition

jpcapdevila 4y ago

Maybe you will like https://svelte.dev/ https://svelte.dev/, I find it more close to good old html. For example, a component that is not interactive is basically an html file with an <style> tag and some html markup.

oaiey 4y ago
I feel the OP. It is not about HTML alone. It is about the lack of understanding of the full picture. About the fact, that you cannot rationalize everything. That everything is three layers away. The problem with the OP feeling (and mine) is that there are shoulders of giants. You either stand on them or not. If you are not, you start on much lower level of features ;)
- jpcapdevila 4y ago
  Makes sense and I agree. For simple things I still do vanilla js. As soon as I need to re-use components or shared state between pages I go with sveltekit.

tomhoward 4y ago

It was much the opposite for me. I started building websites amaterishly from about 1995, and professionally from about 2001, and always hated how complicated and messy my code became any time I wanted to build rich functionality (i.e., a web-app rather than a website). That first changed for me when I discovered ExtJS (now Sencha) in 2007, then later Angular and finally React in 2017. These days I work almost daily on a React web-app I've built for displaying realtime weather/climate data for farmers, and it continues to be a very pleasing codebase to work with, more so than any I've worked on before.