3 ms·

It seems like the best way to conceptualize Remix is that it translates your JavaScript components into it's equivalent Web primitives, instead the equivalent J

by ipnon 5y ago

It seems like the best way to conceptualize Remix is that it translates your JavaScript components into it's equivalent Web primitives, instead the equivalent JavaScript Webpack monster interlaced with the endless NPM dependencies we know and love. Wherever the browser has native support for some functionality, Remix uses it so that you don't reinvent the browser as a thin JavaScript layer over every one of your projects. The result is that you get the snappiness and simplicity of a Web1.0 website on the user end, but you can still develop your applications with the all the frontend advancements made in the last 15 years.

dmitriid 5y ago
> it translates your JavaScript components into it's equivalent Web primitives It doesn't. Or, rather, it does nothing different than React. > instead the equivalent JavaScript Webpack monster interlaced with the endless NPM dependencies we know and love. Yup. Because Remix translates those components by pure magic, with no dependencies > npx create-remix@latest > cd node_modules > ls -l | wc 379 Oh look. 379 dependencies before we even wrote a single line of code > Wherever the browser has native support for some functionality, Remix uses it so that you don't reinvent the browser as a thin JavaScript layer over every one of your projects. Remix's own docs show this is not true. It adds additional abstractions everywhere, and "uses underlying browser functionality" literally to the same extent as everybody else. Example, fetching data: Remix polyfills the fetch API on your server so it's very easy to fetch data from existing JSON APIs. Instead of managing state, errors, race conditions, and more yourself, you can do the fetch from your loader (on the server) and let Remix handle the rest. Remix optimizes the user experiences by only loading the data for the parts of the page that are changing on navigation. So it creates a polyfill, and adds layers of abstraction to make it work. You can say, "it's because it's not in the browser, but on the server". Yes, exactly, Remix doesn't even have documentation on how to use all that goodness on the client. Instead, it creates a huge, complex, and undoubtedly brittle tower of abstractions to make all that work on the server.

by ipnon 5y ago

dmitriid 5y ago

> it translates your JavaScript components into it's equivalent Web primitives It doesn't. Or, rather, it does nothing different than React. > instead the equivalent JavaScript Webpack monster interlaced with the endless NPM dependencies we know and love. Yup. Because Remix translates those components by pure magic, with no dependencies > npx create-remix@latest > cd node_modules > ls -l | wc 379 Oh look. 379 dependencies before we even wrote a single line of code > Wherever the browser has native support for some functionality, Remix uses it so that you don't reinvent the browser as a thin JavaScript layer over every one of your projects. Remix's own docs show this is not true. It adds additional abstractions everywhere, and "uses underlying browser functionality" literally to the same extent as everybody else. Example, fetching data: Remix polyfills the fetch API on your server so it's very easy to fetch data from existing JSON APIs. Instead of managing state, errors, race conditions, and more yourself, you can do the fetch from your loader (on the server) and let Remix handle the rest. Remix optimizes the user experiences by only loading the data for the parts of the page that are changing on navigation. So it creates a polyfill, and adds layers of abstraction to make it work. You can say, "it's because it's not in the browser, but on the server". Yes, exactly, Remix doesn't even have documentation on how to use all that goodness on the client. Instead, it creates a huge, complex, and undoubtedly brittle tower of abstractions to make all that work on the server.