3 ms·

Holy s* yes!!! Finally web dev moves in the right direction! JS developers will finally realise how bad they've had it.

tracker1 11y ago
Yeah... I mean give me layers of interfaces, indirection and dependency injection that's hard to follow. Class structures that don't flow well for procedural workflows. Projects with dead end code paths because they are so big no one person understands even half of it. I mean, these are such great things. I've totally missed them in modern JS development, and haven't been fighting against many of these practices for years now at all (/sarcasm). Seriously though, my biggest issue with JS development today is people that don't understand patterns beyond what they use in C# and Java, and don't want to keep things simple and easy to reason about. Most C# and Java applications I've worked with have many layers of unnecessary complexity for the sake of, more because "that's how it's done in 'Enterprise' software" more than it is about what's truly needed. I actually really like C#, and the thought of being able to use some of the features really appeals to me. That said, actually working with solutions common from .Net, I've been happier without it. I've spent the better part of my time the past 4-5 years migrating away from .Net solutions to Node based ones... once you get past people trying to implement overly complex patterns and embracing "the node way" of simple, composable, functional modules... it can and does go much more smoothly. --- edit: When I say complexity for the sake of... it's usually for the purpose of testability, often in scenarios that don't have tests, and beyond that aren't trying to target multiple implementations of an interface. Even then, with JS you don't need the added constraints. I know there are "contract" concerns, but what that gets you is WS-* and SOAP/WSDL hell that nobody really understands vs easy to reason REST/JSON services. In the end, having simple systems where you have to learn a bit of convention tends to be easier than complex systems with layers of indirection.

Yeah... I mean give me layers of interfaces, indirection and dependency injection that's hard to follow. Class structures that don't flow well for procedural workflows. Projects with dead end code paths because they are so big no one person understands even half of it. I mean, these are such great things. I've totally missed them in modern JS development, and haven't been fighting against many of these practices for years now at all (/sarcasm). Seriously though, my biggest issue with JS development today is people that don't understand patterns beyond what they use in C# and Java, and don't want to keep things simple and easy to reason about. Most C# and Java applications I've worked with have many layers of unnecessary complexity for the sake of, more because "that's how it's done in 'Enterprise' software" more than it is about what's truly needed. I actually really like C#, and the thought of being able to use some of the features really appeals to me. That said, actually working with solutions common from .Net, I've been happier without it. I've spent the better part of my time the past 4-5 years migrating away from .Net solutions to Node based ones... once you get past people trying to implement overly complex patterns and embracing "the node way" of simple, composable, functional modules... it can and does go much more smoothly. --- edit: When I say complexity for the sake of... it's usually for the purpose of testability, often in scenarios that don't have tests, and beyond that aren't trying to target multiple implementations of an interface. Even then, with JS you don't need the added constraints. I know there are "contract" concerns, but what that gets you is WS-* and SOAP/WSDL hell that nobody really understands vs easy to reason REST/JSON services. In the end, having simple systems where you have to learn a bit of convention tends to be easier than complex systems with layers of indirection.