Is the single page application the new normal? - Headspring
What is a single page application and do you need one? We take a look at how this approach to building a web app can enhance your user experience.
headspring.com
Is the single page application the new normal?
Single Page application 은 새로운 평범함인가?
My grandmother sent me a friend request on Facebook recently. She couldn’t even connect to the internet five years ago. As social media and email become more mainstream, the more widespread the expectation for a higher level of functionality, speed, and aesthetic appeal in our digital interactions. If you’re not considering these when building a web app, you’ll end up with a product that no one wants to use.
나의 할머니는 최근에 나에게 페이스북 친구요청을 보냈다. 그녀는 5년전에는 인터넷에 접속조차도 할 수 없었다.소셜미디어 그리고 이메일은 점점더 주류가 되어갈수록, 디지털미디어의 상호관계에서 높은수준의 기능성과 속도, 미적인 아름다움에 광범위한 기대를 한다 ( 이 부분은 번역이 좀 맞는지 모르겠당 ㅎ )만일 너가 웹앱을 만들때, 이러한 것들을 고려하지 않는다면, 너는 결국에 아무도 사용하길 원하지 않는 앱을 만들게 될것이다.
Developers and software consultants are turning to single page applications (SPAs) to meet the rising expectations of consumers and users of internal apps. A single page application is heavily reliant on JavaScript and does not require full page reloads while the user is interacting with the application. Instead, a single page is modified dynamically with each user request, providing a much more performant experience throughout the user journey. Gmail, Google Maps, Facebook, and Asana are examples of single page application options that have popularized this “snappier” user experience. For companies that want to stay engaged with their users and easily onboard new ones, a SPA may be a good option, but they’re not a silver bullet or suited to every team. Here’s what you need to know about single-page applications and what they take to build before you start developing.
개발자와 소프트웨어 컨설턴트들은 고객들과 내부 앱 사용자의 기대의 향상을 충족시키기 위해 SPA로 바꾸고 있다.
SPA는 무섭게 javascript 에 의존하고 있다. 그리고 SPA는 유저가 앱을 사용하는 동안에 전체 page의 reload를 요구하지 않는다.
대신에 단일 페이지는 유저의 요구사항에 동적으로 수정되어지고, 더 향상된 유저경험을 제공한다.Gmail Google Map, FaceBook, Asana 는 이러한 Snappier의 사용자 경험을 대중화한 SPA의 예다.
그들의 유저에게 관계를 유지하고, 새로운 유저에게 쉽게 참여하기 위해서 SPA는 좋은 대안일지도 모른다.하지만, SPA는 은색탄환이나, 모든 팀에게 있어서 적합한 것은 아니다.여기 SPA에 대해서 알아야할 것들과 개발하기 전에 익혀야할것들?이 있다?
Understanding single page applications
One of the best ways to understand SPA architecture is to compare it to multi-page applications, which were the standard until about five years ago. In a traditional application, when a user navigates to a new page or performs an action (such as submitting a form), the browser makes a request to the back end. The back end responds with the HTML, CSS, JavaScript, and relevant data, which is then rendered in the browser. In this case, the back end does the heavy lifting and the client simply renders what is provided. The back end has to provide the same code for static elements like the navigation bar every time a page is loaded, which could be considered wasteful.
In a single page application, the front-end code is only loaded once throughout the user session. All requests from the client following the initial page load are fulfilled through smaller, more targeted API calls to the back end, with only relevant data being returned in the responses.
SPA의 이해
SPA 아키텍쳐를 이해하기 위해 가장 좋은 방법중 하나는 multi-page 앱과 비교하는 것이다. multi-page 앱은 약 5년전까지만 해도 표준이었다.
전통적인 앱에서 사용자는 새로운페이지를 탐험할때, 혹은 어떤 액션을 취할때, 브라우저는 백엔드에 요청을 했다.
백엔드는 html, css, js, 관련된 data 를 응답했고, 그것은 브라우저에서 렌더링되었다.
이러한 경우에 백엔드는 무겁게 수행했고, 클라이언트는 제공된 것은 단순하게 렌더링했다.
백엔드는 모든 페이지에서 로드되어야하는 네비게이션바와 같은 정적인 코드조차도 제공해야만 했다. 그것은 낭비처럼 고려될수 있다.
SPA에서 프론트는 항상 유저의 세션전체에서 오직 한번 로드된다.
All Requests ~ the responses 까지의 해석이 뭔가 모르겠다.
초기 page 로드에 뒤에오는 클라이언트의 모든 요청은 작고 타겟된 API를 호출하고 수행된다. 백엔드로
오직 관련된 데이터만 응답한다.
Benefits of building a single page application
The biggest benefit of building a web app as a single page application is improved performance for users. Since the front-end code is loaded only once, subsequent requests within the application are fulfilled faster because there is less information being transmitted and also less that needs to be re-rendered in the browser. You can opt to display a spinner while data is being fetched, so the user knows that their request is processing. Nielsen/Norman Group has studied the UX benefit of progress indicators in cases like this. They cite a study in which users who were shown an animated loop during a page load were willing to wait on average 3 times longer than those who did not see any progress indicators.
SPA를 만드는 것의 이점
SPA로 앱을 만드는 가장큰 이점은 유저의 수행을 향상시키는 것이다.
프론트엔트 코드가 오직 한번 로드된 이후로, 앱안에서의 뒤따르는 요청들은 빠르게 수행한다 왜냐하면,더 적은 정보의 이동만이 있어서 그리고 브라우저에서 리렌더링하기 위해서 필요한것들이 적어서.
너는 데이터가 패치되는 동안에 스피너를 표시할수 있는 옵션을 선택할수 있다. 그래서 유저는 그들의 요구가 처리중인것을 알수 있다.
Nielsen/Norman 그룹은 이러한 경우에 처리표시에 대한 ux 이점에 대해 연구 하고 있다.
그들은 페이지 로드되는 동안에 반복되는 애니메이트를 보여주는 사이트의 유저가 그렇지 않은 사이트에 비해 3배나 기꺼이 기다릴수 있다는 연구를 인용했다?
Opting to build a single-page application can also benefit your development pipeline. Work can be split between front-end and back end developers, ideally speeding up the process. The front-end developers are focused on building a beautiful user experience, while the back end developers are focused on the data model and building efficient APIs. While this approach to building a web app can definitely speed up the timeline, it requires a high level of focus and collaboration between both teams. The back-end teams need to provide clear API contracts and documentation so that the front-end team knows exactly which APIs to call and what data will be provided. The front-end team needs to be involved in the API design to provide input on what makes the most sense based on the application flow. Without this collaboration, the need for re-work might be introduced that could reduce the benefits of parallel front-end and back-end development.
With the right planning, the same APIs that are built for the web app can also be re-used for a mobile application This allows you to get to market faster with a mobile offering because developers can be off and running quickly with the right API documentation in hand.
SPA를 개발하는 선택은 너의 개발 파이프라인에 이점이 될수 있다? 일은 프론트와 백엔드로 분리되어질 수 있고,
처리속도는 이상적으로 올라갈것이다.
프론트엔드 개발자는 유저의 아름다운 경험에 초점을 마추고, 백엔드 개발자는 데이터모델과 효과적인 API를 만드는 것에 초점을 맞춘다.
이러한 웹 개발접근은 이상적으로 타임라인을 끌어올릴수 있지만, 두팀사이에 높은 수준의 집중과 협업을 요구한다.
백엔드팀은 명확한 API 접근과 문서를 만들어야하며, 프론트엔드팀이 명확하게 API 호출과 데이터의 제공되는 것을 명확하게 알기 위해서
프론트엔드팀은 앱의 흐름에 맞는 가장 합리적인 API 설계를 만들기 위해 참여해야만한다.
이러한 협업 없다면, 프론트엔드팀과 백엔드 팀의 병력작업의 이점을 줄일수 있는 재작업이 필요성이 생길지도 모른다.
올바른 계획대로가면, 웹앱을 위한 API는 모바일 앱에서도 재사용될수 있다. 이것은 너에게 개발자가 빠르고 올바른 API 문서로 ?작업할수 있어서 마켓에 빠르게 진입할수 잇게 해준다?
Downsides of building a single page application
The biggest concern that most people have with the single page application is that they aren’t as SEO-friendly. Search engine crawlers were designed for multi-page applications, so SPAs are less likely to show up in search results without additional work. So, you probably should not attempt to build pages with high marketing value as SPAs. This landscape is improving and there are tools like static site generators that help with SEO, but it’s still a primary consideration.
Another concern is that the initial page load can take longer for SPAs, since it requires ALL of the HTML, CSS, and JavaScript needed for the entire app. However, since subsequent page loads are faster with SPAs, this is not a major obstruction to the overall user experience.
It’s also important to consider your development teams’ expertise and capacity. SPAs require specialized front-end knowledge to build and maintain them efficiently. They can also be harder to debug because they require the use of browser-based development tools as opposed to IDEs. Additionally, the state needs to be maintained between the SPA and the RESTful API.
SPA 개발의 단점
대부분의 사람들이 가지고 있는 SPA 가장큰 걱정은 SPA가 SEO에 진숙하지 않다는 점이다.
검색엔진크롤러는 멀티페이지 앱을 위해서 디자인 되었다. 그래서 SPA는 추가적인 작업 없이는 검색결과를 덜 보여주게된다. 그래서 너는 아마도 SPA로서 높은 마켓팅 value를 가지고 있는 페이지를 만드는것을 시도해선 안된다.
이러한 환경은 향상되고 있고, SEO를 도와주는 static site generator 와 같은 툴이 있지만, 이것은 여전히 주된 고려사항이다.
전체 앱을 구성하기 위한 모든 HTML CSS js 를 요구하기때문에 SPA의 초기 로드는 오래걸릴수 있다는 다른 걱정이 있다. 그러나, 이후의 page 로드는 SPA가 빠르기 때문에 유저 경험을 위한 전반적인 장애요소는 아니다.
이것은 당신의 개발팀의 전문지식과 역량을 고려해야하는 것은 중요하다 SPA는 앱을 효과적으로 유지하고 만드는데 특별한 지식이 요구되고, 그들은 디버깅하는데 어려울수 있다 왜냐하면, IDE와 반대되는 브라우저 기반의 툴로서 사용해야하기 때문이다. 추가적으로 SPA와 API사이에 유지는 중요하다.
Tools and frameworks for building SPAs
With the rising popularity of the single page application, there has been a parallel rise in the popularity of JavaScript frameworks that support their development. The two most popular frameworks are React (Facebook) and Angular (Google), but there are plenty of alternatives that should also be considered, such as Vue.js and Ember.
My advice when choosing a JavaScript framework is to first understand your organization’s technical landscape, then the needs and use cases for the application you’re building. It can take some time for developers to become efficient at working with different frameworks. If your organization has already invested training on one framework, it probably makes sense to choose that one for your next application.
SPA 만들기 위한 프레임워크와 툴
SPA 인기의 상승과 함께 그들의 개발을 지원해주는 자바스크립트의 인기또한 병렬적으로 같이 증가했다. 2가지 인기있는 프레임워크는 리액트와 앵귤러이지만, 뷰나 앰버와같은 고려할만안 대안의 것들도 있다.
자바스크립트 프레임워크를 선택함에 있어 나의 충고는 첫번째로 너의 조직의 기술적환경의 이해이다. 그런다음에 너가 만들고다하는 앱을 위해 필요하고 사용한다?
개발자가 다른 프레임워크에서 효과적으로 일하게 되는것은 조금의 시간이 걸릴수 있다.
만일 너의 조직이 하나의 프레임워크에 교육에 이미 투가하고 있다면, 이것은 아마 너의 다음앱의 선택하는데 이점이 될것이다?
The value of a better experience
If you’re building a web app, consider the benefits of implementing it with a modern front end. Creating the best possible experience for consumer-facing applications is a near-imperative due to rising public expectations. However, a modern web app architecture will also help you derive greater value from internal applications: A better user interface makes people more efficient and can drive overall business.
I hope this post has shed some light on the rise and popularity of the single page application, and why it might make sense to build your next application with a JavaScript framework. So how do you start? Look out for a follow-up post that dives into the technical details of developing a successful single page application.
거 좋은 경험의 가치
만일 너가 웹 앱을 만들고 있다면, 근대 프론트 엔드와 이것을 수행하는 이점을 고려해라?
고객이 마주하고 있는 앱에서의 가능한 최고의 경험을 만드는것은 공통의 기대의 향상에 필요한것이다?
그러나, 근대 앱의 구조는 내부앱으로부터 좋은 가치를 ? 끌어내는데 도움이 된다?
좋은 유저 인터페이스는 사람을 효과적으로 만들고 더나은 비지니스로 끌어낸다?
나는 이 포스트가 SPA의 인기의 향상에 조금의 빛이 되길 희망한다?
그리고 자바스크립트앱의 도움이 되길 바라는 이유이다?
어떻게 시작할까
봐라 다음 테크포스트?
'영어공부' 카테고리의 다른 글
| Spring Boot with OSGi (0) | 2022.10.24 |
|---|---|
| JAVA vs NODE (0) | 2022.06.27 |
| Guide to Java Versions and Features (0) | 2022.01.08 |
| JavaScript Data Types (0) | 2020.02.12 |
| JavaScript Variables (0) | 2020.02.12 |
Is the single page application the new normal? - Headspring
What is a single page application and do you need one? We take a look at how this approach to building a web app can enhance your user experience.
headspring.com
Is the single page application the new normal?
Single Page application 은 새로운 평범함인가?
My grandmother sent me a friend request on Facebook recently. She couldn’t even connect to the internet five years ago. As social media and email become more mainstream, the more widespread the expectation for a higher level of functionality, speed, and aesthetic appeal in our digital interactions. If you’re not considering these when building a web app, you’ll end up with a product that no one wants to use.
나의 할머니는 최근에 나에게 페이스북 친구요청을 보냈다. 그녀는 5년전에는 인터넷에 접속조차도 할 수 없었다.소셜미디어 그리고 이메일은 점점더 주류가 되어갈수록, 디지털미디어의 상호관계에서 높은수준의 기능성과 속도, 미적인 아름다움에 광범위한 기대를 한다 ( 이 부분은 번역이 좀 맞는지 모르겠당 ㅎ )만일 너가 웹앱을 만들때, 이러한 것들을 고려하지 않는다면, 너는 결국에 아무도 사용하길 원하지 않는 앱을 만들게 될것이다.
Developers and software consultants are turning to single page applications (SPAs) to meet the rising expectations of consumers and users of internal apps. A single page application is heavily reliant on JavaScript and does not require full page reloads while the user is interacting with the application. Instead, a single page is modified dynamically with each user request, providing a much more performant experience throughout the user journey. Gmail, Google Maps, Facebook, and Asana are examples of single page application options that have popularized this “snappier” user experience. For companies that want to stay engaged with their users and easily onboard new ones, a SPA may be a good option, but they’re not a silver bullet or suited to every team. Here’s what you need to know about single-page applications and what they take to build before you start developing.
개발자와 소프트웨어 컨설턴트들은 고객들과 내부 앱 사용자의 기대의 향상을 충족시키기 위해 SPA로 바꾸고 있다.
SPA는 무섭게 javascript 에 의존하고 있다. 그리고 SPA는 유저가 앱을 사용하는 동안에 전체 page의 reload를 요구하지 않는다.
대신에 단일 페이지는 유저의 요구사항에 동적으로 수정되어지고, 더 향상된 유저경험을 제공한다.Gmail Google Map, FaceBook, Asana 는 이러한 Snappier의 사용자 경험을 대중화한 SPA의 예다.
그들의 유저에게 관계를 유지하고, 새로운 유저에게 쉽게 참여하기 위해서 SPA는 좋은 대안일지도 모른다.하지만, SPA는 은색탄환이나, 모든 팀에게 있어서 적합한 것은 아니다.여기 SPA에 대해서 알아야할 것들과 개발하기 전에 익혀야할것들?이 있다?
Understanding single page applications
One of the best ways to understand SPA architecture is to compare it to multi-page applications, which were the standard until about five years ago. In a traditional application, when a user navigates to a new page or performs an action (such as submitting a form), the browser makes a request to the back end. The back end responds with the HTML, CSS, JavaScript, and relevant data, which is then rendered in the browser. In this case, the back end does the heavy lifting and the client simply renders what is provided. The back end has to provide the same code for static elements like the navigation bar every time a page is loaded, which could be considered wasteful.
In a single page application, the front-end code is only loaded once throughout the user session. All requests from the client following the initial page load are fulfilled through smaller, more targeted API calls to the back end, with only relevant data being returned in the responses.
SPA의 이해
SPA 아키텍쳐를 이해하기 위해 가장 좋은 방법중 하나는 multi-page 앱과 비교하는 것이다. multi-page 앱은 약 5년전까지만 해도 표준이었다.
전통적인 앱에서 사용자는 새로운페이지를 탐험할때, 혹은 어떤 액션을 취할때, 브라우저는 백엔드에 요청을 했다.
백엔드는 html, css, js, 관련된 data 를 응답했고, 그것은 브라우저에서 렌더링되었다.
이러한 경우에 백엔드는 무겁게 수행했고, 클라이언트는 제공된 것은 단순하게 렌더링했다.
백엔드는 모든 페이지에서 로드되어야하는 네비게이션바와 같은 정적인 코드조차도 제공해야만 했다. 그것은 낭비처럼 고려될수 있다.
SPA에서 프론트는 항상 유저의 세션전체에서 오직 한번 로드된다.
All Requests ~ the responses 까지의 해석이 뭔가 모르겠다.
초기 page 로드에 뒤에오는 클라이언트의 모든 요청은 작고 타겟된 API를 호출하고 수행된다. 백엔드로
오직 관련된 데이터만 응답한다.
Benefits of building a single page application
The biggest benefit of building a web app as a single page application is improved performance for users. Since the front-end code is loaded only once, subsequent requests within the application are fulfilled faster because there is less information being transmitted and also less that needs to be re-rendered in the browser. You can opt to display a spinner while data is being fetched, so the user knows that their request is processing. Nielsen/Norman Group has studied the UX benefit of progress indicators in cases like this. They cite a study in which users who were shown an animated loop during a page load were willing to wait on average 3 times longer than those who did not see any progress indicators.
SPA를 만드는 것의 이점
SPA로 앱을 만드는 가장큰 이점은 유저의 수행을 향상시키는 것이다.
프론트엔트 코드가 오직 한번 로드된 이후로, 앱안에서의 뒤따르는 요청들은 빠르게 수행한다 왜냐하면,더 적은 정보의 이동만이 있어서 그리고 브라우저에서 리렌더링하기 위해서 필요한것들이 적어서.
너는 데이터가 패치되는 동안에 스피너를 표시할수 있는 옵션을 선택할수 있다. 그래서 유저는 그들의 요구가 처리중인것을 알수 있다.
Nielsen/Norman 그룹은 이러한 경우에 처리표시에 대한 ux 이점에 대해 연구 하고 있다.
그들은 페이지 로드되는 동안에 반복되는 애니메이트를 보여주는 사이트의 유저가 그렇지 않은 사이트에 비해 3배나 기꺼이 기다릴수 있다는 연구를 인용했다?
Opting to build a single-page application can also benefit your development pipeline. Work can be split between front-end and back end developers, ideally speeding up the process. The front-end developers are focused on building a beautiful user experience, while the back end developers are focused on the data model and building efficient APIs. While this approach to building a web app can definitely speed up the timeline, it requires a high level of focus and collaboration between both teams. The back-end teams need to provide clear API contracts and documentation so that the front-end team knows exactly which APIs to call and what data will be provided. The front-end team needs to be involved in the API design to provide input on what makes the most sense based on the application flow. Without this collaboration, the need for re-work might be introduced that could reduce the benefits of parallel front-end and back-end development.
With the right planning, the same APIs that are built for the web app can also be re-used for a mobile application This allows you to get to market faster with a mobile offering because developers can be off and running quickly with the right API documentation in hand.
SPA를 개발하는 선택은 너의 개발 파이프라인에 이점이 될수 있다? 일은 프론트와 백엔드로 분리되어질 수 있고,
처리속도는 이상적으로 올라갈것이다.
프론트엔드 개발자는 유저의 아름다운 경험에 초점을 마추고, 백엔드 개발자는 데이터모델과 효과적인 API를 만드는 것에 초점을 맞춘다.
이러한 웹 개발접근은 이상적으로 타임라인을 끌어올릴수 있지만, 두팀사이에 높은 수준의 집중과 협업을 요구한다.
백엔드팀은 명확한 API 접근과 문서를 만들어야하며, 프론트엔드팀이 명확하게 API 호출과 데이터의 제공되는 것을 명확하게 알기 위해서
프론트엔드팀은 앱의 흐름에 맞는 가장 합리적인 API 설계를 만들기 위해 참여해야만한다.
이러한 협업 없다면, 프론트엔드팀과 백엔드 팀의 병력작업의 이점을 줄일수 있는 재작업이 필요성이 생길지도 모른다.
올바른 계획대로가면, 웹앱을 위한 API는 모바일 앱에서도 재사용될수 있다. 이것은 너에게 개발자가 빠르고 올바른 API 문서로 ?작업할수 있어서 마켓에 빠르게 진입할수 잇게 해준다?
Downsides of building a single page application
The biggest concern that most people have with the single page application is that they aren’t as SEO-friendly. Search engine crawlers were designed for multi-page applications, so SPAs are less likely to show up in search results without additional work. So, you probably should not attempt to build pages with high marketing value as SPAs. This landscape is improving and there are tools like static site generators that help with SEO, but it’s still a primary consideration.
Another concern is that the initial page load can take longer for SPAs, since it requires ALL of the HTML, CSS, and JavaScript needed for the entire app. However, since subsequent page loads are faster with SPAs, this is not a major obstruction to the overall user experience.
It’s also important to consider your development teams’ expertise and capacity. SPAs require specialized front-end knowledge to build and maintain them efficiently. They can also be harder to debug because they require the use of browser-based development tools as opposed to IDEs. Additionally, the state needs to be maintained between the SPA and the RESTful API.
SPA 개발의 단점
대부분의 사람들이 가지고 있는 SPA 가장큰 걱정은 SPA가 SEO에 진숙하지 않다는 점이다.
검색엔진크롤러는 멀티페이지 앱을 위해서 디자인 되었다. 그래서 SPA는 추가적인 작업 없이는 검색결과를 덜 보여주게된다. 그래서 너는 아마도 SPA로서 높은 마켓팅 value를 가지고 있는 페이지를 만드는것을 시도해선 안된다.
이러한 환경은 향상되고 있고, SEO를 도와주는 static site generator 와 같은 툴이 있지만, 이것은 여전히 주된 고려사항이다.
전체 앱을 구성하기 위한 모든 HTML CSS js 를 요구하기때문에 SPA의 초기 로드는 오래걸릴수 있다는 다른 걱정이 있다. 그러나, 이후의 page 로드는 SPA가 빠르기 때문에 유저 경험을 위한 전반적인 장애요소는 아니다.
이것은 당신의 개발팀의 전문지식과 역량을 고려해야하는 것은 중요하다 SPA는 앱을 효과적으로 유지하고 만드는데 특별한 지식이 요구되고, 그들은 디버깅하는데 어려울수 있다 왜냐하면, IDE와 반대되는 브라우저 기반의 툴로서 사용해야하기 때문이다. 추가적으로 SPA와 API사이에 유지는 중요하다.
Tools and frameworks for building SPAs
With the rising popularity of the single page application, there has been a parallel rise in the popularity of JavaScript frameworks that support their development. The two most popular frameworks are React (Facebook) and Angular (Google), but there are plenty of alternatives that should also be considered, such as Vue.js and Ember.
My advice when choosing a JavaScript framework is to first understand your organization’s technical landscape, then the needs and use cases for the application you’re building. It can take some time for developers to become efficient at working with different frameworks. If your organization has already invested training on one framework, it probably makes sense to choose that one for your next application.
SPA 만들기 위한 프레임워크와 툴
SPA 인기의 상승과 함께 그들의 개발을 지원해주는 자바스크립트의 인기또한 병렬적으로 같이 증가했다. 2가지 인기있는 프레임워크는 리액트와 앵귤러이지만, 뷰나 앰버와같은 고려할만안 대안의 것들도 있다.
자바스크립트 프레임워크를 선택함에 있어 나의 충고는 첫번째로 너의 조직의 기술적환경의 이해이다. 그런다음에 너가 만들고다하는 앱을 위해 필요하고 사용한다?
개발자가 다른 프레임워크에서 효과적으로 일하게 되는것은 조금의 시간이 걸릴수 있다.
만일 너의 조직이 하나의 프레임워크에 교육에 이미 투가하고 있다면, 이것은 아마 너의 다음앱의 선택하는데 이점이 될것이다?
The value of a better experience
If you’re building a web app, consider the benefits of implementing it with a modern front end. Creating the best possible experience for consumer-facing applications is a near-imperative due to rising public expectations. However, a modern web app architecture will also help you derive greater value from internal applications: A better user interface makes people more efficient and can drive overall business.
I hope this post has shed some light on the rise and popularity of the single page application, and why it might make sense to build your next application with a JavaScript framework. So how do you start? Look out for a follow-up post that dives into the technical details of developing a successful single page application.
거 좋은 경험의 가치
만일 너가 웹 앱을 만들고 있다면, 근대 프론트 엔드와 이것을 수행하는 이점을 고려해라?
고객이 마주하고 있는 앱에서의 가능한 최고의 경험을 만드는것은 공통의 기대의 향상에 필요한것이다?
그러나, 근대 앱의 구조는 내부앱으로부터 좋은 가치를 ? 끌어내는데 도움이 된다?
좋은 유저 인터페이스는 사람을 효과적으로 만들고 더나은 비지니스로 끌어낸다?
나는 이 포스트가 SPA의 인기의 향상에 조금의 빛이 되길 희망한다?
그리고 자바스크립트앱의 도움이 되길 바라는 이유이다?
어떻게 시작할까
봐라 다음 테크포스트?
'영어공부' 카테고리의 다른 글
| Spring Boot with OSGi (0) | 2022.10.24 |
|---|---|
| JAVA vs NODE (0) | 2022.06.27 |
| Guide to Java Versions and Features (0) | 2022.01.08 |
| JavaScript Data Types (0) | 2020.02.12 |
| JavaScript Variables (0) | 2020.02.12 |
