• (nodebb)

    WebForms is obsolete tech for nearly two decades now... nothing more to say there.

  • (nodebb) in reply to MaxiTB

    Also still in use pretty much everywhere. There is one in particular I've been trying to replace for years but the client's answer is always the same: if it works, why change it. All made funier by this particular client being a F500 company with no lack of budget.

  • Richard Brantley (unregistered) in reply to MaxiTB

    Honestly, WebForms was a really bad approach to web development from day one. It was an attempt to make web development look and feel like old desktop VB development, and as such is was entirely the wrong metaphor. Developers would do all sorts of painful contortions to work within its rules, and I've seen very few WebForms projects that didn't devolve into an aggravating mess.

  • (nodebb) in reply to AGlezB

    All made funier by this particular client being a F500 company with no lack of budget.

    It's not the budget. Nobody wants change -- especially F500s.

    I worked for a company where the business users were jumping up and down, waving fists, torches and pitchforks, complaining that the accounting system they were using didn't work for them. They couldn't get good reports, they couldn't track information that was now required because of Federal changes to things like -- o, idunno -- taxes and employment demographics, grants, etc.

    They bought a shiny new ERP. They paid an HPC to implement it and convert [all historical] data. And they also paid said HPC a lot of $$$$$ to customize the new ERP to mirror the functionality in the old system. So ... they spent some $2M to get what they already had. And, of course, the fist waving, cursing, screaming, and torch fests continued. It was quite painful.

    Not only are they not a F500, they're actually a NFP. Because they also don't want change.

  • (nodebb) in reply to MaxiTB

    WebForms is obsolete tech for nearly two decades now

    Sure, it's obsolete from an architecture standpoint. However, corporations love the fact that a WebForms project built in 2005 still builds and still gets security fixes from Microsoft.

    Everything modern needs some amount of love and care every year, even if it's just to upgrade the dependencies and re-test. Very few places that aren't development savvy can handle that.

  • Argle (unregistered) in reply to Jaime

    Sure, it's obsolete from an architecture standpoint. However, corporations love the fact that a WebForms project built in 2005 still builds and still gets security fixes from Microsoft.

    Yet nobody in management would be seen driving a car made then.

  • (nodebb) in reply to AGlezB

    That's a fair and depressing reality check and I couldn't agree more.

  • (nodebb) in reply to Richard Brantley

    Yeah, I still remember the big promises on a conference of write one UI code for both desktop/web which was part of the whole .net idea. Obviously they ran out of time and the idea made little sense from where we are standing right now, but spoiler: It got a renewal when smart people had the idea of web UI on desktop. Oh wait, that was MS again with Windows 8. Ha, good times.

  • (nodebb) in reply to Jaime

    still gets security fixes

    This always cracks me up, the main reason why a lot of code from .net framework was actually not ported or completely changed in netcore are security issues by design that can't be fixed without breaking backwards compatibility.

    It's like this huge oil tanker, where they patch those tiny holes in the paint here and there while under the water line that are a few giant holes that are basically patched up with a thin plastic layer waiting to burst the next time a fish bumps into it :-)

    So yeah, everything .net framework is basically a disaster in waiting if developers not have fixed all the issues that got fix in netcore and not use anything outdated or vulnerable in the first place like the BinarySerializer.

  • (nodebb) in reply to MaxiTB

    It got a renewal when smart people had the idea of web UI on desktop. Oh wait, that was MS again with Windows 8.

    Well, that attempt isn't dead. It just keeps going and people reinvent the same thing every 5 years. React Native, or Kotkin Multi Platform, to only name 2 of a myriad of other platform efforts, have the once again goal of "write once, deploy everywhere". Except now it's "mobile and web" instead of desktop. Same difference. Oh wait, did I inadvertently reuse Java's initial motto? We know how successful that was with Java...

  • (nodebb) in reply to MaxiTB

    This always cracks me up, the main reason why a lot of code from .net framework was actually not ported or completely changed in netcore are security issues by design that can't be fixed without breaking backwards compatibility.

    Security issues normally fall into two categories: Dumb things we do, and vulnerabilities in software that we include in our projects, but we didn't write. Developers will do dumb things forever - in COBOL, VB, WebForms, netcore, WebAPI, whatever. The mechanisms to stop this haven't changed in forty years and netcore didn't do anything to make us smarter.

    As for the platform itself; sure, WebForms is utterly incapable of managing security for you if you employ a modern architecture. But, old-fashioned cookie-based sessions on a single server instance with no "Log in with Facebook" or similar, is just fine in WebForms. Coincidentally, most corporate apps don't need hyper-scalability or any of the other stuff that has evolved over the past 20 years. As long as Microsoft keeps fixing the bugs in the shipped feature set and the developers don't get over-ambitious and try to make a modern application on a ancient platform - it's plenty secure.

    What we want is backwards compatibility. Writing code in 2005 and having it still work in 2028 is extremely valuable to a team that writes a simple thing that's used by 400 people for a simple task.

    Our public-facing stuff is .Net core with Vue.js on the front-end. I can tell you that my team isn't "modern enough" to figure out automated testing and seamless deployment. Either they have to spend months getting good at those things (or I have to pay the salary or someone who already is good at it), or we spend 25 percent of our time running "npm audit" and "dotnet list package --vulnerable" and addressing whatever those tools spit out. These platforms have a habit of changing thing often, or even worse, vulnerable packages often get abandoned.

    Our ancient WebForms stuff requires nothing but applying Windows updates. Things rarely break.

  • Marvin (unregistered) in reply to Ralf

    It's not like MS themselves aren't still pushing that cart ... MAUI is the same "write your code once, use for Win/iOS/Android" thing. And last I checked, it's still realistically unusable.

  • (nodebb) in reply to MaxiTB

    Oh, there's more. Every couple of years the ask some change to the site that usually ends up taking longer and costing more that what it would take to just migrate the whole site to some new framework.

  • LZ79LRU (unregistered) in reply to AGlezB

    That is precisely why they do not lack budget.

    We developers like to jump on the new shiny thing like a bunch of magpies. And I get it. It's bloody shiny! But from a business perspective it's much better to just stick to what works and keep paying people to maintain it than develop from scratch with all the associated costs.

    Remember, the cost of a new system is not just development. You also have the cost of training all the users, developing documentation, training your developers to maintain it etc. And unlike the old system whose flaws are already well known to you, you now have a whole new set of unknown bugs yet to be fixed and misfeatures yet to be adjusted that are completely unknown to you and will remain so until someone runs into them business disruption first. And that's before we get into any certification and stuff that might be involved.

    It's just much cheaper and less painful to stick with what you got. Even if it is technically obsolete.

  • Anonymous Coward (unregistered) in reply to Ralf

    Write once, debug indefinitely everywhere?

  • LZ79LRU (unregistered) in reply to Anonymous Coward

    Beats write many times, relearn, retrain, redeploy every time, debug everywhere anyway.

  • (nodebb)

    As another grizzled old fart I agree w LZ79LRU.

    The shiny new ground-up replacement system will be just as badly designed, incompetently managed, under-resourced, rushed, and full of noob mistakes, HPCs, and offshored garbage as the old system was. It'll just use newer libraries and idioms to be just as bad.

    The enemy is not the technology. The enemy is the industry. And we have met him/her and they are us.

  • (nodebb) in reply to WTFGuy

    No it won't be just as bad: it'll be worse. It won't implement all the necessary functionality because the developers will not have a complete understanding of what the old system does - in fact nobody will. It'll also be extremely slow because the developers are all using up to date modern PCs, not the five year old crud that the users have.

  • (nodebb)

    Why be we talking about WebForms? Everyone knows true pirates be coding in R.

  • (nodebb) in reply to jeremypnet

    And I'd agree if the site had any complexity but it's a 4 page site, counting the login, where external truckers can see their pending transport orders. I don't know who made it originally but it has all the markings of a start-of-the-century development, when security was something you might have heard about in some developer conference but you didn't really know and didn't care and the only "mobile devices" where laptops and PDAs. Plus it's a 100% desktop site with 0% responsiveness which is used almost always from a smartphone. If I had to make a guess I'd say the only reason the site has stayed like that for so long is because nobody from the company uses it.

  • Mike Sandbox (unregistered) in reply to LZ79LRU

    100% this. As was said by some guru guy in a WTF long ago, we are not here to drink coffee and shit out code. We're paid to help the company make money. Obsolete tech that still works but isn't as fast, scalable, or secure as new tech is perfectly fine for a task that isn't public-facing, used by only a few people, and gets people what they need within the amount of time they want. It also has the advantage of a sizeable knowledge base amongst the users and maintainers. The phrase 'good enough' often means exactly that.

Leave a comment on “The Pirate's Code”

Log In or post as a guest

Replying to comment #681171:

« Return to Article