3 ms·

"Not Another Framework" ... is another framework. And from the look of it, it's the javascript equivalent of Ruby's Sinatra or Python's Flask. It's cool, but I

"Not Another Framework" ... is another framework. And from the look of it, it's the javascript equivalent of Ruby's Sinatra or Python's Flask. It's cool, but I think it promises way too much. These frameworks aren't so much frameworks, as they are framework builders. For small projects, they get out of your way. For larger projects, their lack of defaults and structure slowly becomes their own undoing. Eventually you get a bad reimplementation of one framework or another with absolutely abysmal security. Case in point: every Sinatra site I've ended up dealing with has turned into a bad version of Rails. ( Hand-rolled authentication, unsafe session handling, no CSRF protection, buggy form validation...) A field of infinite possibilities seems like a great idea, but you quickly realize it's actually a sea of infinite decisions. Once abstraction became possible, the debate between framework or no framework started. And hasn't stopped. Nor do I think it ever will. :)

OJFord 5y ago
> "Not Another Framework" ... is another framework. I don't think it's in denial about being a framework, it's meant as '[groan] not another framework' self-deprecation. (There's an exclamation mark in the original title that's stripped here.)
kayodelycaon 5y ago
And someone pointed out Remix has React as a hard-dependency... I thought some of the documentation looked familiar. Talk about misleading: > When we design Remix APIs, this is something we think about. We want your experience with Remix to transfer to web development generally.
- 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.
commandlinefan 5y ago
> a bad reimplementation of one framework or another But worse, as far as I've ever been able to tell. I haven't done enough web front-end development to really have a strong opinion on front-end frameworks, but I have done a non-trivial amount of it. I did work with Javascript back when it was new and then followed the jQuery "revolution". While I observed that jQuery actually did eliminate a fair amount of code, I also observed that is also eliminated all of the troubleshooting techniques I'd worked out for Javascript development. I couldn't place breakpoints in firebug any more because all events were being handled by one massive "event handler" (and then re-dispatched to jQuery's own custom reimplementation of the event handler infrastructure that the browser already had built into it). I found Angular to be effectively the same. By then it was worse because Chrome's debugging tools were top notch for "vanilla" Javascript development - much better then firebug had ever dreamed of being, but mostly useless in Angular unless you were lucky enough that a problem included a stack trace into some code that you wrote. I've never used React, but skimming through the high-level docs, it looks like it's more of the "let's write a web browser in Javascript and run it in a browser but with inferior tooling". This remix thing looks like "let's rewrite React in React but with even more inferior tooling" (but I could be wrong, haven't actually given it a chance).
LAC-Tech 5y ago
> For small projects, they get out of your way. For larger projects, their lack of defaults and structure slowly becomes their own undoing. Eventually you get a bad reimplementation of one framework or another with absolutely abysmal security. The vast majority of projects I've worked on have been small projects, using big project technology. Big frameworks (and here I'll speak more to enterprise react) make sense when you have at least one person it is whose fulltime job is be a sort of npm and tooling sysadmin. When you don't, and there's a small handful of you, it's heart-breaking when you all have to stop flying to perform arduous maintenance on your 747 you're ill-equipped to operate, instead of making progress in your cessna.
mastazi 5y ago
I respectfully disagree with one of the points you made: in my experience, micro frameworks like Sinatra or Flask work best for large projects while the more full fledged ones like Rails or Django work best in small projects. The reason is that micro frameworks give you more flexibility and in large projects this is gold since you have to deal with so many requirements and multiple stakeholders. In large projects having to do more things "manually" is actually a good thing for this reason. It is likely that you have a large team so in terms of work required it's not going to impact you that much. You can still use libraries for the various things the framework lacks, e.g. it's not like you have to build authentication from scratch, but at least being modular gives you freedom to swap one library for another. On the other hand whenever I worked in small teams or solo I have been highly appreciative of frameworks like Django that have "batteries included" and let me get things done quickly and efficiently. It's true what you say "A field of infinite possibilities seems like a great idea, but you quickly realize it's actually a sea of infinite decisions." but this is more of a problem if you are working solo or in a small team, whereas if you have a large team you can put different minds onto different problems/features... (Edit: grammar)
- lhorie 5y ago
  It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard was that people doing willy-nilly things cause setbacks to efforts to make project-wide improvements. One example was that build times were very slow and there was an effort to implement incremental builds along some interface boundaries, but then teams would disrespect agreements to not violate constraints for that boundary (because immediate deadlines trump long term large efforts) A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. A project can be very very large, but be entirely CRUD forms, and Rails could fit like a glove. But on the other hand, a project could have predominantly "curveball" features (maybe it simultaneously has a real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).
  - mastazi 5y ago
    > A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.

OJFord 5y ago

> "Not Another Framework" ... is another framework. I don't think it's in denial about being a framework, it's meant as '[groan] not another framework' self-deprecation. (There's an exclamation mark in the original title that's stripped here.)

kayodelycaon 5y ago

And someone pointed out Remix has React as a hard-dependency... I thought some of the documentation looked familiar. Talk about misleading: > When we design Remix APIs, this is something we think about. We want your experience with Remix to transfer to web development generally.

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.

commandlinefan 5y ago

> a bad reimplementation of one framework or another But worse, as far as I've ever been able to tell. I haven't done enough web front-end development to really have a strong opinion on front-end frameworks, but I have done a non-trivial amount of it. I did work with Javascript back when it was new and then followed the jQuery "revolution". While I observed that jQuery actually did eliminate a fair amount of code, I also observed that is also eliminated all of the troubleshooting techniques I'd worked out for Javascript development. I couldn't place breakpoints in firebug any more because all events were being handled by one massive "event handler" (and then re-dispatched to jQuery's own custom reimplementation of the event handler infrastructure that the browser already had built into it). I found Angular to be effectively the same. By then it was worse because Chrome's debugging tools were top notch for "vanilla" Javascript development - much better then firebug had ever dreamed of being, but mostly useless in Angular unless you were lucky enough that a problem included a stack trace into some code that you wrote. I've never used React, but skimming through the high-level docs, it looks like it's more of the "let's write a web browser in Javascript and run it in a browser but with inferior tooling". This remix thing looks like "let's rewrite React in React but with even more inferior tooling" (but I could be wrong, haven't actually given it a chance).

LAC-Tech 5y ago

> For small projects, they get out of your way. For larger projects, their lack of defaults and structure slowly becomes their own undoing. Eventually you get a bad reimplementation of one framework or another with absolutely abysmal security. The vast majority of projects I've worked on have been small projects, using big project technology. Big frameworks (and here I'll speak more to enterprise react) make sense when you have at least one person it is whose fulltime job is be a sort of npm and tooling sysadmin. When you don't, and there's a small handful of you, it's heart-breaking when you all have to stop flying to perform arduous maintenance on your 747 you're ill-equipped to operate, instead of making progress in your cessna.

mastazi 5y ago

I respectfully disagree with one of the points you made: in my experience, micro frameworks like Sinatra or Flask work best for large projects while the more full fledged ones like Rails or Django work best in small projects. The reason is that micro frameworks give you more flexibility and in large projects this is gold since you have to deal with so many requirements and multiple stakeholders. In large projects having to do more things "manually" is actually a good thing for this reason. It is likely that you have a large team so in terms of work required it's not going to impact you that much. You can still use libraries for the various things the framework lacks, e.g. it's not like you have to build authentication from scratch, but at least being modular gives you freedom to swap one library for another. On the other hand whenever I worked in small teams or solo I have been highly appreciative of frameworks like Django that have "batteries included" and let me get things done quickly and efficiently. It's true what you say "A field of infinite possibilities seems like a great idea, but you quickly realize it's actually a sea of infinite decisions." but this is more of a problem if you are working solo or in a small team, whereas if you have a large team you can put different minds onto different problems/features... (Edit: grammar)

lhorie 5y ago
It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard was that people doing willy-nilly things cause setbacks to efforts to make project-wide improvements. One example was that build times were very slow and there was an effort to implement incremental builds along some interface boundaries, but then teams would disrespect agreements to not violate constraints for that boundary (because immediate deadlines trump long term large efforts) A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. A project can be very very large, but be entirely CRUD forms, and Rails could fit like a glove. But on the other hand, a project could have predominantly "curveball" features (maybe it simultaneously has a real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).
- mastazi 5y ago
  > A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.