141–150 of 307 posts
Off topic: this is the best landing page I've ever seen on a mobile device. Keep scrolling down for some surprises!
I remember the team had the idea of charging for the software but now I am seeing that they raised VC money. There is no question that this sort of company can be big (See Vercel) but I'm wondering why this decision was made?
Sounds like timescale, metabase, and posthog.
Earlier quoted context omitted.
That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-ab…
NextJS ships with both the built-in fs router AND a traditional imperative router. Also, there's a lot more to caching with NextJS than SSG.
I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.
I remember the team had the idea of charging for the software but now I am seeing that they raised VC money. There is no question that this sort of company can be big (See Vercel) but I'm wondering why this decision was made?
because this sort of company can be big
Off topic: this is the best landing page I've ever seen on a mobile device. Keep scrolling down for some surprises!
It's mindbogglingly bloated and terrible.
So as a 56yo "old school" LAMP-stack monkey, could someone please give me a quick rundown exactly what benefits would investing the mental energy (a non-trivial amount) and time (less an issue) give to someone in my ancient yet comfortable canvas Cons? For sure next.js is an interesting framework and of course I use plenty of typescript in my projects to keep the UXs from feeling stale, but I have yet to see the over…
As a 47yo UI Designer and UX/User Centered Design Pioneer (CEO, PM, Business Owner, etc.), I have one rule of thumb towards "Cool JS/CSS/New tech": I wait for the tech to become "Unavoidable" in Implementation practices. Aside of "mental load", every new paradigm shift is measured in education/expenses/support time. So waiting for "market validation" is the only valuable option for me. This approach has saved a tons…
So the web dev madness has come full circle - the react people just built rails in react. In the mean time I just keep using rails...
So as a 56yo "old school" LAMP-stack monkey, could someone please give me a quick rundown exactly what benefits would investing the mental energy (a non-trivial amount) and time (less an issue) give to someone in my ancient yet comfortable canvas Cons? For sure next.js is an interesting framework and of course I use plenty of typescript in my projects to keep the UXs from feeling stale, but I have yet to see the over…
I think this new wave of server-enabled React is enabling codebases that are better organized than old MVC stacks. The MVC way was: 1. Look at the route 2. Recognize that this route has, e.g. A Header, A Sidebar, and Content 3. Load the data for the Header, Sidebar, and Content 4. Pass the data to the templating engine 5. Use the templating engine to render the route, which likely fans the data for the Header, Sideba…
you can do that with Suspense. React doc calls that render-as-you-fetch pattern https://reactjs.org/docs/concurrent-mode-suspense.html#appro...
I was reading through the documentation and the only thing I think is really lacking is the fact that there's no screenshots or examples of what the UI winds up looking like after the code has been written... is there any examples of what any of this looks like from the user perspective from the web browser side?
They lost me at: return ( {projects.map((project) => ( {project.title} ))} . . . I don't know why we need another framework that smashes together code and HTML/directive-based templates like this and, generally, keeps us bound so tightly to web idioms. Would be nice to have a framework that obscures these kinds of "web fundamentals", so we no longer have to wrangle such low-level primitives to build complex apps. EDI…