I Am Happy Not to Be a Web Developer Anymore(thecodist.com)
thecodist.com
I Am Happy Not to Be a Web Developer Anymore
https://thecodist.com/i-am-happy-not-to-be-a-web-developer-anymore/
72 comments
The problem in the past was primary browser incompatibility. That was why jQuery exists and was so successfull.
Different render output with different css settings was an other problem. But, thank god, since IE dies, this problems are solved for 99% of all use cases.
I got into a web development a few years ago, and I am so... what would should I use? Almost euphoric that I never had to learn to work around IE6 or Internet Explorer in general; that web browsers mostly support the same feature set now (shame on Safari for still not supporting Ogg, and on Edge for not supporting AVIF), and ECMAScript 6 being widely available is a blessing.
In 2006, tech decisions were easy: shall I use jQuery or Prototype.js? PHP or ASP? Postgres or MySQL?
Nowadays, after the long decision process to go serverless I choose Cloudflare from the 13 best serverless frameworks and VueJS from the 30 frameworks they support.
So I choose SPA from the four ways to deploy VueJS. I chose TS over JS. SFCs thank you very much. Setup syntax please! Composition over options all the way.
I'm in the promised land! Types! Components! No server admin! No DB admin! Let's actually make something!
Trouble is, 18 months down the line, the commercial charts library I wanted to use is pretty much unusable with this setup. I've been through about eight dropdown menu libraries. How many person-hours were wasted with abandoned vuejs dropdown menus I wonder!?
It's been easier to write a desktop application to do the same thing in about two months.
Nowadays, after the long decision process to go serverless I choose Cloudflare from the 13 best serverless frameworks and VueJS from the 30 frameworks they support.
So I choose SPA from the four ways to deploy VueJS. I chose TS over JS. SFCs thank you very much. Setup syntax please! Composition over options all the way.
I'm in the promised land! Types! Components! No server admin! No DB admin! Let's actually make something!
Trouble is, 18 months down the line, the commercial charts library I wanted to use is pretty much unusable with this setup. I've been through about eight dropdown menu libraries. How many person-hours were wasted with abandoned vuejs dropdown menus I wonder!?
It's been easier to write a desktop application to do the same thing in about two months.
Right? Web development is orders of magnitude easier today than it was 20 years ago. We've standardized the web apis, we've standardized identity management and how to federate that management, we've standardized site interoperability, we've standardized site security - really, about the only choice you have now is which major framework do you want to use? And none of the above is still a choice.
Things are much, much easier today and work better for our customers. A true win-win.
Things are much, much easier today and work better for our customers. A true win-win.
I could almost agree, but for at least one aspect: 90% or more of today's SPA web apps are just glorified information pages, that do not need any React, Vue, Angular or Svelte. That is where the hype train shows. They could just as well be way simpler in design, and avoid having to reimplement (through a dependency or not) the back button. Many cases for actually multi page apps, that are needlessly implemented as SPA with additional router BS and tons of dependencies and a heavy framework, rather than simply going for server side rendered template and being done with it. This comes mostly pushed by frontend developers, who want their shiny framework of choice to be relevant everywhere. A job guarantee.
Your argument is sound but it does not support your conclusion; react native is an example of “changing the base”. It is missing a significant chunk of HTML and CSS as an implementation detail. It is not an improvement, and I treat it as evidence that approach will not yield an improvement.
The whole thread is about web development though, React Native is not web development. It's app development in React/JS, there are similarities but it's definitely not web development
> There's really only 4 framerworks (React, Vue, Angular & Svelte, in this order), they pretty much do the same thing
For me it looks there are only 4 frameworks in that category. htmx in my eyes feels like a welcomed step back from those. Closer to what we used to do before (server-side html generation and such), but with a small twist. I have not really used it, but React etc. never felt good fit for me, personally.
For me it looks there are only 4 frameworks in that category. htmx in my eyes feels like a welcomed step back from those. Closer to what we used to do before (server-side html generation and such), but with a small twist. I have not really used it, but React etc. never felt good fit for me, personally.
[deleted]
I'll be the contrarian. I'm in my mid 40s and have been designing / developing for the web now for 25 years professionally. I built my personal site in Astro, Svelte and Xata because they were all new technologies and I enjoy learning new things. The fact that things change so much is actually a reason I've remained so excited about my work for so long. I love the learning part of things so much, that when I'd grown into being a corporate executive I generally missed that daily churn of learning and eventually gave it all up so that I could take an IC job to code again.
Is this good for business? Probably not. Is it fun for me? Absolutely. Sometimes the road calls to you more than the destination. We're all wired a little different.
Side note. I love the author's art and couldn't find a place to purchase it.
Is this good for business? Probably not. Is it fun for me? Absolutely. Sometimes the road calls to you more than the destination. We're all wired a little different.
Side note. I love the author's art and couldn't find a place to purchase it.
I’m kinda in the same boat but lately (last few years) have been frustrated as I’ve ventured outside of web tech in seeking new things and found so many nice things in other platforms that its just sad to see “progress” trying to catch up innovation that has happened elsewhere.
I’ve tried closure, elixir and a bit of haskell and all have so many great lessons that are yet to be learned elsewhere.
After developing professionally in PHP, ruby, python and javascript and trying out other languages and frameworks at some point one can see so many great ideas that you can’t really use because the language doesn’t allow it. Like how much more would we have to wait for a normal low level lib for javascript/node, or even things like the pipe operator.
Various frameworks and libraries allow you a glimpse of whats possible, but then when one reads ip on the inspiration behind them and tries them out in their “native” environment, it just kinda sad how much can be lost “in translation”.
I’ve tried closure, elixir and a bit of haskell and all have so many great lessons that are yet to be learned elsewhere.
After developing professionally in PHP, ruby, python and javascript and trying out other languages and frameworks at some point one can see so many great ideas that you can’t really use because the language doesn’t allow it. Like how much more would we have to wait for a normal low level lib for javascript/node, or even things like the pipe operator.
Various frameworks and libraries allow you a glimpse of whats possible, but then when one reads ip on the inspiration behind them and tries them out in their “native” environment, it just kinda sad how much can be lost “in translation”.
Speaking for myself personally, I think this is where standards have helped. Yes, new ideas spring about from frameworks and languages, but typically I see the standards cementing the good parts beyond them.
5-15 years ago I couldn't write native CSS. Today? I prefer it. It's improved to such a degree that I think most people aren't even aware of how much better it's gotten, because they escaped to Sass / CSS-in-JS for years.
5-15 years ago I couldn't write native CSS. Today? I prefer it. It's improved to such a degree that I think most people aren't even aware of how much better it's gotten, because they escaped to Sass / CSS-in-JS for years.
I agree. I started web development in 1997, started working professionally as a web developer in 2000, and just this past summer moved away from being a full-stack web developer to a different individual contributor programming role. Frankly I was happy to move away. Web development used to be fun, it isn't fun anymore. I'll keep an eye on the field and, if it ever moves back to a more sane development environment, I'll consider jumping back in.
I think the article sidesteps the underlying issue with programming for a company.
Programming is way closer to cleaning bathrooms or working the checkout line at the grocery store than most programmers are willing to admit. It's an endless slog to solve the same problems for the same companies over and over.
Your code really has no value without a business solution. A website or an app or some code is just an implementation detail, and it has no value by itself. It can lose value in an instant if something else comes around or the underlying problem that it set out to solve disappears.
There's nothing wrong with web development today. It's a tool for a job and it does its job.
I think a lot of developers have tunnel vision on what they actually do for a living. I don't really think it's the greatest gig. I think a lot of other corporate roles are more lucrative and easier. For example, fart out some business word salad for your MBA classes, get your degree (this is way easier than an engineering undergrad), and convince someone to hire you in a strategic business role.
You can't even really screw it up at a lot of companies, there's no need to be competent, the programmers and other grunt workers do all the actual work.
Programming is way closer to cleaning bathrooms or working the checkout line at the grocery store than most programmers are willing to admit. It's an endless slog to solve the same problems for the same companies over and over.
Your code really has no value without a business solution. A website or an app or some code is just an implementation detail, and it has no value by itself. It can lose value in an instant if something else comes around or the underlying problem that it set out to solve disappears.
There's nothing wrong with web development today. It's a tool for a job and it does its job.
I think a lot of developers have tunnel vision on what they actually do for a living. I don't really think it's the greatest gig. I think a lot of other corporate roles are more lucrative and easier. For example, fart out some business word salad for your MBA classes, get your degree (this is way easier than an engineering undergrad), and convince someone to hire you in a strategic business role.
You can't even really screw it up at a lot of companies, there's no need to be competent, the programmers and other grunt workers do all the actual work.
For a long time I've felt like software is really just a blue collar job, but instead of turning a wrench it's pushing little plastic buttons.
I like this aspect of it. It feels humble and practical. We're plumbers, but we pipe data not fluid. We don't have any science of data dynamics yet, so it's all word of mouth cargo culting. It's like being a plumber in the bronze age if plumbing was extremely valuable.
As to the ease of "and convince someone to hire you in a strategic business role". Yes, this is a job that people have, however it's extremely competitive and hard to keep. There's always someone else who can spit out MBA salad and who wants your job. I wouldn't want to be a BS artist, it's too stressful.
I like this aspect of it. It feels humble and practical. We're plumbers, but we pipe data not fluid. We don't have any science of data dynamics yet, so it's all word of mouth cargo culting. It's like being a plumber in the bronze age if plumbing was extremely valuable.
As to the ease of "and convince someone to hire you in a strategic business role". Yes, this is a job that people have, however it's extremely competitive and hard to keep. There's always someone else who can spit out MBA salad and who wants your job. I wouldn't want to be a BS artist, it's too stressful.
I think you have a point. The thing is, I'm weirdly OK with labouring away at the coalface. It's hard work, it's more toil and drudgery than people admit, but I'd rather that than finding the white collar 'cheat codes' that allow me to skive off.
It helps to work on a product that you're into, or believe in, if you're lucky enough to find such a thing. I think one of the secrets is to become a product-centric engineer, and focus more energy on understanding the domain and what the business needs.
It helps to work on a product that you're into, or believe in, if you're lucky enough to find such a thing. I think one of the secrets is to become a product-centric engineer, and focus more energy on understanding the domain and what the business needs.
I get the point the writer is making: web development is a mess. However, I also think that stepping off that treadmill can make one's impression of the field a bit skewed, because there is no longer an incentive of the writer to keep up with the nuances of the changes. Web frameworks do come and go, but they're also not that different from each other. New ones show up, but that doesn't mean that everyone flocks to them and disrupts everything.
The whole process is definitely still a mess and I am not trying to defend the chaos, but I think it probably appears a lot worse from the outside.
The whole process is definitely still a mess and I am not trying to defend the chaos, but I think it probably appears a lot worse from the outside.
I don't know man, I've seen frameworks rise, gain massive adoption and then be abandoned as everyone moves to the next hot thing.
I watched everyone adopt AngularJS and then have to migrated to Angular 2.0 and then everyone migrated to React. During this time, the backend folks wrote java services using SpringBoot and then migrated to SpringBoot and then when that wasn't abandoned, moved to SpringBoot.
Web development feels way too much like a hamster wheel to me.
I watched everyone adopt AngularJS and then have to migrated to Angular 2.0 and then everyone migrated to React. During this time, the backend folks wrote java services using SpringBoot and then migrated to SpringBoot and then when that wasn't abandoned, moved to SpringBoot.
Web development feels way too much like a hamster wheel to me.
I'll just pile on my anecdote because I am a backend dev but want to make websites since apparently end users don't like reading and hand-composing JSON or something.
A while ago, a few years I think, I learned react with class components. Hooks were never mentioned, so I don't know if they didn't exist yet or were in some nascent stage. I thought "huh neat this makes writing js not completely awful" - my only "frontend"-related background was in desktop UI development with Swing and Qt and such. As I mentioned, I'm mostly a backend dev.
Anyway, I wrote a small internal app for my job at the time and shipped it and it was neat, all the other backend devs (we had ~no frontend devs) were suitably impressed with how much less awful react was than vanilla JS.
Fast forward... I suspect 3-ish years. Suddenly hooks were popular and class components were not and people were being pushed to migrate (since newer versions of libraries were preferring hooks). My hard-won frontend knowledge is already outdated! And imagine my surprise when I learned SSR was back?? and something about next.js which I guess is still react but it's a server packaging of it as well and that bleeds over into letting you do more stuff on the frontend, something about server-side props? I was disappointed with how much had changed despite the actual product - the websites you can build - still essentially staying the same.
And this is just for React - the winner! I had managed to correctly pick the winner and there's still all this churn. Meanwhile, as you mentioned, rails is still almost exactly the same (all its churn has been trying to pick a not-awful way to integrate javascript, ironically) despite several major versions passing, Spring is the same, etc.
A while ago, a few years I think, I learned react with class components. Hooks were never mentioned, so I don't know if they didn't exist yet or were in some nascent stage. I thought "huh neat this makes writing js not completely awful" - my only "frontend"-related background was in desktop UI development with Swing and Qt and such. As I mentioned, I'm mostly a backend dev.
Anyway, I wrote a small internal app for my job at the time and shipped it and it was neat, all the other backend devs (we had ~no frontend devs) were suitably impressed with how much less awful react was than vanilla JS.
Fast forward... I suspect 3-ish years. Suddenly hooks were popular and class components were not and people were being pushed to migrate (since newer versions of libraries were preferring hooks). My hard-won frontend knowledge is already outdated! And imagine my surprise when I learned SSR was back?? and something about next.js which I guess is still react but it's a server packaging of it as well and that bleeds over into letting you do more stuff on the frontend, something about server-side props? I was disappointed with how much had changed despite the actual product - the websites you can build - still essentially staying the same.
And this is just for React - the winner! I had managed to correctly pick the winner and there's still all this churn. Meanwhile, as you mentioned, rails is still almost exactly the same (all its churn has been trying to pick a not-awful way to integrate javascript, ironically) despite several major versions passing, Spring is the same, etc.
I completely agree with what you've said.
All I want to add is that today React is the winner, last week, backbone/ember was, week before that it was angular.
Even winners are transient and ephemeral.
All I want to add is that today React is the winner, last week, backbone/ember was, week before that it was angular.
Even winners are transient and ephemeral.
It doesn't help that a lot of websites / apps have this tendency to "need" a redesign / rebranding every 5-10 years, which developers take as an opportunity to use the next great framework because the old app is an unmaintainable mess.
If anything, new frameworks should be simple to use.
I've had the misfortune to work in an Angular codebase last year, I could hardly make heads or tails from it; I'm sure there's good theory behind it, but it was far too complicated.
Currently working in React, and it's got the annoyances of hooks, callbacks, effects, etc; basically, you as a developer are responsible for a lot of rendering behaviour, using what looks like magic trickery. Don't get me wrong, I like the basics of React, but as soon as it goes beyond simple props it's starting to lose me. I heard Vue solved this better or more intuitively, but it's still a layer on top of JS/HTML.
In parallel I've been working in Go, and while it's wordy and frequently annoying (like when using the correct design patterns, you'll end up copying a database struct to a business logic struct to a HTTP API struct, it's boring, wordy and bug prone code), it's still much more of a joy to work in because there's very little indirection or friction.
If anything, new frameworks should be simple to use.
I've had the misfortune to work in an Angular codebase last year, I could hardly make heads or tails from it; I'm sure there's good theory behind it, but it was far too complicated.
Currently working in React, and it's got the annoyances of hooks, callbacks, effects, etc; basically, you as a developer are responsible for a lot of rendering behaviour, using what looks like magic trickery. Don't get me wrong, I like the basics of React, but as soon as it goes beyond simple props it's starting to lose me. I heard Vue solved this better or more intuitively, but it's still a layer on top of JS/HTML.
In parallel I've been working in Go, and while it's wordy and frequently annoying (like when using the correct design patterns, you'll end up copying a database struct to a business logic struct to a HTTP API struct, it's boring, wordy and bug prone code), it's still much more of a joy to work in because there's very little indirection or friction.
Meanwhile Ember has quietly improved and reinvented itself steadily over the last decade-plus, while maintaining compatibility responsibly the entire time. Sure it’s not always been on the cutting-edge (which I guess is why it lost its cachet) but its relative stability through fundamental reworking of its core have enabled me to happily maintain multiple SPAs that I started with as far back as 2015 when everyone was adopting AngularJS.
All this is to say that there are projects and communities that value stability with stagnating so you can still have “nice things” without feeling stuck on a hamster wheel.
All this is to say that there are projects and communities that value stability with stagnating so you can still have “nice things” without feeling stuck on a hamster wheel.
Most ironically, Ember's mascot is in fact a Hamster (well, a Tomster). :-)
I started around 2009, and while I certainly felt overwhelmed at several points during the framework craze, I never got tired of it because it was exciting. As soon as I started hearing about hydration though, that was my breaking point. I'm just tired of it all.
That being said, I do love Astro. It's a very nice, easy experience.
That being said, I do love Astro. It's a very nice, easy experience.
And now from client side rendering (CSR) back to server side rendering (SSR). The thing, that we done 20 years ago, but now only more complicated, with more tools, more setups, etc.
I feel like I stepped off frontend the treadmill and haven’t been able to catch up with frontend. React, Angular, Vue, Next, Nuxt, Svelte, Typsecript, Tailwind, Bundlers.
It feels like a mountain to climb to get my head around that lot!
It feels like a mountain to climb to get my head around that lot!
I don’t really understand why people seem to decouple learning from doing. Isn’t it possible to only learn what you need when you need it? It’s not like you even have to learn an entire framework/etc each time you run into a new one, just learn the specific part you need at that time. What am I missing?
This mentality is what leads to paint drip shaped people. It's a very good practice in my experience. Go just as deep as you need to solve the problem.
https://flowchainsensei.wordpress.com/2021/07/28/kent-becks-...
https://flowchainsensei.wordpress.com/2021/07/28/kent-becks-...
But until you don't know something, you can't use it and, most importantly, you can't understand that you need it.
Like, how can you understand the tradeoffs between react, svelte or vanilla js until you have a basic knowledge of them?
Like, how can you understand the tradeoffs between react, svelte or vanilla js until you have a basic knowledge of them?
If you're a front-end developer, it shouldn't take long to research the differences between modern front end frameworks. If you don't have any existing front-end skills, you won't have the ability to know what to dive into. True beginners need a solid foundation to build on, but once you have that foundation you should be able to adapt it to new and changing technology very easily. Once you have the foundation, you can dive as deep as you need into specific specialties and jump back out quite easily.
Learning your first programming language is hard. There's a lot of details and idiosyncrasies. The second is a bit easier because you have a base of experience to reference it against. By the time you're picking up your sixth language or front end framework or node API framework, you should be able to much more quickly assimilate the details because you've got so much more experience to draw on.
Learning your first programming language is hard. There's a lot of details and idiosyncrasies. The second is a bit easier because you have a base of experience to reference it against. By the time you're picking up your sixth language or front end framework or node API framework, you should be able to much more quickly assimilate the details because you've got so much more experience to draw on.
Most of those are just rehashing of already discovered ideas. It is not like they have much of a secret sauce. Just put some concepts together. If you are a good developer, you can understand what they do in no time. But that makes it even more annoying to see the hype around something that is nothing special. Add to that a mountain of silly configurations and limitations due to design decisions, and you get a "modern" web stack. Take for example "tree shaking". I remember how there was a hype around it. Every second day I would see some post about tree shaking or read some blog or whatever, where people point out tree shaking. Tree shaking! Tree shaking here! tree shaking there! Most of them never stopped and thought about how they shouldn't need to be shaking, but instead should avoid putting that much shakable shit into their trees in the first place.
It almost seems like people are getting off on the fact, that they manage configuration complexity in web projects, as if that makes them somehow qualified. Instead they should be saying:
Wait a minute, why am I configuring all this shit? Why is my web app so big, that using a minifier makes any significant difference? Does my web app really do that much? Couldn't I get by with just rendering templates and add a tiny amount of JS?
But people do not ask and continue riding the hype train and it even makes them more in demand, because way too many people think they need this.
It almost seems like people are getting off on the fact, that they manage configuration complexity in web projects, as if that makes them somehow qualified. Instead they should be saying:
Wait a minute, why am I configuring all this shit? Why is my web app so big, that using a minifier makes any significant difference? Does my web app really do that much? Couldn't I get by with just rendering templates and add a tiny amount of JS?
But people do not ask and continue riding the hype train and it even makes them more in demand, because way too many people think they need this.
html used to be a markup language for describing documents.
now html is the gibberish output from some js build pipeline for wrapping 50 nested divs around some json values.
why i hate web dev now:
1. what used to to take 1-3 steps now takes 10-20. trade-offs are absolutely not worth it for 90% of cases.
2. web dev has become low value, highly saturated and competitive field thanks to learn2code and low barrier.
now html is the gibberish output from some js build pipeline for wrapping 50 nested divs around some json values.
why i hate web dev now:
1. what used to to take 1-3 steps now takes 10-20. trade-offs are absolutely not worth it for 90% of cases.
2. web dev has become low value, highly saturated and competitive field thanks to learn2code and low barrier.
web dev has become low value, highly saturated
Web dev has been the low value, low barrier, entry level programming job for decades. I got my first web dev job in the mid 90s and it was low value, entry level work even then, that is why they would hire a 17 year old with no experience.
Yes there is Web dev work that is very advanced, and web devs doing stuff way beyond what most can do, but most web dev jobs in the world have never been that.
Web dev has been the low value, low barrier, entry level programming job for decades. I got my first web dev job in the mid 90s and it was low value, entry level work even then, that is why they would hire a 17 year old with no experience.
Yes there is Web dev work that is very advanced, and web devs doing stuff way beyond what most can do, but most web dev jobs in the world have never been that.
Developers confuse technical stack (the how) with the why (what business value is my solution delivering).
There are just more choices today. You don't query for the latest stack and work back words.
Are you building a dog house or a skyscraper? If its a dog house use vanilla js or whatever works. If your building a skyscraper then use a react stack or something that has wide developer support since now your working on a large team on a large web application and the requirements have changed.
Server side rendering for example is to solve the issue of first load but is that actually something the business must have? It also adds CPU processing to your back end and more complexity. Is the trade off worth it for your business?
The reason the business pays us money is so we learn the trade offs and make the correct technical decisions, not that we blindly grab the new hot.
Most hacker news links I see like this is a developer confusing their world (small shop, internal IT dev, large shop, enterprise development, contract work for medium size business, FANG company etc) with the whole world and think there is one solution that applies to all worlds.
There are just more choices today. You don't query for the latest stack and work back words.
Are you building a dog house or a skyscraper? If its a dog house use vanilla js or whatever works. If your building a skyscraper then use a react stack or something that has wide developer support since now your working on a large team on a large web application and the requirements have changed.
Server side rendering for example is to solve the issue of first load but is that actually something the business must have? It also adds CPU processing to your back end and more complexity. Is the trade off worth it for your business?
The reason the business pays us money is so we learn the trade offs and make the correct technical decisions, not that we blindly grab the new hot.
Most hacker news links I see like this is a developer confusing their world (small shop, internal IT dev, large shop, enterprise development, contract work for medium size business, FANG company etc) with the whole world and think there is one solution that applies to all worlds.
I don’t blame the tooling, there’s nothing stopping you from creating an old school PHP website.
I blame the audience. These JS frameworks and cloud-everything services exist to shave every possible millisecond off from the experience because we all have the attention spans of a goldfish now.
I blame the audience. These JS frameworks and cloud-everything services exist to shave every possible millisecond off from the experience because we all have the attention spans of a goldfish now.
I made my personal website mostly static (just some Apache server-side includes) with no js. It’s astounding how much faster it is than any other website I use. If you really want to get the goldfish audience, eschew the scripting.
According to the lore a goldfish has an attention span of about 3 seconds, are you sure humans nowadays have one *that long* ?
Starting a fresh new (internal) project in our company, no specs, no borders, we can use any JS lib, framework, tool, whatever.
Now we stay like a kid in front of a candy shop and don't know what to choose.
Anything has pros and cons, but nothing really convinces us. It seems that all candies look great but taste like spoiled fish.
We are a small team and we don't have the time to update the app with every new version of a framework.
We stepped back and looked at our internal tools, which needed the least time of work for updates etc. and we currently think we use no framework. Only a really really simple one. That would possible need more time to build an app, but saves a lot to maintain the app. This tool would be used for the next 10 years (ok 20 years in reality).
Our oldest internal tool is 22 years old (manages customers, projects, domains, servers, etc.), got a little update some months ago to work with newest browser, update to newer php-version and that all within only 2 weeks. 2 weeks! That is today not enough time for a modern build setup ;-)
10 years ago, non of the current JS frameworks exists, or you have to do so much upgrade work to maintain you apps. 20 years ago? OMG unbelievable. Now think 10 or 20 years in the future. I think none of the current frameworks will then exists.
Now we stay like a kid in front of a candy shop and don't know what to choose.
Anything has pros and cons, but nothing really convinces us. It seems that all candies look great but taste like spoiled fish.
We are a small team and we don't have the time to update the app with every new version of a framework.
We stepped back and looked at our internal tools, which needed the least time of work for updates etc. and we currently think we use no framework. Only a really really simple one. That would possible need more time to build an app, but saves a lot to maintain the app. This tool would be used for the next 10 years (ok 20 years in reality).
Our oldest internal tool is 22 years old (manages customers, projects, domains, servers, etc.), got a little update some months ago to work with newest browser, update to newer php-version and that all within only 2 weeks. 2 weeks! That is today not enough time for a modern build setup ;-)
10 years ago, non of the current JS frameworks exists, or you have to do so much upgrade work to maintain you apps. 20 years ago? OMG unbelievable. Now think 10 or 20 years in the future. I think none of the current frameworks will then exists.
The dilemma of choosing the right tool for a long-term project is understandable. We are running an open source React framework called refine for building Enterprise B2B apps like admin panels, internal tools and dashboard.
It's designed to be ensuring that projects remain maintainable even as time goes by. With its headless architecture, it can be used with custom styles or any UI library and data services. Maybe it helps you somehow
You can check the examples with source code: https://refine.dev/docs/examples/
Repository: https://github.com/refinedev/refine
It's designed to be ensuring that projects remain maintainable even as time goes by. With its headless architecture, it can be used with custom styles or any UI library and data services. Maybe it helps you somehow
You can check the examples with source code: https://refine.dev/docs/examples/
Repository: https://github.com/refinedev/refine
Thanks, will have a look at it.
10 years ago I was creating apps with Ember.js, which is still a current JS framework.
And how many times you have to update your app? How many time you need for maintain?
I’ve been maintaining Ember apps since 2015 and there’ve been 4 new major versions I’ve worked through, but the project’s deprecation policy and migration tooling have enabled incremental migration over time so there’s never been a need to hard fork / rewrite the app in a way that has occurred with several other (once-)popular web frameworks.
Yes, the update politics of ember is a good example for all. But it comes normally with a cost (features, speed, better solutions, whatever.... don't know currently enough about ember to form a judgment there).
I used ember too for a little own project, when it was version 1 (ONE), but i can't remember today why i not used it anymore.
I used ember too for a little own project, when it was version 1 (ONE), but i can't remember today why i not used it anymore.
Respectfully Ember is not current at all. Might as well call BackboneJS or Marionette current as well.
Ember still has significant updates, it's still innovating alongside the best of them, it still has annual conferences, and the productivity a team gets by choosing Ember is still right alongside most popular frameworks for creating and maintain ambitious web applications. The same cannot be said for Backbone or Marionette.
If this POV resonates with you I encourage you to follow the work of progrium (Jeff Lindsay) who is actually trying to do something about it at pretty fundamental levels.
Wanix - https://www.youtube.com/watch?v=qGFdtDKLI9o
Tech Thesis - https://www.youtube.com/watch?v=yKZ15O7zeHY
Wanix - https://www.youtube.com/watch?v=qGFdtDKLI9o
Tech Thesis - https://www.youtube.com/watch?v=yKZ15O7zeHY
What industry hasn’t changed tremendously since 2000? Look at Vulkan vs OpenGL 2. Or C++23 vs C++03. Or C# today vs C# in 2000. Or even Java today vs Java then. Or CPUs of today vs CPUs of 2000. Those gosh darned hardware engineers keep making this stuff overly complex!
I find it funny when people from other domains complain about web development changing so quickly, when literally every other domain changes at about the same pace. React has been around since 2013 now, that’s the same age as Rust. Of course if you’re not in the industry and actively following it, it will feel foreign to you if you revisit it in 10 years. That doesn’t mean your industry hasn’t changed, it just means you haven’t noticed it because you’ve been following it all this time.
And you can still use plain JS, HTML, and CSS. And a lot of things have gotten way better using vanilla tools. You don’t have to use a super complicated stack if you don’t want to.
I find it funny when people from other domains complain about web development changing so quickly, when literally every other domain changes at about the same pace. React has been around since 2013 now, that’s the same age as Rust. Of course if you’re not in the industry and actively following it, it will feel foreign to you if you revisit it in 10 years. That doesn’t mean your industry hasn’t changed, it just means you haven’t noticed it because you’ve been following it all this time.
And you can still use plain JS, HTML, and CSS. And a lot of things have gotten way better using vanilla tools. You don’t have to use a super complicated stack if you don’t want to.
In many cases it is better not to use super complicated stack. It depends on the kind of project, how many people work with it, how it should be maintained, ...
But the problem is, that most people automatically think to use a framework (me also).
But the problem is, that most people automatically think to use a framework (me also).
I too remember when all my projects were greenfield, before my first burnout, when a less jaded me with better knees enjoyed the simpler times.
Just adding an option that worked for me: clojure, with its philosophy of making things simple [0] (as opposed to easy, as in "easy to get started but turns into a mess"). There are some exciting new developments out there (see rama [1] and electric clojure [2]), but the composability of the language makes these feel like additive ideas rather than "throw everything out and start from scratch".
[0] https://www.infoq.com/presentations/Simple-Made-Easy/ [1] https://news.ycombinator.com/item?id=37137110 [2] https://news.ycombinator.com/item?id=34771771
[0] https://www.infoq.com/presentations/Simple-Made-Easy/ [1] https://news.ycombinator.com/item?id=37137110 [2] https://news.ycombinator.com/item?id=34771771
I hate my web dev job. I'm hoping to transfer back to an API team. I'll probably suck there too though.
The web development might not be perfect, and yes it’s evolving very fast, but it is not worse than it used to be.
I’m a bit disappointed in the article. With the title I expected to read something about development that is not web (system, embedded…), and it made me curious. Sadly it isn’t; the author is criticizing an ecosystem they left a while ago, and regret not to be able to keep up with it. Pretty normal, isn’t it?
It’s very easy not to be able to keep up with something you’re not a part of anymore. We shouldn’t expect things to stay the same forever. It’s okay to take a step back and reflect on how things are (yes, maybe web dev becomes too complicated in certain ways), but it’s hard to judge when you’re completely out of it (the author stopped web development “in 2009”).
I’m a bit disappointed in the article. With the title I expected to read something about development that is not web (system, embedded…), and it made me curious. Sadly it isn’t; the author is criticizing an ecosystem they left a while ago, and regret not to be able to keep up with it. Pretty normal, isn’t it?
It’s very easy not to be able to keep up with something you’re not a part of anymore. We shouldn’t expect things to stay the same forever. It’s okay to take a step back and reflect on how things are (yes, maybe web dev becomes too complicated in certain ways), but it’s hard to judge when you’re completely out of it (the author stopped web development “in 2009”).
> Programming when I started in the early 80s was much more straightforward, as you needed to know the programming language, the operating system, and what you were asked to build — everything else you had to invent for yourself!
Is that much more straightforward? If I have an idea today, I can mostly just skip straight to the parts of that idea that interest me. I don't have to worry about writing my own database driver or windowing system or whatever — projects that could be fun in their own rights, but ultimately soul-sucking if they're just obstacles in the way of my actual vision.
Is that much more straightforward? If I have an idea today, I can mostly just skip straight to the parts of that idea that interest me. I don't have to worry about writing my own database driver or windowing system or whatever — projects that could be fun in their own rights, but ultimately soul-sucking if they're just obstacles in the way of my actual vision.
It has to be said, web dev got better when the Redmond Middle School science projects (Microsoft Internet Explorer and old Edge) went into the dustbin of history where they have long belonged.
I've been doing web development for the past 15 years or so, with the odd sidestep to mobile, currently React Native, but ten years ago I did some native iOS. I had the opportunity to do native iOS again recently, just a POC to add widgets to our app. On the one side, it was great, the tooling is great, super previews, etc. On the other, it's a lot of fidgeting to get it to work, but then, I hadn't had the opportunity to work with SwiftUI yet.
I certainly agree that current front-end stacks are a house of cards.
On the other hand, though, not many developers get to focus mostly on new code. And generally, open source dependencies are going to be used, as it's considered wasteful to build everything from scratch.
On the other hand, though, not many developers get to focus mostly on new code. And generally, open source dependencies are going to be used, as it's considered wasteful to build everything from scratch.
What is a saner specialty then? I’m getting tired of web dev because I’m getting too old to keep running on the treadmill.
But what’s a better specialty (more stable, doesn’t change every week, large number of opportunities)? iOS or Android development? Something else?
But what’s a better specialty (more stable, doesn’t change every week, large number of opportunities)? iOS or Android development? Something else?
A Web page requires a browser to show it. A Web application requires a Web OS to run it. We have no the Web OS at this point of time.
Don´t worry too much guys, we have "The Renaissance", one man framework, SSI, things are coming back.
We can be Webmasters again!
We can be Webmasters again!
Nothing's actually forcing you to do all these new trends. In fact, i'm currently working on a project and I'm using smalltalk/seaside and prototypejs for it
Knew Smalltalk would make its way into this. Saying as someone who loves it.
Is the issue really that old is now new, or is it that abstraction actually becomes a liability when it gets too deep? A lot of that old tech hit the sweet spot on abstraction without taking it too far.
Is the issue really that old is now new, or is it that abstraction actually becomes a liability when it gets too deep? A lot of that old tech hit the sweet spot on abstraction without taking it too far.
Web Scientists is new Science)
These frontend pity parties are so tiresome and the lack so much context on the industry, historical evolution of the web, client usage patterns, client feature capabilities, consumer demand for things, etc.
They all ring of, "my job got harder, not fair!", as they take home near top 5% salaries. Just do your jobs, stay informed, right tool for the right job, etc. Good grief.
They all ring of, "my job got harder, not fair!", as they take home near top 5% salaries. Just do your jobs, stay informed, right tool for the right job, etc. Good grief.
Said everyone.
The way we do stuff today is just a better and improved way to do the same thing we used to do yesterday, the fact that we have so much tooling is just a reflection of the fact that the web was created to serve documents and now we need to serve apps, so we need transformers along the way that allow for that 100% change of scope. But we aren't changing the base (HTML/CSS/JS, which we should), just the wrappers on top of it.