I always use Nuxt by default for new projects, and it's a correct decision every time. People who choose to do Client Side Rendering (SPA) finally struggling on SEO and other tasks. 1. Nuxt can runs in SPA mode just…
Why are people slapping Static Site Generators to all the problems? Imagine you build an e-commerce website that has ten thousands of products, that can be accessed by example.com/products/{product-slug}. Now what is…
When dealing with large tables with searching + sorting + paginating capabilities, I always use query params and let the API do the heavy lifting
And what is the best solution? Client Side Rendering is worse, because users see a blank page until the script is parsed. 100KB is actually desirable, because it's included Vue and Vuex out of the box.
All browser processes 100KB of scripts just fine. And they process the scripts in the background. The HTML is already parsed and displayed.
Nuxt works fine for all the uses case that I have come across, even for ERP projects. With Nuxt you can have real redirects, real 404 pages, and a well-established project structure. The only hard thing is that…
Phoenix too
No native support for concurrency operators, no real event loop implementation, lack built-in support for non-blocking IO... I do Elixir regularly and Actor Model is not something PHP developers know
Not at all. I have worked with both for a long time and I can clearly see the differences. They are used for different purposes. The people comparing any PHP frameworks to NextJS have not been very experienced with…
still, no proper multithreading, in comparison with Java, C#, Elixir...
no PHP framework is similar to the thing that NextJS/Reactis doing. The output is the same (well, isn’t the point of web framework is to spit out HTML?) but the methodology is totally different.
Please take a look at my CV. I'm a fullstack developer (Elixir, Node, PHP, React, Vue, Flutter...) https://www.dropbox.com/s/kqkm467cb9ay65f/Lam%20Huynh.pdf?dl...
+1 for Ecto, the most powerful ORM that I have seen so far (among PHP, Node, Ruby, Python and Elixir)
Exactly, I don't get why people are against it. All ORM allows you to write raw query and using ORM does not mean that you suck at SQL or vice versa.
SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
More plastic but it's easy to clean - recycle. At least more delivery = less traffic, less polution
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC. So in what way does if differ from traditional…
Use both. Many of the business logics are just as simple as query by id, filter/sort by a couple of columns. A smart ORM will handle fetching relationships without hitting N+1 problem For advanced queries, you can write…
At my PHP-shop company, most projects are limited to MySQL 5.7 (legacy reason, dependency reason, boss-likes-MySQL reason...). They are all handicapped by MySQL featureset, and can't update to 8 yet. If they had used…
Nesting is okay for one-level. However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the…
A portion of Vue projects are not single page app: it can be used on top of a server-rendered frameworks like Laravel, Rails. Even the document mentions using Vue by a script tag inside the HTML. This may contribute to…
Outside Angular, I have never heard about two way binding as a source of bug
If you mix server-side rendered apps with Vue, this is the most common way. Second method is to push the data to a window.__data.staffMemberOptions = "{{ foo }}" and use it in Vue.
I think OP does not mean that Vue is unstructured / non-disciplined. Vue does have a rigid structure and standard though, but it's pleasantly designed and doesn't get in your way. Maintenance has been a breeze for me.
Not at all, people moves between libraries of the same framework, they will likely refactor jQuery mess into a framework, but it's unlikely for a team to move from React to Vue or Angular (and vice versa).
I always use Nuxt by default for new projects, and it's a correct decision every time. People who choose to do Client Side Rendering (SPA) finally struggling on SEO and other tasks. 1. Nuxt can runs in SPA mode just…
Why are people slapping Static Site Generators to all the problems? Imagine you build an e-commerce website that has ten thousands of products, that can be accessed by example.com/products/{product-slug}. Now what is…
When dealing with large tables with searching + sorting + paginating capabilities, I always use query params and let the API do the heavy lifting
And what is the best solution? Client Side Rendering is worse, because users see a blank page until the script is parsed. 100KB is actually desirable, because it's included Vue and Vuex out of the box.
All browser processes 100KB of scripts just fine. And they process the scripts in the background. The HTML is already parsed and displayed.
Nuxt works fine for all the uses case that I have come across, even for ERP projects. With Nuxt you can have real redirects, real 404 pages, and a well-established project structure. The only hard thing is that…
Phoenix too
No native support for concurrency operators, no real event loop implementation, lack built-in support for non-blocking IO... I do Elixir regularly and Actor Model is not something PHP developers know
Not at all. I have worked with both for a long time and I can clearly see the differences. They are used for different purposes. The people comparing any PHP frameworks to NextJS have not been very experienced with…
still, no proper multithreading, in comparison with Java, C#, Elixir...
no PHP framework is similar to the thing that NextJS/Reactis doing. The output is the same (well, isn’t the point of web framework is to spit out HTML?) but the methodology is totally different.
Please take a look at my CV. I'm a fullstack developer (Elixir, Node, PHP, React, Vue, Flutter...) https://www.dropbox.com/s/kqkm467cb9ay65f/Lam%20Huynh.pdf?dl...
+1 for Ecto, the most powerful ORM that I have seen so far (among PHP, Node, Ruby, Python and Elixir)
Exactly, I don't get why people are against it. All ORM allows you to write raw query and using ORM does not mean that you suck at SQL or vice versa.
SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
More plastic but it's easy to clean - recycle. At least more delivery = less traffic, less polution
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC. So in what way does if differ from traditional…
Use both. Many of the business logics are just as simple as query by id, filter/sort by a couple of columns. A smart ORM will handle fetching relationships without hitting N+1 problem For advanced queries, you can write…
At my PHP-shop company, most projects are limited to MySQL 5.7 (legacy reason, dependency reason, boss-likes-MySQL reason...). They are all handicapped by MySQL featureset, and can't update to 8 yet. If they had used…
Nesting is okay for one-level. However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the…
A portion of Vue projects are not single page app: it can be used on top of a server-rendered frameworks like Laravel, Rails. Even the document mentions using Vue by a script tag inside the HTML. This may contribute to…
Outside Angular, I have never heard about two way binding as a source of bug
If you mix server-side rendered apps with Vue, this is the most common way. Second method is to push the data to a window.__data.staffMemberOptions = "{{ foo }}" and use it in Vue.
I think OP does not mean that Vue is unstructured / non-disciplined. Vue does have a rigid structure and standard though, but it's pleasantly designed and doesn't get in your way. Maintenance has been a breeze for me.
Not at all, people moves between libraries of the same framework, they will likely refactor jQuery mess into a framework, but it's unlikely for a team to move from React to Vue or Angular (and vice versa).