111–120 of 292 posts
I've been doing front-end development off and on for 25 years and I still had a moment like this just this week. A different team updated a library we're supposed to use and all of a sudden, the deployed service was crashing on startup (worked locally). It appeared as though the problem was some EMCA6 syntax wasn't playing well with Babel configuration that seemed fine to me. I got so frustrated that I ended up remov…
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.
The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.
Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.
Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.
All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.
Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.
There is sooooo much you have to think about when writing a good React component with hooks and to ensure it remains performant and is bug free.
I really want to go back to basics. Using as little framework as possible.
I’d much rather something simple that I have full control over and that I can trace the entire execution with a debugger than all this magic crap.
I don’t even like JSX. I always pass an object in like: ‘’. Would much rather just use a literal js object.
I feel like React is a lot like dependency injection frameworks. The initialization code you would have to write without using one is actually very simple and straightforward.
Is it really that difficult to manually render components as needed? Do we actually need this huge runtime vdom overhead? Or any of these other compilers/transpilers.
I feel your pain. My career happiness peaked around 2014 or 2015, when I was writing Rails monoliths. I felt like I could focus 100% of my energy on business logic since the framework was so opinionated and the stack was simple. Things went rapidly downhill after that, once microservices, SPAs, node.js, NoSQL, and serverless computing started becoming popular. Everything just felt like a step backward. Microservices…
I still work on a Django monolith and agree on being able to focus 100% on business logic. I've found Angular is excellent for "sprinkling" a little JS into the frontend where necessary rather than going the full SPA/React route.
PHP. Use PHP, it’s so crazy easy for web development. - No compiling, - no middleware, - no state (which also means no memory leaks), - just drop a file on web server and it works (no crazy CI pipeline), - the documentation is fantastic, - it’s extremely fast, and - no surprises because it’s tried and true. PHP is so under appreciated.
Earlier quoted context omitted.
> Why does this happen? It happens because these technologies solve real problem for some subset of their users. Usually when people are saying that technology has become too complicated, it's because they happen to be looking from a perspective where the problems that the technology solves are invisible to them. That doesn't mean that the problem isn't important - it just means the problem isn't important for them .…
My sense is that is wrong. Case in point, I deal with a group that has a relatively elaborate set of excel workbooks to manage their process. None of the workbooks are great, all of them created and maintained by different teams, and there is persistent discussion of needing to accrue tools or some guy even threw together his own MS Access db to substitute for the workbooks. What they do is not at all beyond what Exc…
Honestly, I don't think it's even that bad for basic development (they literally have a CLI command that generates a very basic webapp immediately.)
I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…
In scientific/academic environments (the only type I can speak of) I have sometimes wondered if my fellow computerists have complexity envy. What we need to do is not that complicated but making it so distracts from understanding the harder problem at hand while appearing to be working furiously.
I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…
>Why does this happen? I wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some... Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are: (1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcas…
no such thing as frontend development. only full stack. and react for all the trillions of words written about it, what can you actually do with it? not much. also it's over-saturated as hell. you think there's high demand, you're right, now try applying for a position and see how it goes. there are two types of roles in modern web dev: 1 .90% of jobs are code monkey work: extremely saturated, you are competing with…
Old software sucked a lot, and automation sucked a lot. Weird issues where you HAD to know what went wrong, because handholding was looked down upon. The lack of automation meant that servers were pets, you looked after them, groomed them, maybe even sang a song to get the piece of junk going. Modern automation means you mostly care about the blueprint, not the actual instance. If it's not working properly, you reimage. If you need more, fire up more instances.
Also, what can you do on the frontend only? I have two examples from the top of my head: