What will make you hate web development:

* All the unnecessary nonsense: frameworks, template foolishness, tooling, thousands of dependencies, and so forth

* Bad advise. Be critical of all advice, including this advise, especially since you are already an experienced developer. Be extremely critical of any advise that attempts to make the technologies or languages easier. Simple is not easy.

What makes JavaScript a fun experience:

* Expressiveness. Functions are first-class citizens which means they can be used and executed anywhere a primitive type can be used. This is a feature, not an accident. Since ES6 the language has lexical block scope, which is great for writing structured code without a bunch of syntax decoration.

* Rapid experimentation. JavaScript compiles fast enough that you won't ever know there is a compile step. This allows you to write code and test it instantly. The biggest limitation in this process is you.

* Appreciate the data structures provided for you. Treat the DOM like a data structure, which it is, by using the standard methods and your code will be more expressive, smaller, and execute several orders of magnitude faster. Being comfortable with how the technologies work allow you to write logic that is more fun to test and more interactive to use.

Here is a fun personal project that I recently worked on. The GUI only took a bit more than 2 weeks to write and fully test: http://mailmarkup.org/sharefile/demo1.mp4

> Be extremely critical of any advise that attempts to make the technologies or languages easier. Simple is not easy.

This is great advice. I would have avoided a huge snafu on a recent project if I had listened to my gut instead of adopting an unproven "easier" approach promoted by a FAANG-sponsored open source framework.

Could you possibly share more details on this? Would also love to avoid the pitfall is possible. Thank you

Try ELM, with elm-ui it makes much more sense than the dumpster fire that is "modern" JavaScript development.

Maybe I'm just old like you. But I remember that it was easy to make graphical user interfaces, connected to a database in simple tools such as TK or visual basic ver 2.5

But somehow around 1995 we lost our way...

I'm running a .net exe as a server, on "raw" sockets. For the front end, typescript with 0 dependencies that aren't built into browsers. My own "framework" on both ends, written to specifically cover my needs (and do no more). WebSockets maintain connections (I wrote the server implementation from WebSockets specification - no iis or asp.net necessary), and HTML5 Canvas renders content (I wrote the renderer - working on vetting whether or not I can switch to WebGL currently). I may migrate to web assembly through C# to cut javascript out completely if that becomes available without the blazor framework requirement.

It's a lot of fun to work on, it fits my specific (unusual) needs, it's fully predictable, and it's fast as hell.

There is no chance I could have convinced someone to pay me to build this. I'm a solo founder with 20 years of r&d programming and high complexity, high traffic, application architecture experience.

As crazy as this stack may sound to some; the chances that this system will continue to run and be usable without modification in 10 years is pretty high.

I think a lot of it is many entering the field today are throwing components together more than optimising their work. You look at the source of pages and see the mishmash of various javascripts, CSSs, and HTML.

Then again I sometimes see a well crafted thin website, usually this is one that's been around a while (which after a few re-boots learned that just getting anyone to re-make it again is not going to fix the problem.) Look around, they are out there.

So what can I say, there is a lot of technical debt in web development lately (i.e. WordPress), and at some point these will come due. The script kiddies will not be the choice to fix the problem, but folks who care about the long term will - and with that there will be a chance to go through the cruft and refactor a more optimised web.

I'd recommend not trying to enjoy it anymore, and instead focus on the subject of what you're working on. Once you accept that coding arbitrary stuff just isn't inherently that interesting, you can use it as the tool it is and find something more interesting to work on. I've long since given up trying to understand all facets of my current js stack, and pick it up as necessary. I direct my interest to specific hard tasks and maintain a distance from really caring about the tools. I used to give a shit about HTML semantics and other language syntax bs that doesn't matter, and now I focus on the problem because those things barely matter.

Unfortunately I can't cheer you up except to say that I sympathize. I enjoy many different facets of programming but trying to understand modern web development makes me want to tear my hair out, it feels like it's almost designed as a "moat" where you have to specifically specialize in the area to understand best practices and why they exist.

I do enjoy JavaScript, and I've found much more happiness sticking to the absolute minimum for personal projects: vanilla JS or sometimes React + JSX without NPM.

You're not missing anything. Modern web development is a dumpster fire, and hating it is perfectly reasonable and justified.

I am interested in this too. I looking to Elixir & Phoenix framework ...but I am not sure I can find a remote job

I got out of it for a lot of the reasons you mention above. It made me not enjoy programming much anymore. I switched to iOS development, I'm not sure why really, it could have been anything I think I just picked it up at the right time and started getting work and really enjoying it. Native mobile development's hype period is long gone, it's a smaller and more mature and the code quality is often far better, cross platform and PWAs are eating up the boring json-viewing app market so whats left is actually pretty fun stuff if you can get it.

I was there once as well. Then I've tried Vue.js framework (I am a front-end developer who spent too much time in jQuery-based projects) - I've written a blog post about it as well: https://lukaszkups.net/notes/thanks-to-vuejs-ive-found-front...

Do you have a need for those systems? Unless you're working on a large project which has specific needs, you will need at most the package manager, framework of choice, test framework, and maybe babel. Just because you can use more things doesn't mean you need them.

If you're doing something internal and tiny with Vue for example, you could just import it like any other script and not use anything else, not even npm.

The “modern web” will be a case study for psychiatrists once this bubble is over. (Seems to be a creation of the cloud business marketing machine)

These elements, Javascript, DOM, HTML together portray a picture of modern web development. This is one in which developers are trying to handle more complexity and sophistication while improving their productivity and efficiency.

If it’s a trivial mobile app are you sure you need JavaScript? A traditional server-side web app is accessible on any mobile device and doesn’t require much of any JS.

As many others below, I can also say I sympathise and often feel the same. As you said, everything feels super fragile and held together with only duct tape.

Why is it so? I believe because everything started switching to web lately so it gained a lot of focus. Being open-source in nature it attracted a lot of new ideas and this is what lead us to the influx of new frameworks we have today.

It is a good thing because innovation->improvement, but also a bad thing because a huge mess and choice paralysis :D. I also feel overwhelmed with all the transpiler and compilation steps, pretty much gave up on understanding everything.

How to hate it less? What @valand suggested below makes sense to me, by focusing less on the technology and its brokeness, but rather on the product, best practices and the end-goal. Also, even if the build system is a mess we can still write clean, high-quality and tested code which can be reused. This is what we did, propagated this culture through the team and that helped me hate things less. We were reading engineering books, having clean code dojos, best practice presentations etc. My takeaway from that was choose your victories when you can have them and enjoy them.

Another approach would be to join the madness by creating your own solution - which is what I also did. I know it is a https://xkcd.com/927/ case, but it was too fun and interesting so I couldn't help it :)

We basically built a DSL that compiles to the underlying stack of choice. If somebody wants to give it a look it is here: https://github.com/wasp-lang/wasp

Good luck and hope you find peace with whatever you choose!

Felt the same even though I'm just 3 years into professional software development.

I found that the most comfortable place to look at software development is at the architecture level and I suggest you try too.

You'll be able to see the roles of each component in a system. It's magnificent.

Tips:

1. In the end, you'll only need to know the fundamentals

2. Docker builder pattern really helps with the build scripts thingy if you're developing a web app, either for the frontend and backend side. It really helps with fragility because fragility is often caused by leftover states and Docker container really helps you with that.

3. Rewrite instead of reuse parts that are not essentials / easily breaks. Pass-by-value and copy-paste was invented for something ;D

4. If you're using javascript, consider using TypeScript. It saves you a lot of time debugging for type-related bugs.

5. For browser/browser-like apps, use declarative language frontend libraries such as React, but don't rely much on other libs that come with React's popularity (such as redux, react-bootstrap, etc). They usually don't help as much and could be a hindrance in the future. All you need to understand are the fundamentals: html, css, and javascript.

6. For backends, don't feel forced to follow some architecture pattern such as (MVC, MVVM, etc). They often only apply well on certain tech-stacks, but not the other (e.g. expressjs is more popular than the MVC oriented sails.js, actor system is more comfortable in elm than redux due to the former having static typing). It'll help with flexibility later on.

7. Optimize the most valuable and reused component of the software/system. Over DRYing could lead you into premature optimization/abstraction where it would lead to unnecessary complexity.

8. If possible, only make assumptions if it is commonly done or it is guaranteed to not change frequently in the future. Otherwise, do not reuse. This is where YAGNI applies.

9. Don't feel rushed by the overwhelming amount of new frameworks, those things rarely survive. Choose the most flexible, helpful, and do the least (and most starred). Resist hype-based development because new programmers tend to be excited to learn new things and will inadvertently put what's new in the stack because it is cool.

10. Make it a constant if it can. Give it default if it cannot. If there's no possible default, don't run if not provided, write documentation for it. Do the same when running something. It'll reduce the amount of config in your codebase from now on.

Optimize at the architecture level, because you'll find the moving cogs over there are the most valuable for the business. Do touch the codebase at the lower level to understand what problem resides there.

Any framework you choose doesn't matter much as long as it fulfills the purpose of that very component.

You'll find that some tools and frameworks are better than the other for a particular problem, but usually, the choice of tech stack matters more despite the framework. And the choice of structure, contract, and architecture is the real deal, applicable everywhere.

Example: React feels better than Angular in electron. Nevertheless, electron app done right is almost always slower than native apps done right (not hating electron, I code electron almost every day in 2018). But ultimately you'll need to have a desktop app over publishing game in only-browsers, if you've got to run a game publishing and download management business because requirements and other things.

After a while, you'll realize that the technical decisions that matter the most are which you have to balance between development speed/productivity, performance, and maintainability. To me, it sounds like a pretty decent challenge, and I'm sure it does to you too.

If you're dealing with multi-layered architecture that needs maintaining, press your team or yourself to make each layer as simple as possible, do one thing and do it well, this also applies for frontend apps. Sometimes it takes more line of codes to do less, but it'll be worth it.

These have made my life easier and I hope they help you love programming more too.

(I love programming too, Game programming, Functional Programming, Fullstack, TypeScript, Rust, JavaScript)