4 ms·

You make a very interesting point. As a reasonably recent dev (three years ish), starting with Python (and Kivy), then Go, then HTML/CSS/JS, I can see some cons

You make a very interesting point. As a reasonably recent dev (three years ish), starting with Python (and Kivy), then Go, then HTML/CSS/JS, I can see some consistent patterns emerge. I've built a few apps with frontends by now and every, single, time, I could not tell you whether my frontend code is any good. In Python I sort of know when my code is good. It 'feels' good. It might not be clever or amazing, but I can get it to a point where it doesn't repeat loads, is reasonably easy to read even months later and behaves consistently and can be tested easily. In Go I feel this effect even more strongly. It feels quite wholesome to me. Frontend? ¯\_(ツ)_/¯ I just can't get to a point where I am satisfied with how it's setup. Yes, I can make it work, but it never stops feeling messy. I don't want to use a billion libraries or frameworks either. I like to do my own thing (having tried some frameworks, I felt I was mostly working against the framework). Javascript-anything always feels yanky. No matter how much I optimise it to death using webworkers, try every CSS trick in the book to load things as quickly as possible. On my 4.5Ghz 4790k with 32GB of ram, everything I do always hitches, stutters, jitters and doesn't feel smooth. This is true for the web (and that's after adblocking). Like, how is that the state of things? Browsing the internet on a weak work-machine without adblockers is literally unbearable. I simply don't do it. So I don't know what this predicament is we find ourselves in nowadays, or whether I need to spend more time with frontend work, but overall it feels far messier, far more difficult to get right than the backend stuff I have built. Anyone have any pointers as to how one deals with FE work? Even simple sites quickly turn into a mess of thousands of DOM elements and every time I try to write non-repeating code, I notice one more setting or attribute I need to switch particularly, so then I am adding yet another conditional to a function or writing another function, which basically does the same thing, but not really... Wish I could go backend-only, lol...

jasim 7y ago
Front-end often has longer data transformation pipelines than back-end, and that leads to the complexity you mention. If you treat it as a programming problem, you can write better front-end code by shoring up on your ability to compose, glue, and modularize code. You also need a way to represent front-ends as a data structure rather than a sequence of imperative actions. Data is easier to think about - imagine if instead of HTML you had to write imperative code to paint everything on the screen - that kind of code can get tangled up easily and make it difficult to understand or modularize the code. In this vein, using a library that lets you think of the front-end as data ('declarative') rather than imperative DOM mutation (with jQuery etc.) is an important thinking tool. A way to short-circuit the amount of learning associated with this is to pick-up tools that have already reified this knowledge, so that by learning the tool you pick up the many mental models they embody. I suggest either Reason (with ReasonReact) or Elm as great starting point. Pursue their homepages, toss a coin, pick the one that appeals to you on first blush. Both these languages are typed functional languages. Types here are tools of thought - especially the ability to represent data as One of Many (sum types) - will forever add a dimension to the way you model data. Functional programming is a toolkit of methods that let you compose and glue code together, and while it wouldn't appear that they attack the problems you're facing head on (should I add yet another conditional here, or should I extract another function that looks almost the same vs DRY etc.), those are exactly the problems you'll be able to confidently answer after you've practiced in this paradigm for a while.
jrumbut 7y ago
Front end work is just messy, solutions that optimize everything at the same time are rare/non-existent. When I've run into hitches, stutters, etc, it was when I was doing too much of the rendering myself in Javascript, micromanaging the HTML and CSS. A little load time is better than any amount of jittering or hitching, which give me a headache very fast. When you make the Javascript do less of the browser's job, work with CSS rather than against it, your code even drifts a little bit toward elegance. The other thing that has caused it, on reflection, is just too many elements (hundred of thousands or millions) particularly in complex SVG visualizations. If this is your issue, the solutions might include summary statistics, fancy graphics algorithms, or just changing the design.

jasim 7y ago

Front-end often has longer data transformation pipelines than back-end, and that leads to the complexity you mention. If you treat it as a programming problem, you can write better front-end code by shoring up on your ability to compose, glue, and modularize code. You also need a way to represent front-ends as a data structure rather than a sequence of imperative actions. Data is easier to think about - imagine if instead of HTML you had to write imperative code to paint everything on the screen - that kind of code can get tangled up easily and make it difficult to understand or modularize the code. In this vein, using a library that lets you think of the front-end as data ('declarative') rather than imperative DOM mutation (with jQuery etc.) is an important thinking tool. A way to short-circuit the amount of learning associated with this is to pick-up tools that have already reified this knowledge, so that by learning the tool you pick up the many mental models they embody. I suggest either Reason (with ReasonReact) or Elm as great starting point. Pursue their homepages, toss a coin, pick the one that appeals to you on first blush. Both these languages are typed functional languages. Types here are tools of thought - especially the ability to represent data as One of Many (sum types) - will forever add a dimension to the way you model data. Functional programming is a toolkit of methods that let you compose and glue code together, and while it wouldn't appear that they attack the problems you're facing head on (should I add yet another conditional here, or should I extract another function that looks almost the same vs DRY etc.), those are exactly the problems you'll be able to confidently answer after you've practiced in this paradigm for a while.

jrumbut 7y ago

Front end work is just messy, solutions that optimize everything at the same time are rare/non-existent. When I've run into hitches, stutters, etc, it was when I was doing too much of the rendering myself in Javascript, micromanaging the HTML and CSS. A little load time is better than any amount of jittering or hitching, which give me a headache very fast. When you make the Javascript do less of the browser's job, work with CSS rather than against it, your code even drifts a little bit toward elegance. The other thing that has caused it, on reflection, is just too many elements (hundred of thousands or millions) particularly in complex SVG visualizations. If this is your issue, the solutions might include summary statistics, fancy graphics algorithms, or just changing the design.