I agree, in theory. Just not in practice. Which is why I totally give you the thumbs up still... because intelligent peeps can disagree and be civil. I think. D=
Anywho, it's an outdated barometer. Very outdated. Let me give you one metric that makes that TIOBE index just completely wrong, in terms of web development. NPM's public repo has 25 billion weekly downloads... weekly is not a typo. This doesn't account for private repos, etc. You could easily add more to that to get a more accurate figure since they're not the only repo host (GitHub, etc.).
Now, compare that to NuGet. Granted, not everyone uses NuGet in C++, C#, etc., so this isn't completely accurate either in terms of overall popularity. (I'm excluding things like a Linux distro's repo since it's usually not a developer downloading from that.) The NuGet statistics claim about 3.5 billion weekly downloads. Compare that to 25+ billion a week.
The fact is, most people that rely on TIOBE are not web developers. It hasn't been truly updated in over a decade. It doesn't matter if they've seen a console.log once or twice, that's not what makes a web developer. It had it's time and place, but the dude that wrote is just let it get stale while the world passed him by. And I seriously doubt that when it was written it took any real statical analysis into consideration.
You see the same mistakes in financial markets. People just blindly assuming that because it's a chart it actually means anything of significance. So, I agree with you as maybe it's a starting point for research, but it's only a starting point at best because the data is not reliable at all. This is only if you know zero about the ecosystem you're studying. If you know anything about it at all, you'd get a more accurate picture just ignoring it.
Hi. I'm new here, I saw your question and ask it from chat GPT.
this is the answer that I took from it:
It is still possible to add a reference to a SOAP web service in Visual Studio and have it generate the necessary C# files to call the service. However, the process may have changed slightly since 2005, reflecting advancements in technology and the increasing popularity of RESTful APIs.
In recent versions of Visual Studio, the process of adding a reference to a SOAP web service involves using the "Add Service Reference" feature. This feature allows you to specify the URL of the WSDL (Web Services Description Language) file associated with the SOAP web service. Visual Studio will then generate the client-side proxy classes and other necessary artifacts based on the information provided in the WSDL.
To add a reference to a SOAP web service, follow these steps:
In Visual Studio, right-click on your project in the Solution Explorer and select "Add Service Reference" (or "Add Web Reference" in older versions of Visual Studio).
In the "Add Service Reference" dialog, click on the "Advanced" button.
In the "Service Reference Settings" dialog, click on the "Add Web Reference" button.
Enter the URL of the WSDL file for the SOAP web service in the "URL" field and click "Go".
Visual Studio will retrieve the WSDL and display the available web service methods. Specify a namespace for the generated client-side proxy classes and click "Add Reference".
Visual Studio will then generate the necessary C# files and create a client-side proxy class that you can use to interact with the SOAP web service.
However, it's worth noting that with the rise of RESTful APIs and the increasing adoption of modern web service standards, such as JSON over HTTP, SOAP-based web services have become less common in recent years. RESTful APIs are often preferred due to their simplicity, scalability, and compatibility with a wider range of platforms and technologies. Therefore, the tools and features in Visual Studio may focus more on RESTful web services. Nonetheless, Visual Studio still supports SOAP web services and provides functionality to work with them.
If you're unsure about the options available in your specific version of Visual Studio, consulting the documentation or seeking assistance from the Visual Studio community can provide you with more detailed and up-to-date information.
I don't know if it is right or not, but maybe help you to find it out.
It's an absolute mess. After years of complaining about the lack of SSRS support in MVC, then in .NET Core, and now in .NET, Microsoft's official response[^] is that you have to pay for PowerBI Premium, and move all of your reports to their portal.
There are some free third-party libraries which provide limited SSRS support - for example:
lkosson/reportviewercore[^] - No interactive web control for previewing or entering parameters; no SQL Spatial types support; workaround required for image support on Linux;
We are in the process of developing an online permitting application that collects data and allows the client to make payment(s). I have been tasked with determining what the best option(s)/version(s) are for UI and backend development.
I am a novice and am not very familiar with any of these newer technologies.
Any suggestions for best resources for seeking guidance would be appreciated. If thisis not the proper forum for such a request, please advise.
.NET Core 2.x is out of support, and should not be used - support for 2.2 ended in December 2019.
The same goes for .NET 5 - support ended in May last year.
If you decide to go with .NET, your choices are:
.NET 6 - The current "long-term support" release, supported until November 2024;
.NET 7 - The current "short-term support" release, supported until May 2024;
.NET 8 - Due to be released in November 2023, this will be the next LTS release;
NB: "Support" in this case means actively receiving security patches. The out-of-support versions will still work, but they may contain security vulnerabilities which will remain unpatched. It's always best to keep your application up-to-date, and updates tend to be reasonably easy.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Most folks on here are going to suggest a Microsoft solution. But, I won't. Muwahahaha.
This is a very open ended discussion that could go on for weeks. But, if you're a novice that's just overkill and will only kill the vibe. Start with a minimal framework and eventually learn how it works under the hood. Emphasis on minimal. So many web developers think they're web developers but they have no idea how React works under the hood for instance.
Udemy has several courses on it, etc. too. Eventually, you'll want to learn proper relational DB design, etc. but save that for later. Because you'll have a lot to learn right now, including polyfills, ponyfills, browser quirks, accessibility, etc.
Note: Stay far, far away from Angular if you want to be a good web developer.
You would not choose min(300px, 500px), as that makes no sense: 300 is always smaller than 500. It is used when you want to select the smallest of a set of different value types. See the example at CSS min() function[^], which will select either 50% of the width of the div element, or 300 pixels if that is smaller. So the selected element will not be larger than 300 pixels wide.
The reason you got downvoted most likely is that you asked for a lot of work in the reply (real world code examples), but you didn't put a great amount of effort into the question yourself. Remember, we're happy to help but nobody here works for free. Our time is also valuable.
That being said, the most common reason people need to deal with a minimum value of anything in web development is with responsiveness and scaling as a result of it. The browser (and thus viewport) can be resized when using a desktop computer. If the user sizes the browser too small, sometimes you need a guarantee an element/container maintains at least a certain size. Or maybe you want to scale down font size with a smaller viewport while ensuring it doesn't get too small, etc. Whatever the case, responsiveness is the usual reason they are used.
The max size is used less in practice. But sometimes it can useful when going in the opposite direction and making sure things don't scale too large, if say the user is on an 8K display, etc.