...and handle presentation layer stuff on the server? Crazy. Well... it's crazy that the development world is still swinging back and forth so hard on this after 40 years.

When people implement this, they'll see old bad patterns come back. Presentation and business logic will get mixed up together in awkward, difficult-to-maintain ways. You'll get pages where the state gets complicated or out-of-sync, some stuff will be difficult to debug, and you'll wish for simpler transactions between client and server (and for the ability to re-use endpoints between different types of clients).

And then someone will save us by introducing thick clients. Then thin clients, then thin ones but with a twist, then thick ones again. And, at every generation, I have to pretend to be excited about the new game-changing paradigm.

Every project - business or otherwise - starts with developers picking a language.

When there's not a strong incumbent in an organization (and sometimes even when there is), they often pick based on what they learned in school (which is the explanation behind every legacy project written in Delphi), or what they've used for hobby programming (which is a large part of why VB6 was so popular in 1998, because so many developers then had done their first programming in GWBasic or QBasic or whatever). In turn, VB6 being popular in 1998 is a large part of the reason why all those business apps in .NET you mention exist.

Microsoft owes a ton of its developer support (and overall success) to good developer tools, and for the most part they know this and work to keep improving. They've spent a lot of time servicing "absolute beginner programmers" (who can learn to organize their thoughts into steps with Minecraft coding exercises and what not) and also to support "dedicated hobbyists" (who can work in DirectX/C++, or who can do things like make a multi-platform game with Unity).

But they've missed a section in the middle - the teen programmer who wants to do their first "real" project. It's harder than it should be to do that project in .NET, and that means they'll lose people to something like Python that has less ties to their ecosystem.

And more importantly, it means I'm annoyed because setting up my kid's project is harder than it should be.

I work as a programmer, primarily with .NET - and I generally get along just fine.

My kid, though, is just learning programming - and that means writing games. He has done some stuff in Scratch, but his ideas are complicated enough that he's better off moving on from that. He did an online course with Python, and we started writing a text-y game with that - but he really (and naturally) wanted proper graphics. I couldn't immediately figure out how to get an image library working with the goofy install they'd done, so I figured "Hey, I can just get him going in .NET" - that'll be easy to support him with.

Writing a simple 2d game in .NET is a bizarre mess.

From past experience I knew using the built-in forms/GDI would be slow (performance wise) and unpleasant, so I figured I'd find out what MS recommended now. I searched.. and I don't know. There's like 10 generations of half-realized/extinct crap: DirectX.NET and XNA and at least a couple more, all with half-functional zombie documentation, dead links, and instructions that no longer work. There's a bunch of MS articles pointing you towards libraries that died long ago (SlimDX, SharpDX) and otherwise suggesting approaches that are broke.

Or they suggest you use very heavy-weight libraries - things like Unity or Monogame - that have a whole network of other challenges to pick up, and/or require a ton of boiler-plate code/external tools to get going. These tools are probably great - but the point of this is to learn programming, not to learn how to use a bunch of resource editors.

Eventually I found Win2d, which is so far "not insane"... like, you can load and draw an image to your form without a ton of code, without external tools, and without having to pay to remove a splash screen. But even Win2d has a bunch of baggage that makes it awkward for a new programmer. Like, it works with "Universal Windows Platform", which means a bit of config to get going and is generally odd. You have to edit XML to place your form on the page (which I'm OK with, but is pretty imposing when you're starting out). You have to use special URIs (rather than just hardcoding a path) to get to your assets, since you don't seem to have permission on the regular file system. There's a bunch of methods that are async only, which makes for some very intimidating looking await patterns when you're just starting out.

Like, I can get a project going for him to work with, but it's all been way harder than it should be.

MS should put a simple graphics/sound library in .NET: something that's easy to consume using straightforward, self-contained, procedural code. Ideally, you could compile it to a self-contained EXE, a web page, or an Android app.

Doing that would capture a ton of interest from kids looking to program - and I feel like MS used to understand this (back in GORILLA.BAS days).

Welp, as expected I got the normal variety of responses here - all of them smug/dismissive and all of them different.

Lightning solves everything. It's all the fault of the other side in some schism. Bitcoin isn't about bulk transactions, it's a store of value and you'd use something else or some other service for that kind of thing. And your reaction, which is that there just isn't a problem to begin with.

Yep, that's a bingo. Cool. Have fun.

Bitcoin transactions currently take an average of 10 minutes, while only processing an average of 5 per second.

It's already incredibly, unusably slow, and there's every reason to believe it will scale very poorly.

I believe this is a device built to isolate conversations between women, determine if those women have names, and snoop on the conversation to see whether it's about a man or not.

Progressive goal, but still a privacy breach.

Word is probably worse, sure, but both have had catastrophic security problems over the years.

The PDF format is a brutal mess.

You aren't wrong but it's worth noting that most everything is now based on the .Net framework.

I'm a .NET developer, and I like .NET... but this just isn't even close to right. Even most of Microsoft's software isn't .NET. Very few important/common consumer desktop applications are in .NET.

I think the plan is to shift people to using Microsoft Chrome (or whatever they are calling it) and Steam is only used by gamers.

Mostly Steam is used by people to play games, yes - but it's not like "gamers" is a weird niche. Steam has over a billion accounts and like 100 million users active. Steam (and "games" in general) is a huge thing tying people to Windows.

I've ported tens of thousands of lines of VB6 to VB.NET. WebClasses and forms both have some awkward bits (including control arrays) that we built transition libraries for over time, and sometimes error handling is weird - but mostly it goes really smooth. Lots of stuff that's further from the UI requires no transition at all: copy/paste, wrap in a class declaration, change a little lifetime stuff, and it's mostly done. Honestly, I'd rather port VB6 code to modern .NET than try to port, say, early ASPX pages - most stuff comes over really clean.

(Well, I'll make an exception for VB6 "retain state" web pages, which never really worked well to start with, and need more of a paradigm shift to function in the modern world - but I've only seen a few of these in my career).

And there's ton of stuff you don't have to port at all. It's very regular you can ditch huge chunks of code and replace it either directly or with a small wrapper for something in the standard library (eg. countless hand-rolled stringbuilder and associative arrays and base64 strings and awkward calls to APIs, all get mostly flushed).

Very few programmers have as many positive memories as I do of VB6 or have worked with it more in the last 10 years... but what you're saying is nonsense. .NET is better than VB6 in a million ways and supports programming in modern paradigms that are way better, but also - barring some pretty minor stuff in the grand scheme of things - doesn't prevent you from doing things in the same old way if you want. The codebase I work with daily has everything from "light, modern WebAPI platform supporting a variety of front-end clients" to "VB6-webclass-templates, barely-ported, URL-rewritten-into-ashx-calls, mostly-unchanged-since-1998", all sharing code and all working fine together.

I think a lot of VB6 programmers were turned off by early versions of .NET. ASPX pages were never a great model, the early .NET debugger was pretty terrible (again, this is one of VB6's real strengths - that debugger would edit-and-continue through anything.. except a case statement for some reason), and applications were awkward to distribute.

All those complaints were fair, and I think skipping the first versions of .NET probably was a reasonable choice for lots of people. But that's all a very long time ago at this point.

Partially? I believe you can develop and debug Windows apps in VB6/Windows 10. I don't think you can run VB6 web apps - or at least not ones that use WebClasses (which were always obnoxious). I use a XP VM when I have to deal with these, as even in Vista/7 there were problems (IIRC, though it's not like I'm looking for reasons to use Vista either way).

VB6 had a number of good things going for it back in the day - particularly the debugger was really smooth. But really there's no excuse for not having your code ported to .NET at this point; I've ported a few systems for work, and it's really a simple job.

Yeah the keyboard is pretty basic, and at one point web security/privacy was a lot simpler.

The web worked without javascript - without all of the effective access it grants to memory and compute resources and the network. The web would work without cookies or persistent storage. The web worked fine without access to a webcam or microphone - and both are absolutely, obviously catastrophic privacy concerns. Tons of features over the years have created opportunities for new vulnerabilities and privacy risks: ajax calls or webgl or webAssembly or, hell, CSS (because, in combination with js, you can measure how things display in ways that identify computer properties).

You could have used the same logic to deny all these features over the years, and the web could be stuck in 1993 being much less useful than it is now. Or you could learn from past mistakes in terms of privacy/security errors, but still let a user decide whether they want a specific webpage to have access to Bluetooth (or whatever).

[quote]Slashdot doesn't know whether that is my keyboard or I just cut and pasted text from another window.[/quote]

Slashdot could distinguish these sorts of things if they wanted to - javascript gets fairly fine grained information about keyboard events. Of course, you could write a browser/extension to lie about key events/state, but you could also make a browser that lies about your magnetometer or whatever. It's true that there's several layers of abstraction and indirection between javascript and your physical hardware, but that's true of almost all software.

Anyway, yeah, the important point is that you can control what interaction the browser has with your hardware by - like in your example - moving the mouse out of that tab. As long as users get to make decisions about hardware access (and are steered away from "very bad decisions"), I think there's a lot of value in making those options available.

It wasn't a joke. I was pointing out that perhaps you hadn't considered your comment before submitting it, and maybe you should slow down.

Slashdot absolutely has access to your keyboard. For example, if you put your cursor in a comment box and start typing, Slashdot reads the keys you're pressing in order to record your comment. Regular javascript can read a variety of input from keyboard and mouse, some of which users might not expect.

In any case, your normal keyboard interaction - eg. typing a comment - with Slashdot is fine, because you, as a user, understand it and can control it.

Where privacy breaks down is where the user isn't given choices, or doesn't understand those choices (eg. 3rd party tracking cookies). Accessing your battery status (or the other stuff mentioned in the OP) can leak privacy information, and thus shouldn't be done without a user's permission - but with a user's permission may be useful.

Saying "web pages shouldn't access or interact with hardware" is overly broad and generally misguided. There's no reason a web page shouldn't be allowed to interoperate with a variety of hardware (obviously keyboards and mice and screens - but also microphones or printers or magnetometers), as long as the user can consent to and reasonably control that interaction.

That sounds great. To start off, I think we should remove Slashdot's access to your keyboard. If you don't like this response, maybe you should also remove its connection to your monitor.