Maybe it is just another pun, but wouldn't hurt to check out


Since ChatGPT was released, "Prompt engineering" is a hot topic these days. It can be a complex subject if you delve deep into it, and for some, it may sound like a pun, but I believe that it is obviously useful so no reason to hate it either. Here are some useful tips that I have summarised briefly.



Detailed context improves its responses. It is recommended to provide context information at the beginning of the conversation or after receiving a response to obtain the desired information.

 
ChatGPT can only remember up to 4096 tokens, so it is important to keep questions concise. You can use translation tools like Google Translate or Papago to translate your questions and answers.

 
You can assign roles to ChatGPT to get different answers. "act as" keywords allow you to give roles to ChatGPT, such as marketing experts, senior developers, and successful CEOs. Also you can assign your role as well. For example, you as a front-end engineer with 4 years of experience.


 🙂 https://github.com/f/awesome-chatgpt-prompts


Some parameters can actually change the response result that ChatGPT generates. Explanations were generated by ChatGPT, so if it is wrong blame him/her : -)

 A parameter that limits the selection of words to the top k most likely candidates at each step, leading to more coherent but potentially repetitive text. In front-end development, this could be used to generate pre-defined responses for a chatbot, limiting the number of possible responses to a few relevant ones.

: A parameter that controls the level of randomness in the output, balancing creativity and coherence. In front-end development, this could be used to generate product recommendations for an e-commerce website, allowing for some randomization while still ensuring the recommendations are relevant.

: A parameter that determines the maximum length of the generated text, preventing excessively long outputs. In front-end development, this could be used to generate summaries of articles or reviews, limiting the length of the summary to a specific number of characters.

: A parameter that controls the diversity of the output by encouraging the model to generate more diverse responses. In front-end development, this could be used to generate alternative product recommendations for users who have already seen a similar product, ensuring a wider range of options.

: A parameter that controls the number of candidate sequences the model considers at each step, allowing for faster generation with some sacrifice in quality. For example, in front-end development, this could be used to generate auto-completion suggestions for a search bar, limiting the number of suggestions to a few of the most likely ones.


Prompt driven engineering

Server-side rendering(SSR) can't be the silver bullet

Server-side rendering definitely has many advantages. However, it should be used carefully as there are pros and cons depending on the situation, and there are also frequent cases where CSR is better in terms of development cost or performance. In this post, I will briefly compare and summarise SSR and CSR, and then discuss whether server-side rendering really brings fast loading or not.


SSR is a technique where web pages are generated on the server and sent to t. To be clear, SSR is what web used to be. Web pages used to be always populated from server side until client-side rendering(CSR) become a trend. 

This means that the initial render of the page is done on the server, rather than in the client's browser.

 SSR can improve SEO, page load times, and the user experience on slower devices or networks. However, it can be more complex to set up and maintain compared to client-side rendering (CSR), and may not be necessary or beneficial for all types of web applications.

Yes, clearly one of SSR's advantages is performance. But really? Let's compare SSR and CSR first.

Serverside rendering vs client side rendering

Generates HTML on the server and sends it to the client

Provides a better user experience on slower devices or networks

Can be more complex to set up and maintain

Generates HTML in the client's browser using JavaScript

Provides a faster and more interactive experience after the initial load

Simplifies the development process and enables faster iteration

May not be as SEO-friendly or performant on slower devices or networks

I can agree the above mentioned features except the performance part.

CSR was initially introduced for better user experience including performance. With CSR + Single Page Application (SPA) users can use web like application and this combination is improving every day. Once JS bundles  are cached on client side, it will just send ajax request to server to retrieve required data only. This will reduce the workload on the server-side as well, which means with the same resource (same computing power) CSR should be faster as it uses client side resources.

Then 

 millions of people say SSR is faster? Actually it can 

 faster because when the contents are loaded, it will show completed page at one once, compared to CSR that loads contents later with following ajax requests. Hence from the user perspective, they may 

 SSR is faster. 

However that doesn't really mean SSR is faster than CSR, especially when there are a lot of requests, serving SSR pages can be a huge issue compared to CSR served by CDN.

Having said that, SSR can be still faster if you have enough server resources.

So, basically SSR may appear to have significant drawbacks that could slow down loading times, but it can still be faster due to reduced requests and round trip times. For example CSR apps will normally follow these steps below to show contents.


Client requests JS bundle files to server

After that, client evaluates javascript and start application

These steps can be different depending on the application's architecture. But the main point is every request incurs a delay.


On the other hand, SSR has a lot fewer steps as below

Front end server receive the request and send API call to API server

Front-end server populate. Physically close.


Considering the close proximity of front-end server and API server, each request time itself will be even shorter.


Hang on, what about the server cost then? Yes, that is something we might have to flexibly decide depending on the situations. SSR 

faster if you have additional settings like auto scaling or some strategy to handle the requests


It is worth noting that SSR doesn't have to render all content. For instance, modals or other content that users don't need to see initially don't require SSR. Rendering all content via SSR can significantly increase loading times. 


To conclude, SSR is not always the answer. Modern search engines can retrieve information from CSR pages effectively, making SSR less important for small projects or SaaS applications, and proper SSR comes with increased development time and extra server costs. But again, it is true that SSR can increase the performance itself. So, yes. SSR is faster than CSR : )

Is server-side rendering really faster?

Will ChatGPT will replace developers shortly?

Kyle Simpson, the author of "You don't know Javascript" said

Here's my theory (I mean it sincerely, not as an insult or sarcasm):

If you think your job as a software developer could/will be taken by an AI, then you're 

 the kind of software developer whose job could be taken by an AI.

If you think your job as a software developer will NEVER be taken by an AI, then you're 

 the kind of software developer whose job could be taken by an AI.

If you think your job as a software developer will likely have to change as a result of AI, then you're probably secure in your job as a software developer.

I completely agree with this post. To me, it seems to be more about attitude and perspective than knowledge, skills, or talent. When the automobile was invented, carriage drivers had to learn how to drive, rather than ignore the changes.

With the development of web frameworks and ecosystems, things seem to be getting more complicated, even though many of these inventions were created to make developers' lives better. Modern web developers may not need to deal with memory management or vanilla DOM, but they now have to deal with multiple layers of solutions.

AI will make many of our previous processes redundant, but it will also bring new opportunities. We simply need to adjust and learn how to move forward with AI.

Will ChatGPT replace developers?

 with my current workplace, I occasionally crave the freedom to experiment with new technologies without the risk of adverse consequences. Also, I tend to focus too heavily on the application's business logic lately.


So, I decided to make a tech blog from scratch to experiment with new web technologies and share my thoughts on them.

Although numerous subjects are there, I plan to address the following topics initially :

Starting my blog : - )

Exercitation aliqua dolor ea dolore pariatur consectetur nostrud exercitation elit id mollit ullamco id. Non anim non eu mollit. Elit aliquip dolore duis occaecat. Cillum non amet amet tempor reprehenderit mollit nostrud anim reprehenderit dolor quis tempor ad.

Image test

Exercitation aliqua dolor ea dolore pariatur consectetur nostrud exercitation elit id mollit ullamco id. Non anim non eu mollit. Elit aliquip dolore duis occaecat. Cillum non amet amet tempor reprehenderit mollit nostrud anim reprehenderit dolor quis tempor ad.


Is server-side rendering really faster?

Starting my blog : - )

Prompt driven engineering

Will ChatGPT replace developers?

Image test

Font test

Upload test

Slug test page

Category test page