Bazaprogram.ru

Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Javascript asp net

Взаимодействие с JavaScript

В этой и последующих статьях рассматриваются способы взаимодействия JavaScript и ASP.NET: создание сложных сценариев, построение интерактивных серверных элементов управления ASP.NET, асинхронное взаимодействие с сервером с помощью Ajax и т.д. Если вы не знакомы с основами JavaScript, рекомендую обратится к разделу «Учебник JavaScript» на нашем сайте.

Создание JavaScript-процессора страницы

Сколько раз вам приходилось щелкать на веб-странице и затем наблюдать за загрузкой сайта в строке состояния вашего браузера? Возможно, разорвано соединение с Интернетом? Или произошла какая-то ошибка подключения к базовой системе? Или же просто система работает столь медленно? Часто эти проблемы усложняют признание новых веб-решений, особенно при замене более быстро реагирующего и предоставляющего большие возможности клиентского приложения (такого как Windows-приложение).

В этой ситуации самый легкий способ убеждения пользователей своего приложения в его работоспособности — предоставление им сообщений о ходе выполнения, которые ставят их в известность о том, что в настоящий момент система обрабатывает их запрос.

Одним из распространенных способов предоставления сообщения о состоянии является применение JavaScript для создания стандартного процессора страницы. Когда пользователь переходит к странице, обработка которой занимает много времени, процессор страницы отображается немедленно и выводит стандартное сообщение (возможно, с прокруткой текста). В это же время запрошенная страница загружается в фоновом режиме. Как только результаты становятся доступными, сообщение процессора страницы заменяется запрошенной страницей.

Проблему задержки обработки невозможно решить, добавляя код JavaScript в целевую страницу, поскольку этот код не будет запущен до завершения обработки страницы и возврата визуализированной HTML-разметки пользователю. Однако универсальный процессор страницы, который обрабатывает запросы к любой отнимающей много времени страницы, можно создать на своем сайте.

Чтобы создать процессор страницы, понадобится отреагировать на JS-события onload и onunload. Ниже приведена страница (по имени PageProcessor.aspx), в которой демонстрируется этот подход. Она отображает индикатор загрузки страницы (большую коллекцию индикаторов можно загрузить на сайте www.ajaxload.info). Элемент связан с двумя функциями, которые вскоре будут рассмотрены.

Чтобы использовать процессор страницы, нужно запросить эту страницу и передать в аргументе строки запроса требуемую страницу. Например, для загрузки в фоновом режиме страницы Default.aspx понадобилось бы использовать следующий URL-адрес:

Процессор страницы нуждается в очень небольшом объеме серверного кода. Фактически, все его действия сводятся к извлечению первоначально запрошенной страницы из строки запроса и ее сохранению в защищенной переменной класса страницы. (Это полезно, поскольку затем эту переменную можно предоставить коду JavaScript с использованием выражения привязки данных ASP.NET, как будет показано чуть позже.) Полный серверный код станицы PageProcessor.aspx имеет следующий вид:

Остальная часть работы выполняется клиентским кодом JavaScript. При первой загрузке процессора страницы генерируется событие onload, которое вызывает функцию BeginPageLoad() клиентской стороны. Функция BeginPageLoad() сохраняет текущее окно открытым и начинает извлечение страницы, запрошенной пользователем. Для этого применяется метод window.setInterval(), устанавливающий таймер, который периодически вызывает специальную функцию UpdateProgressMeter().

Код JavaScript-функции BeginPageLoad() выглядит следующим образом:

Первый оператор кода указывает на страницу по ее новому URL-адресу. Обратите внимание, что страница, которую требуется загрузить, не является жестко закодированной в коде JavaScript. Вместо этого она устанавливается с помощью выражения привязки данных . Когда страница визуализируется на сервере, ASP.NET автоматически вставляет значение переменной PageToLoad на свое место.

Последний оператор кода запускает таймер, используя функцию window.setInterval(). Каждые 500 миллисекунд этот таймер срабатывает, и указанная строка кода выполняется. Эта строка кода вызывает JavaScript-функцию по имени UpdateProgressMeter() и продолжает отслеживать текущий счетчик цикла.

Функция UpdateProgressMeter() просто периодически изменяет сообщение о состоянии, придавая ему сходство с анимированным индикатором выполнения. Сообщения о состоянии циклически повторяется, периодами от 0 до 5. Код JavaScript, который решает эту задачу, имеет следующий вид:

И, наконец, когда страница полностью загружена, генерируется клиентское событие onunload. В приведенном примере событие onunload связано с функцией EndPageLoad(). Эта функция останавливает таймер, очищает сообщение о ходе выполнения и устанавливает временное сообщение передачи, которое исчезает, как только новая страница визуализируется в браузере. Ниже приведен код:

На протяжении всего процесса никакие обратные отправки не выполняются, Конечным результатом является сообщение о ходе выполнения, которое остается на экране до тех пор. пока целевая страница будет полностью обработана и загружена:

Чтобы протестировать процессор страницы, нужно просто воспользоваться целевой страницей, которая занимает много времени при выполнении на сервере (из-за объема работ, выполняемых кодом) или при загрузке на клиенте (из-за размеров страницы). Медленную страницу можно имитировать, помещая в целевую страницу код задержки, подобный следующему:

Теперь при запросе этой страницы посредством процессора страницы можно будет в течение пяти секунд наблюдать сообщение о ходе выполнения.

Как видите, совсем небольшой объем клиентского кода JavaScript позволяет информировать пользователя о том, что страница обрабатывается. А это, в свою очередь, улучшает субъективное представление пользователя о производительности.

Визуализация блоков сценария

В рассмотренном ранее примере использовался статический блок «; Page.ClientScript.RegisterClientScriptBlock(this.GetType(), «Confirm», script); form1.Attributes.Add(«onsubmit», «return ConfirmSubmit();»); >

Чтобы упростить определение функции JavaScript в нескольких строках, в начале должен быть помещен символ @, в результате все символы будут обрабатываться как строковые литералы, что позволяет использовать несколько строк.

Результат показан на рисунке ниже:

В этом примере применение метода RegisterCllentScriptBlock() не дает никаких реальных преимуществ. Однако методы ClientScriptManager становятся важны при разработке специального элемента управления, который использует JavaScript. Позже будет рассмотрен элемент управления, в котором с помощью метода RegisterStartupScript() отображается всплывающее окно.

Getting Started with ASP.NET Core JavaScript Services

In February I wrote a quick post titled Angular + ASP.NET Core Quick Start with .NET Core CLI. Within that post, I introduced ASP.NET Core JavaScript Services and demonstrated how to create a new Angular + ASP.NET Core application. Within this post, I will take a closer look at JavaScript Services by exploring the supported client-side frameworks and its many features such as server-side prerendering and webpack dev middleware.

Background

Microsoft ASP.NET Core JavaScript Services is part of ASP.NET Core and it enables developers to easily build Single Page Applications (SPA) with ASP.NET Core. Currently, it includes support for the following client-side frameworks – Angular, Aurelia, Knockout.js, React, React + Redux, and Vue.js.

There are many advantages to using this approach, such as:

  • It’s cross-platform, develop on Windows, Mac, or Linux
  • Use any source code editor, develop with Visual Studio 2017, Visual Studio Code, Eclipse
  • Supports many client-side frameworks, such as Angular, Aurelia, React
  • Use the .NET Core CLI, if you are already using .NET Core, you won’t need additional tools
  • Provides a streamlined development experience, everything is already configured and optimised so you can focus on building your app
  • It’s open-source, you can review the source code and contribute, updates occur frequently

Getting started is easy, just run:

A new project will be created that will use ASP.NET Core and C# for cross-platform server-side code, TypeScript for client-side code, webpack for building and bundling client-side resources, and Bootstrap for layout and styling. Within the new project, developers will benefit from the following capabilities:

Читать еще:  При восстановлении айфона ошибка 2003 что делать
CapabilityAngularAureliaKnockout.jsReactReact + ReduxVue.js
Server-side prerendering of SPA components
Webpack dev middleware
Hot module replacement (HMR)
Server-side and client-side routing integration
Code splitting and lazy loading
Efficient production builds

If your favourite client-side framework or feature is missing, fear not – this project is open-source and contributions are welcome! Click here to review the contribution guidelines and get started.

Getting started

You will need to set up your development environment. First, ensure that you meet the following prerequisites before continuing:

Next, install the ASP.NET Core SPA templates:

Note: The use of ::* in the above command requests the latest version.

That’s it, we are now ready to create a new project.

Creating a new project

In this section I’ll create an Angular project, however, please note that you can go ahead and use your preferred client-side framework such as Aurelia, Knockout.js, React, or Vue.js.

Using the command prompt, execute the following commands:

This will generate the project for you, preconfigured with ASP.NET Core, Angular, Webpack, TypeScript, C#, ASP.NET Core, and so on. Next, we can restore the server-side dependencies:

Followed by the client-side dependencies:

Finally, we can run the project using the following command:

Launch your web browser and navigate to http://localhost:5000/ to view the newly created project.

Important: If you are running entirely from the command line, make sure you’re running in development mode.

In the following sections, I’ll provide an overview of server-side prerendering, webpack dev middleware, hot module replacement, and managing client-side dependencies.

Server-side prerendering

Server-side prerendering allows you to prerender the initial state of your application. This results in faster initial load times, improved search engine optimisation (SEO), and support for site preview (social media apps correctly display a preview image).

You can get an idea of how prerendering works by following these steps (using Chrome):

  1. Launch your application, e.g. dotnet run
  2. Navigate to http://localhost:5000
  3. Press F12 to launch the Developer Tools
  4. Select the Network tab and check Disable cache
  5. Press F5 to reload the page

Review the results to see the load time, the number of requests, and the amount of data transferred. In my case, it was 1.22 seconds, 6 requests, and 5 MB. This is quite large as it includes all of the client-side dependencies required by your application.

If we disable JavaScript, we can get a rough idea of the difference that server-side prerendering can make:

  1. Within the Developer Tools, press F1 to access Settings. Configure as follows:
  2. Switch back to the Network tab and press F5

This time it took 396 milliseconds, 3 requests, and only 314 KB. A major improvement!

Note: Server-side prerendering is not designed to run your application without JavaScript. It simply delays loading the client-side dependencies to improve initial load times, SEO, and so on.

Server-side prerendering is configured within /Views/Home/Index.cshtml:

If you need to disable pre-rending, change the above line to:

You can further improve the performance of prerendering by leveraging ASP.NET Core caching:

Server-side pre-rending results in a very fast initial load time and an improved user experience.

Webpack dev middleware

Webpack is used to build and bundle client-side resources. Normally you would need to run webpack at the command-line to kick this off, however, with webpack dev middleware this has been automated. To see this in action, follow these steps:

  1. Launch your application, e.g. dotnet run
  2. Navigate to http://localhost:5000
  3. Open /ClientApp/app/components/home/home.component.html
  4. Change the following line:
  1. Save your changes
  2. Refresh your browser

Your changes will be visible, and that is because webpack is running in the background via the webpack dev middleware.

Webpack dev middleware is added inside the Startup.cs file within the Configure method:

With webpack dev middleware enabled and your application running in the Development environment, you can change any client-side file (e.g. TypeScript, HTML, CSS) and the updated version will be available (almost instantly) to the browser. You do not need to run any build commands manually, so you can focus creating new features.

Hot module replacement (HMR)

Hot module replacement is a feature of webpack that improves upon webpack dev middleware. It injects updated modules into the active runtime so that if you add, update, or delete client-side files while the application is running, these changes will be immediately available without the need to refresh the browser. To see it in action, follow these steps:

  1. Launch your application, e.g. dotnet run
  2. Navigate to http://localhost:5000
  3. Press F12 to launch the Developer Tools and confirm that HMR is active with the presence of this console message:
    [HMR] connected
  4. Open /ClientApp/app/components/home/home.component.html and change the following line:
  1. Save your changes
  2. Switch to the browser and view the updated changes (available almost instantly)

HMR is enabled inside the Startup.cs file within the Configure method:


Figure: HMR in action using Visual Studio Code

Using webpack dev middleware with hot module replacement provides the most productive and streamlined development experience available.

Wake Up And Code!

Adventures in web/cloud dev, and more!

JavaScript, CSS, HTML & Other Static Files in ASP .NET Core

This is the tenth of a series of posts on ASP .NET Core in 2019. In this series, we’ll cover 26 topics over a span of 26 weeks from January through June 2019, titled A-Z of ASP .NET Core!

A – Z of ASP .NET Core!

In this Article:

J is for JavaScript, CSS, HTML & Other Static Files

NOTE : this article will teach you how to include and customize the use of static files in ASP .NET Core web applications. It is not a tutorial on front-end web development.

If your ASP .NET Core web app has a front end – whether it’s a collection of MVC Views or a Single-Page Application (SPA) – you will need to include static files in your application. This includes (but is not limited to): JavaScript, CSS, HTML and various image files.

When you create a new web app using one of the built-in templates (MVC or Razor Pages), you should see a “wwwroot” folder in the Solution Explorer. This points to a physical folder in your file system that contains the same files seen from Visual Studio. However, this location can be configured, you can have multiple locations with static files, and you can enable/disable static files in your application if desired. In fact, you have to “opt in” to static files in your middleware pipeline.

You can browse the (template-generated) sample app (with static files) on GitHub at the following location:

sample app with static files: https://github.com/shahedc/AspNetCoreStaticSample

Configuring Static Files via Middleware

Let’s start by observing the Startup.cs configuration file. We’ve seen this file several times throughout this blog series. In the Configure() method, you’ll find the familiar method call to enable the use of static files.

This call to app.UseStaticFiles() ensures that static files can be served from the designated location, e.g. wwwroot. In fact, this line of code looks identical whether you look at the Startup.cs file in an MVC or Razor Pages project.

It’s useful to note the placement of this line of code. It appears before app.UseMvc(), which is very important. This ensures that static file requests can be processed and sent back to the web browser without having to touch the MVC middleware. This becomes even more important when authentication is used.

Take a look at either the MVC or Razor Pages projects that have authentication added to them. In the code below, you can see the familiar call to app.UseStaticFiles() once again. However, there is also a call to app.UseAuthentication(). It’s important for the authentication call to appear after the call to use static files. This ensure that the authentication process isn’t triggered when it isn’t needed.

By using the middleware pipeline in this way, you can “short-circuit” the pipeline when a request has been fulfilled by a specific middleware layer. If a static file has been successfully served using the Static Files middleware, it prevents the next layers of middleware (i.e. authentication, MVC) from processing the request.

NOTE : if you need to secure any static files, e.g. private images, you can consider a cloud solution such as Azure Blob Storage to store the files. The files can then be served from within the application, instead of actual static files. You could also serve secure files (from outside the wwwroot location) as a FileResult() object returned from an action method that has an [Authorize] attribute.

Customizing Locations for Static Files

It may be convenient to have the default web templates create a location for your static files and also enable the use of those static files. As you’ve already seen, enabling static files isn’t magic. Removing the call to app.useStaticFiles() will disable static files from being served. In fact, the location for static files isn’t magic either.

In a previous post, we had discussed how the Program.cs file includes a call to CreateDefaultBuilder() to set up your application:

Behind the scenes, this method call sets the “content root” to the current directory, which contains the “wwwroot” folder, your project’s “web root”. These can both be customized.

  • To change the content root, you can configure it while building the host, e.g.
  • To change the web root within your content root, you can also configure it while building the host, e.g.

You may also use the call to app.UseStaticFiles() to customize an alternate location to serve static files. This allows you to serve additional static files from a location outside of the designated web root.

Wait a minute… why does it look like there are two alternate locations for static files? There is a simple explanation:

  • In the call to Path.Combine(), the “AltStaticRoot” is an actual folder in your current directory. This Path class and its Combine() method are available in the System.IO namespace.
  • The “AltStaticFiles” value for RequestPath is used as a root-level “virtual folder” from which images can be served. The PhysicalFileProvider class is available in the Microsoft.Extensions.FileProviders namespace.

The following markup may be used in a .cshtml file to refer to an image, e.g. MyImage01.png:

The screenshot below shows an example of an image loaded from an alternate location.

The screenshot below shows a web browser displaying such an image.

You can find the above code in the RazorWebAltStatic sample web app on GitHub:

Preserving CDN Integrity

When you use a CDN (Content Delivery Network) to serve common CSS and JS files, you need to ensure that the integrity of the source code is reliable. You can rest assured that ASP .NET Core has already solved this problem for you in its built-in templates. Let’s take a look at the shared Layout page, e.g. _Layout.cshtml in a Razor Pages web application.

Right away, you’ll notice that there are two conditional blocks in the above markup. The first block is used only during development, in which the bootstrap CSS file is obtained from your local copy. When not in development (e.g. staging, production, etc), the bootstrap CSS file is obtained from a CDN, e.g. CloudFlare.

You could use an automated hash-generation tool to generate the SRI (Subresource Integrity) hash values, but you would have to manually copy the value into your code. You can try out the relatively-new LibMan (aka Library Manager) for easily adding and updating your client-side libraries.

LibMan (aka Library Manager)

The easiest way to use LibMan is to use the built-in features available in Visual Studio. Using LibMan using the IDE is as easy as launching it from Solution Explorer. Specify the provider from the library you want, and any specific files you want from that library.

If you’ve already read my SignalR article from my 2018 blog series, you may recall the steps to add a client library via LibMan (aka Library Manager):

  • Right-click project in Solution Explorer
  • Select Add | Client-Side Library

In the popup that appears, select/enter the following:

  • Provider: choose from cdnjs, filesystem, unpkg
  • Library search term, e.g. @aspnet/signalr@1… pick latest stable if desired
  • Files: At a minimum, choose specific files, e.g. signalr.js and/or its minified equivalent

For more on LibMan (using VS or CLI), check out the official docs:

In any case, using LibMan will auto-populate a “libman.json” manifest file, which you can also inspect and edit manually. The aforementioned SignalR article also includes a real-time polling web app sample. You can view its libman.json file to observe its syntax for using a SignalR client library.

Every time you save the libman.json file, it will trigger LibMan’s restore process. This pulls down the necessary libraries from their specified source, and adds them to your local file system. If you want to trigger this restore process manually, you can always choose the “Restore Client-Side Libraries” option by right-clicking the libman.json file in Solution Explorer.

What About NPM or WebPack?

If you’ve gotten this far, you may be wondering: “hey, what about NPM or WebPack?”

It’s good to be aware that LibMan is a not a replacement for your existing package management systems. In fact, the Single-Page Application templates in Visual Studio (for Angular and React) currently use npm and WebPack. LibMan simply provides a lightweight mechanism to include client-side libraries from external locations.

For more information on WebPack in ASP .NET Core, I would recommend these 3rd-party articles:

References

  • Static files in ASP.NET Core: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/static-files
  • ASP.NET Core Middleware: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/
  • Library Manager (LibMan): https://devblogs.microsoft.com/aspnet/library-manager-client-side-content-manager-for-web-apps/
  • Use LibMan with ASP.NET Core in Visual Studio: https://docs.microsoft.com/en-us/aspnet/core/client-side/libman/libman-vs
  • Get started with ASP.NET Core SignalR: https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr
  • Environment Tag Helper in ASP.NET Core: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/tag-helpers/built-in/environment-tag-helper
  • Securing the CDN links in the ASP.NET Core 2.1 templates: https://damienbod.com/2018/03/14/securing-the-cdn-links-in-the-asp-net-core-2-1-templates/
  • Pre-compressed static files with ASP.NET Core: https://gunnarpeipman.com/aspnet/pre-compressed-files/

Additional reference for pre-compressing static files, found on Twitter via:

Что выбрать: ASP.NET или PHP

ASP.NET и PHP — две самые популярные технологии среди backend-разработчиков. Разбираем, чем они отличаются и какую лучше выбрать новичку.

Несмотря на то что на PHP написано 79% всех сайтов в интернете, есть и другие технологии, которые хорошо подходят для написания серверной части веб-приложений: Python, Java, Ruby, Node.JS.

В этой статье мы разобрали отличия PHP и его основного конкурента — ASP.NET, доля которого среди сайтов составляет 11,2%.

Пишет о разработке сайтов, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Чем отличаются
PHP и ASP.NET

PHP — это скриптовый интерпретируемый язык, созданный специально для разработки серверной части сайтов. На нём написаны такие сайты, как:

  • Facebook;
  • VK.com;
  • WordPress (и все сайты, созданные на нём);
  • YouTube;
  • Wikipedia и очень многое другое.

ASP.NET — это фреймворк для языков из семейства .NET (чаще всего C# или Visual Basic), который позволяет писать серверную часть сайтов. С его помощью созданы такие площадки, как:

  • Exchanger.com;
  • MSN.com;
  • Microsoft.com;
  • Dell.com;
  • Stackoverflow.com и другие.

Вот основные отличия этих технологий:

PHPASP.NET
Способ выполненияИнтерпретируется. При каждом обращении к скрипту он запускается, а после выполнения — закрывается. Поэтому на небольших проектах можно обойтись без сборки мусора.Компилируется. Сайт представляет собой приложение, которое создаёт новый поток при каждом обращении. Есть встроенная сборка мусора.

Простота изученияНизкий порог входа. Новичок сможет написать первый сайт на PHP за один день. (Конечно, если он уже знает HTML и CSS.)Высокий порог входа. Перед изучением самого ASP.NET нужно освоить какой-нибудь язык из семейства .NET.Объём кодаКомпактный.
На PHP можно быстро написать какой-нибудь блог, используя минимум кода.Чуть менее компактный.
Даже для простого вывода надписи «Hello, World!» требуется создать отдельный класс и запустить анонимный асинхронный метод. Несмотря на это, многие задачи можно выполнить с помощью лаконичного кода.Размер проектовПредпочтителен для небольших проектов. Поддержка кода на PHP сложнее, потому что в нём реже используется ООП и нет типизации (пока), а также сложно проводить отладку.Подходит для больших проектов. Небольшой сайт на ASP.NET уступает в скорости аналогичному на PHP. Однако он почти не проседает при большой нагрузке.
ТипизацияВ планахЕсть
Популярность и сообществоПопулярный.
Большое сообщество разработчиков, множество тем на форумах и Stack Overflow.
Менее популярный. Сообщество значительно меньше, чем у PHP, но это компенсируется большим количеством книг и очень подробной документацией.
ЗарплатыХорошие зарплаты на фрилансе и в столицах.
В регионах дела обстоят чуть хуже.
Зарплаты чуть выше. Это связано с более высокой квалификацией, поэтому PHP-разработчик с аналогичными навыками может зарабатывать не меньше.
РазвитиеБыстро развивается и меняется.
В новых версиях PHP планируют добавить типизацию, также постоянно появляются какие-то изменения, которые делают PHP лучше от версии к версии. Поэтому уже нельзя сказать, что PHP — это нестабильный и уязвимый язык для новичков.
Быстро развивается, но следует плану. Microsoft прислушивается к сообществу по поводу того, какие изменения вносить в язык. Но всё же компания не отходит от определённого пути. То есть ASP.NET-разработчик может быть уверен, что, проснувшись завтра, не обнаружит любимый фреймворк для создания сайтов изменившимся до неузнаваемости.
КоллекцииТолько массивы.
В PHP в качестве коллекций можно использовать только массивы, но они совмещают в себе особенности всех других коллекций. Например, можно указать строку в качестве ключа (аналог Dictionary в C#) или добавлять и удалять любые ячейки (аналог List). Это удобно для новичков, но усложняет поддержку и чтение кода.
Множество разных коллекций.
В C# и Visual Basic очень широкие возможности по работе с коллекциями: списки, очереди, словари, карты и так далее. Работа с ними становится ещё более мощной благодаря обобщённым коллекциям.
Асинхронность и многопоточностьМногопоточность не нужна.
Так как PHP запускает отдельный экземпляр скрипта при каждом обращении к нему, многопоточность и асинхронность особо не нужны — всё и так отлично работает.
Широкие возможности.
Языки семейства .NET позволяют эффективно работать с несколькими потоками и выполнять одновременно различные задачи. Например, при каждом обращении к сайту создаётся асинхронный поток.
РазмещениеМного дешёвых серверов.
Это связано с популярностью PHP. Практически все хостинги предоставляют возможность использовать PHP-скрипты без дополнительной настройки — просто загрузите ваш сайт, и он заработает.
Серверы подороже. ASP.NET менее популярен, поэтому и хостингов значительно меньше, а стоят они дороже.

Отдельно стоит сказать, что оба языка активно развиваются, поэтому некоторые различия перестанут быть актуальными уже в скором времени. Например, в PHP собираются ввести типизацию, а всё семейство .NET переходит в open source с поддержкой кроссплатформенности. Поэтому PHP может стать сложнее, а ASP.NET — популярнее и доступнее.

Также стоит отметить значительные различия в синтаксисе. Например, вот как в PHP выводится текст:

Ссылка на основную публикацию
Adblock
detector