22 ms·

Not Another Framework

70 points by pspeter3 5y ago

getcrunk 5y ago
Followed the link, didn't know what remix was so clicked the logo up top. Took me to /blogs. Clicked again, took me to / Pretty cool!
- nomdep 5y ago
  Not sure if you’re been sarcastic or not
  - bdcravens 5y ago
    I'm going with yes, and would say it's well deserved.
    - capableweb 5y ago
      In general you want navigation to remain the same no matter where you are. Clicking the same button twice takes you to a different place compared to if you press it once? That breaks the user expectation. More fitting would have been to have two elements next to each other, one "Remix" that takes you to the landing page, and one "Blog" that takes you to the index of the blog.
Scarbutt 5y ago
That's one condescending and manipulative article.
- dgb23 5y ago
  I agree. Their landing page is pretty cool. But I had to navigate deep into the docs to figure out what this is: A Nodejs and React based full stack framework with DSL magic. It does progressive enhancement is optimized for partial data fetching and UI updates.
  - k__ 5y ago
    It can be used independently from Node.js
    - ithrow 5y ago
      But looks like you do need to have v8 running somewhere for production?
      - k__ 5y ago
        It runs on Cloudflare Workers, so I don't think so.
        ithrow 5y ago
        What do you think cloudflare workers are and what is parsing the JS? ;)
        deleted 5y ago
        [deleted]
        k__ 5y ago
        I could swear your comment said Node.js instead of V8 when I answered.
    - bdcravens 5y ago
      Not according to the package.json. https://github.com/remix-run/remix/blob/main/package.json https://github.com/remix-run/remix/blob/main/package.json
      - k__ 5y ago
        As far as I understood it, Node.js is needed for building, but the package runs on different JS environments.
- akmittal 5y ago
  How so care to describe? Well i don't fully agree, you still have to learn react/JSX. But they still use the platform lot more than most other solutions(next, react, angular)
  - dmitriid 5y ago
    > But they still use the platform lot more than most other solutions They use about the same amount.
ziggus 5y ago
Not Another Advertisement Disguised As A Blog Post
- dimitrisnl 5y ago
  Were you expecting productivity tips or something?
- akmittal 5y ago
  What's wrong with advertising something which is actually great. Remix seems very promising and has much better performance than nextjs
andrewl-hn 5y ago
Somehow I had an impression that web developers in general are aware of web APIs: stuff like fetch, DOM events, forms and URLs - all things this article lists. Modern React development doesn’t deal with these things much not because devs don’t learn web APIs but because most projects use various component libraries that abstract web APIs from devs. You as an app developer do a lot more work to glue components together to achieve the desired behavior and you mostly deal with data management. I don’t say Remix is bad, it’s an impressive piece of technology for building interactive UIs that tries to blend server side and browser side of web in a neat package, quite successfully I must say! It’s very pleasant to work with, not hard to get into, and I personally haven’t found any big drawbacks. I’d recommend it for all sorts of projects! But this whole “we do plain web APIs” marketing angle is IMO strange and misleading. Remix is a set of APIs on top of React, you will be building React apps with it, with JSX, hooks and everything else. It’s NOT a vanilla web, far from it.
- dimitrisnl 5y ago
  > most projects use various component libraries that abstract web APIs from devs You would be surprised
- simonw 5y ago
  The impression I have is that many web developers who learned their trade in the past five years know how to build with React (or maybe another front-end framework) but don't know how to hook up a JavaScript-free form using GET or POST - or even know that it's possible and sometimes desirable to do that!
  - andrewl-hn 5y ago
    I suspect you’re right. I organize conferences, and about 5 years we ran into similar situations. A speaker would propose a talk and they would put an example that would assume the audience’ familiarity with jQuery. We’d have to explain to the speaker that half of our audience started doing web development 2-3 years before, and there was a very high chance they started with React and never wrote or read any jQuery-based code. Many talk proposals would almost completely broke down because of that.
dimitrisnl 5y ago
Very interesting, hoping to see some real-world examples soon.
weego 5y ago
No, the exhausting part is not a new framework, it's being pitched The Next Revolution when it's just a horizontally-iterative variation on a domain that people continue to reinvent without ever actually making a difference. Someone need to step up to the bigger picture of how we stop the entire JS side of the industry repeat the same mistakes that not only other domains have already dealt with but that the JS community seems destined to repeat themselves.
- beepbooptheory 5y ago
  Having actually read the article, I thought what it had to say about "transferable knowledge" spoke to this general complaint quiet nicely. Whether you think its the right answer or not, I'm not sure.
  - weego 5y ago
    I just feel like it's trying to force the 'A-ha!' moment that the first rails demonstrations had for most developers at the time, when that ship has long sailed. I'm probably just jaded. There's nothing actually wrong with what they're doing at all, it's just 20 years later and there's an overwhelming feeling of 'is this all we've achieved?'
    - kayodelycaon 5y ago
      It's almost like each new generation of programmers needs to go through the same cycles of possible solutions. Those of us who are older see a rehashing of old arguments. Those who are younger, are seeing those arguments for the first time. I wouldn't worry too much about it. High schoolers make me cranky and my parent's generation is completely out of touch. My parents and grandparents felt the same at my age. :)
    - danjac 5y ago
      Rails was a full-stack framework that took care of everything from database models down to frontend AJAX integration, so you literally could build a very basic blog that actually saved stuff to a database within 20 minutes. Remix is yet another frontend framework that you have to manually wire up to some other library or service to do anything useful.
dmitriid 5y ago
> Learn Remix, Accidentally Learn the Web Th post links to tutorial, whose first line of actual code is: import { Link } from "remix"; <Link to="/posts">Posts</Link> 1. This is not the web 2. This is not transferrable knowledge I've skimmed through the tutorial and I fail to see anything in there that "actually teaches you web". It's a bunch or same old React, with same old React abstractions. Not that those abstractions are bad. They are just falling short of what Remix's heavy-handed marketing promises.
- jaredcwhite 5y ago
  Imagine a web framework where you could write `<a href="/link-to-something">Something</a>` and It. Just. Works. sky parting, rainbows, unicorns, choir of angels singing…
  - scgtrp 5y ago
    We had that already! In the 1990s!
kayodelycaon 5y ago
"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.
deleted 5y ago
[deleted]
brentm 5y ago
It would be really interesting to see what the conversion funnel looks like for a new framework like this.
mmckelvy 5y ago
I haven't had a chance to check out Remix yet, but I've certainly been impressed with the creators' (Ryan Florence and Michael Jackson) work on React Router and their React Training series. They design very good, easy to learn, low surface area APIs. I suspect Remix will be more of the same. Regarding frameworks in general, the common lament is that it's all churn with no progress. In my experience this certainly hasn't been the case. It was much easier to work with jQuery than with the old web APIs, and it's light years easier to work with React than with jQuery or some of the older frameworks like Backbone and Ember. Each step built upon the previous one and unlocked a completely new set of capabilities.
- capableweb 5y ago
  > I haven't had a chance to check out Remix yet, but I've certainly been impressed with the creators' (Ryan Florence and Michael Jackson) work on React Router and their React Training series. They design very good, easy to learn, low surface area APIs. I suspect Remix will be more of the same. Isn't React Router one of the projects that are famous for completely changing their API for every single version they've released (basically)? Sure, they got a lot of training to perfect designing APIs I guess, but at one point you get frustrated of the constant churn, and the authors neglect of stability.
jaredcwhite 5y ago
> So while you do need to learn a few React specific APIs, most of your code is just JavaScript. That's transferrable knowledge! Well that gets a big LOL from me. React goes out of its way to eliminate any awareness or interaction with real DOM APIs, and tends to abstract away all kinds of things that are actually straightforward using native JS APIs. Heck, we're only _just now_ perhaps-maybe-hopefully getting true support for web components and they've been around for years. If you want to use a reactive view library that actually helps you learn about vanilla APIs, try Lit. Or drop down a level and check out Stimulus.
- dmitriid 5y ago
  > helps you learn about vanilla APIs, try Lit Ah yes. The library that has its own string-based DSL surely "helps you learn about vanilla APIs"
huqedato 5y ago
Unfortunately Remix is just another framework! It brings nothing new/better than common React/Vue/Angular... It will soon fade away into the funnel of the web development history; just like its many other brothers before/after it.
jscholes 5y ago
This page talks a lot about knowledge that is transferable, e.g.: > We want your experience with Remix to transfer to web development generally. But then, you opened the quickstart tutorial[1], and the first bit of mark-up is: <Link to="/posts">Posts</Link> Uh... okay. Not only is this not how you create links in HTML, but it also repurposes an element that actually does exist in HTML[2] for a completely different purpose. Of course, as to not conflict with that element, I now have to remember to type the L in uppercase, which is another aspect that doesn't carry over to HTML either. It seems the amount they're willing to reinvent is limited to JavaScript. [1] https://remix.run/docs/en/v1/tutorials/blog https://remix.run/docs/en/v1/tutorials/blog [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li...
- pier25 5y ago
  That's only if you want to take advantage of the hydration and client side routing. You can of course use regular <a> links and navigate to a new page every time.
  - jscholes 5y ago
    > That's only if you want to take advantage of the hydration and client side routing. I feel it would be doable for a framework to determine which links should be client-side routed versus not. Or, failing that (or in conjunction with it), provide a way for developers to indicate that information, without reinventing a cornerstone of the web and HTML mark-up from scratch.
    - vagrantJin 5y ago
      I agree with your point. I dont know what it is about some devs aversion for HTML. But a anchor with a data attribute should more than suffice rather than creating over-engineered abstractions. But then again, not many devs even read the HTML docs.
    - pier25 5y ago
      That's probably what they would have done if starting from scratch, but Remix is built on top of React Router which is a 7-8 year old project with its own idioms. Also, Remix is for React developers. It's expected you will use JSX, components, etc. Personally I have a toy client-side router for Svelte. Links that need to trigger client-side navigation simply use a Svelte action: <a href="/" use:link>Home</a> https://github.com/PierBover/roots-svelte-router https://github.com/PierBover/roots-svelte-router
lhorie 5y ago
[Disclaimer: I'm the author of mithril.js, another web framework] I've thought a lot about the idea of transferable knowledge, and my feelings on it have matured a bit over the years. The premise of the article is that web technologies are transferable knowledge because they underlie helper abstractions, and yes, you're much more likely to gain a higher appreciation of something like FormData if you look at the MDN docs than if you look at the axios docs. But also, that's kinda beside the point if the idiomatic way to do HTTP requests in React has a different API than in Angular. You could argue that despite the superficial API differences, what is transferable is the understanding of the platform itself: what is CORS, what is CSRF, what are HTTP headers, what is idempotency in the context of HTTP, etc. Learning the standard Request API doesn't necessarily teach any of that any more than learning axios' API. But knowing the platform lets you feel your way around new framework APIs. Another example: the naked history.pushState API is frankly horrendous to work with. Who wants to think about state machines and mess with scroll positions manually? Routers, on the other hand, are present in pretty much every self-respecting framework, and while their APIs don't always map 1:1 among themselves, the concept of declarative routing is transferable knowledge, because that's what every framework does. That's the "meta". So I think of transferable knowledge along two axes: - the first axis is how much can the framework get out of the way of learning the platform. Can I easily figure out what API translates to history.replaceState? Can I easily figure out which API maps to the `credentials` field for a CORS-enabled endpoint? Can I easily reason about CSRF tokens? Can I tell the framework to just take a hike and access the underlying API directly? - the second axis is how much the framework conforms to developer expectations. How much does a framework conform to the "meta" of declarative views and routers, state and error propagation, etc, and how much is gained or lost by breaking away from mainstream patterns. There's also something to be said about the emergence of emulation of transferable knowledge. The biggest example of this is Svelte, which looks a lot like "plain vanilla JS", but it achieves this via some non-trivial compilation, which sometimes leaves gaping abstraction holes like the `list = list` pattern. The transferable knowledge here for a more seasoned developer is not so much the basics of JS, but the understanding of how reactivity models are implemented. But this may or may not be the level of knowledge that is relevant for you.
pier25 5y ago
Remix is looking super cool. A breath of fresh air really in the JS ecosystem. Rich Harris (creator of Svelte) has actually been introducing new features to SvelteKit inspired by Remix. https://github.com/sveltejs/kit/issues/3533 https://github.com/sveltejs/kit/issues/3533 https://github.com/sveltejs/kit/issues/3532 https://github.com/sveltejs/kit/issues/3532 A lot of people in this thread are having weird opinions because they don't really understand the context of Remix. The point of Remix is that it facilitates SSR + hydration + progressive enhancement full stack dev in the most efficient way possible regarding DX. Network wise it's also much more efficient than Next, which is the predominant framework in this space. Of course if you just want to spit out HTML from your server, Remix would be a pretty stupid choice. In part because React's render to string is very slow, but also because there are already very mature options to do that (Rails, Django, Laravel, etc).
- dmitriid 5y ago
  > A lot of people in this thread are having weird opinions because they don't really understand the context of Remix. Because Remix goes out if the way to never describe what it actually does. > The point of Remix is that it facilitates SSR + hydration + progressive enhancement full stack dev in the most efficient way possible regarding DX. See, if this was written on Remix's website, or in the blog post we're discussing, there would be significantly fewer people "missing the point".
  - pier25 5y ago
    I'm so immersed in this stuff it seems obvious to me (and probably the creators of React) but you're absolutely right.
aobdev 5y ago
I don’t think anyone here is giving remix enough credit for what they’re trying to do. In fact I’ve been a long time lurker and finally made an account today to share this opinion. My company is building a B2B ordering system. We take reservations and store fulfillment details with some email and SMS functionality bolted on to a web interface; at least for now it’s a simple business CRUD app. We chose to use Vue for the frontend and Python REST APIs on the backend. And it has been thoroughly frustrating to just ship our MVP, because when I look into our frontend codebase, more than half of it is a bunch of API calls, state management, authentication, and error handling that honestly does not provide much value to the product that we’re offering. I half wish that we had built this in Rails or Django. Except, we are geospatial-enabled and have a killer interactive map view that powers this whole thing. And it’s not just a single asset-tracking view, but this map component is going to be embedded in several places across the app. And when you zoom, pan, or search the relevant data on screen is updated. I wouldn’t dare try to build this in anything other than one of the big 3 SPA frameworks today. Why do I have to choose between a traditional app with poor ergonomics for developing frontend JS, and a clunky SPA that reinvents everything the browser has gotten good at in the last 20 years? Remix is a hybrid and I think they are on to something really great here. I can write my server side models and controllers as in days of yore and pass them straight to a renderer that happens to be full blown React + React Router that does as many fancy interactive things on the frontend as I wish once the page is hydrated. I think it’s easy for backend devs to discount how nice it is to use JSX across the stack if they’re used to a templating language and writing JS sprinkles to manipulate the DOM. And it’s easy for frontend devs to discount how much extra work it is to create an API when your team is only using it internally for a first-party app, because you need APIs for SPAs. But once you realize that you can eliminate these entire bodies of work (manipulating the DOM and writing an unnecessary API), you get the best of both worlds and everything about complicated web dev today feels so achievable. Even if it’s early days yet, and Remix can’t hold a candle to comprehensive frameworks like Rails, this is much more than just Sinatra or Flask written in JS. I’m seriously excited about where Remix is headed and I’m rooting for these guys all the way.
- dmitriid 5y ago
  > I don’t think anyone here is giving remix enough credit for what they’re trying to do. We would give it credit if Remix actually told us what they are trying to do. Instead we see very heavy-hanvded marketing claiming nothing short of a revolution and failing.
Chyzwar 5y ago
I will not touch remix with 10 foot pole. It is from react-router authors, it is only open source that bring my worst emotions.
- pandesal 5y ago
  Why?
  - ithrow 5y ago
    Every new release was like "we broke backwards compatibility but we got it right this time", rinse and repeat
    - dmitriid 5y ago
      The upgrade docs for the latest release is like War and Peace. For a frigging router. With lots of things like "we renamed this or that option or component for literally no reason"
      - doteka 5y ago
        What do you mean for no reason? The authors run a consulting shop and give trainings on this library. They are clearly incentivized to break things regularly.
- midrus 5y ago
  Same. Got burned so badly by it. And I'm pretty sure same thing will happen with this framework. Can see how 1 year from now it is a totally different thing impossible to update without rewriting everything because they've got a new idea.
cblconfederate 5y ago
> The worst part is feeling like all the deep knowledge I have with my current tools is now obsolete, and I'm a beginner all over again The worst part is that there are millions of github projects that are abandoned, obsolete, uncompilable, unworkable, broken etc. Meanwhile you can still find every kind of widget in jqueryscript.net and it works! Seriously, screw more frameworks, javascript programming is fundamentally broken and no amount of frameworking or godawful constructs will fix that basic fact. After dabbling a bit with 'modern' javascript i m convinced there's a mass epidemic of masochism in the community. And in the meanwhile browser development is progressing at snail-pace. It's 2022 and we still have to deal with unfinished implementations of ubercomplex things like webrtc.
midrus 5y ago
Sorry yes, it's yet another framework. This one happens to have more marketing than others.
flykespice 5y ago

70 points by pspeter3 5y ago

Followed the link, didn't know what remix was so clicked the logo up top. Took me to /blogs. Clicked again, took me to / Pretty cool!

nomdep 5y ago
Not sure if you’re been sarcastic or not
- bdcravens 5y ago
  I'm going with yes, and would say it's well deserved.
  - capableweb 5y ago
    In general you want navigation to remain the same no matter where you are. Clicking the same button twice takes you to a different place compared to if you press it once? That breaks the user expectation. More fitting would have been to have two elements next to each other, one "Remix" that takes you to the landing page, and one "Blog" that takes you to the index of the blog.

Scarbutt 5y ago

That's one condescending and manipulative article.

dgb23 5y ago
I agree. Their landing page is pretty cool. But I had to navigate deep into the docs to figure out what this is: A Nodejs and React based full stack framework with DSL magic. It does progressive enhancement is optimized for partial data fetching and UI updates.
- k__ 5y ago
  It can be used independently from Node.js
  - ithrow 5y ago
    But looks like you do need to have v8 running somewhere for production?
    - k__ 5y ago
      It runs on Cloudflare Workers, so I don't think so.
      - ithrow 5y ago
        What do you think cloudflare workers are and what is parsing the JS? ;)
        deleted 5y ago
        [deleted]
        k__ 5y ago
        I could swear your comment said Node.js instead of V8 when I answered.
  - bdcravens 5y ago
    Not according to the package.json. https://github.com/remix-run/remix/blob/main/package.json https://github.com/remix-run/remix/blob/main/package.json
    - k__ 5y ago
      As far as I understood it, Node.js is needed for building, but the package runs on different JS environments.
akmittal 5y ago
How so care to describe? Well i don't fully agree, you still have to learn react/JSX. But they still use the platform lot more than most other solutions(next, react, angular)
- dmitriid 5y ago
  > But they still use the platform lot more than most other solutions They use about the same amount.

ziggus 5y ago

Not Another Advertisement Disguised As A Blog Post

dimitrisnl 5y ago
Were you expecting productivity tips or something?
akmittal 5y ago
What's wrong with advertising something which is actually great. Remix seems very promising and has much better performance than nextjs

andrewl-hn 5y ago

Somehow I had an impression that web developers in general are aware of web APIs: stuff like fetch, DOM events, forms and URLs - all things this article lists. Modern React development doesn’t deal with these things much not because devs don’t learn web APIs but because most projects use various component libraries that abstract web APIs from devs. You as an app developer do a lot more work to glue components together to achieve the desired behavior and you mostly deal with data management. I don’t say Remix is bad, it’s an impressive piece of technology for building interactive UIs that tries to blend server side and browser side of web in a neat package, quite successfully I must say! It’s very pleasant to work with, not hard to get into, and I personally haven’t found any big drawbacks. I’d recommend it for all sorts of projects! But this whole “we do plain web APIs” marketing angle is IMO strange and misleading. Remix is a set of APIs on top of React, you will be building React apps with it, with JSX, hooks and everything else. It’s NOT a vanilla web, far from it.

dimitrisnl 5y ago
> most projects use various component libraries that abstract web APIs from devs You would be surprised
simonw 5y ago
The impression I have is that many web developers who learned their trade in the past five years know how to build with React (or maybe another front-end framework) but don't know how to hook up a JavaScript-free form using GET or POST - or even know that it's possible and sometimes desirable to do that!
- andrewl-hn 5y ago
  I suspect you’re right. I organize conferences, and about 5 years we ran into similar situations. A speaker would propose a talk and they would put an example that would assume the audience’ familiarity with jQuery. We’d have to explain to the speaker that half of our audience started doing web development 2-3 years before, and there was a very high chance they started with React and never wrote or read any jQuery-based code. Many talk proposals would almost completely broke down because of that.

dimitrisnl 5y ago

Very interesting, hoping to see some real-world examples soon.

weego 5y ago

No, the exhausting part is not a new framework, it's being pitched The Next Revolution when it's just a horizontally-iterative variation on a domain that people continue to reinvent without ever actually making a difference. Someone need to step up to the bigger picture of how we stop the entire JS side of the industry repeat the same mistakes that not only other domains have already dealt with but that the JS community seems destined to repeat themselves.

beepbooptheory 5y ago
Having actually read the article, I thought what it had to say about "transferable knowledge" spoke to this general complaint quiet nicely. Whether you think its the right answer or not, I'm not sure.
- weego 5y ago
  I just feel like it's trying to force the 'A-ha!' moment that the first rails demonstrations had for most developers at the time, when that ship has long sailed. I'm probably just jaded. There's nothing actually wrong with what they're doing at all, it's just 20 years later and there's an overwhelming feeling of 'is this all we've achieved?'
  - kayodelycaon 5y ago
    It's almost like each new generation of programmers needs to go through the same cycles of possible solutions. Those of us who are older see a rehashing of old arguments. Those who are younger, are seeing those arguments for the first time. I wouldn't worry too much about it. High schoolers make me cranky and my parent's generation is completely out of touch. My parents and grandparents felt the same at my age. :)
  - danjac 5y ago
    Rails was a full-stack framework that took care of everything from database models down to frontend AJAX integration, so you literally could build a very basic blog that actually saved stuff to a database within 20 minutes. Remix is yet another frontend framework that you have to manually wire up to some other library or service to do anything useful.

dmitriid 5y ago

> Learn Remix, Accidentally Learn the Web Th post links to tutorial, whose first line of actual code is: import { Link } from "remix"; <Link to="/posts">Posts</Link> 1. This is not the web 2. This is not transferrable knowledge I've skimmed through the tutorial and I fail to see anything in there that "actually teaches you web". It's a bunch or same old React, with same old React abstractions. Not that those abstractions are bad. They are just falling short of what Remix's heavy-handed marketing promises.

jaredcwhite 5y ago
Imagine a web framework where you could write `<a href="/link-to-something">Something</a>` and It. Just. Works. sky parting, rainbows, unicorns, choir of angels singing…
- scgtrp 5y ago
  We had that already! In the 1990s!

kayodelycaon 5y ago

"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.

deleted 5y ago

[deleted]

brentm 5y ago

It would be really interesting to see what the conversion funnel looks like for a new framework like this.

mmckelvy 5y ago

I haven't had a chance to check out Remix yet, but I've certainly been impressed with the creators' (Ryan Florence and Michael Jackson) work on React Router and their React Training series. They design very good, easy to learn, low surface area APIs. I suspect Remix will be more of the same. Regarding frameworks in general, the common lament is that it's all churn with no progress. In my experience this certainly hasn't been the case. It was much easier to work with jQuery than with the old web APIs, and it's light years easier to work with React than with jQuery or some of the older frameworks like Backbone and Ember. Each step built upon the previous one and unlocked a completely new set of capabilities.

capableweb 5y ago
> I haven't had a chance to check out Remix yet, but I've certainly been impressed with the creators' (Ryan Florence and Michael Jackson) work on React Router and their React Training series. They design very good, easy to learn, low surface area APIs. I suspect Remix will be more of the same. Isn't React Router one of the projects that are famous for completely changing their API for every single version they've released (basically)? Sure, they got a lot of training to perfect designing APIs I guess, but at one point you get frustrated of the constant churn, and the authors neglect of stability.

jaredcwhite 5y ago

> So while you do need to learn a few React specific APIs, most of your code is just JavaScript. That's transferrable knowledge! Well that gets a big LOL from me. React goes out of its way to eliminate any awareness or interaction with real DOM APIs, and tends to abstract away all kinds of things that are actually straightforward using native JS APIs. Heck, we're only _just now_ perhaps-maybe-hopefully getting true support for web components and they've been around for years. If you want to use a reactive view library that actually helps you learn about vanilla APIs, try Lit. Or drop down a level and check out Stimulus.

dmitriid 5y ago
> helps you learn about vanilla APIs, try Lit Ah yes. The library that has its own string-based DSL surely "helps you learn about vanilla APIs"

huqedato 5y ago

Unfortunately Remix is just another framework! It brings nothing new/better than common React/Vue/Angular... It will soon fade away into the funnel of the web development history; just like its many other brothers before/after it.

jscholes 5y ago

This page talks a lot about knowledge that is transferable, e.g.: > We want your experience with Remix to transfer to web development generally. But then, you opened the quickstart tutorial[1], and the first bit of mark-up is: <Link to="/posts">Posts</Link> Uh... okay. Not only is this not how you create links in HTML, but it also repurposes an element that actually does exist in HTML[2] for a completely different purpose. Of course, as to not conflict with that element, I now have to remember to type the L in uppercase, which is another aspect that doesn't carry over to HTML either. It seems the amount they're willing to reinvent is limited to JavaScript. [1] https://remix.run/docs/en/v1/tutorials/blog https://remix.run/docs/en/v1/tutorials/blog [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li...

pier25 5y ago
That's only if you want to take advantage of the hydration and client side routing. You can of course use regular <a> links and navigate to a new page every time.
- jscholes 5y ago
  > That's only if you want to take advantage of the hydration and client side routing. I feel it would be doable for a framework to determine which links should be client-side routed versus not. Or, failing that (or in conjunction with it), provide a way for developers to indicate that information, without reinventing a cornerstone of the web and HTML mark-up from scratch.
  - vagrantJin 5y ago
    I agree with your point. I dont know what it is about some devs aversion for HTML. But a anchor with a data attribute should more than suffice rather than creating over-engineered abstractions. But then again, not many devs even read the HTML docs.
  - pier25 5y ago
    That's probably what they would have done if starting from scratch, but Remix is built on top of React Router which is a 7-8 year old project with its own idioms. Also, Remix is for React developers. It's expected you will use JSX, components, etc. Personally I have a toy client-side router for Svelte. Links that need to trigger client-side navigation simply use a Svelte action: <a href="/" use:link>Home</a> https://github.com/PierBover/roots-svelte-router https://github.com/PierBover/roots-svelte-router

lhorie 5y ago

[Disclaimer: I'm the author of mithril.js, another web framework] I've thought a lot about the idea of transferable knowledge, and my feelings on it have matured a bit over the years. The premise of the article is that web technologies are transferable knowledge because they underlie helper abstractions, and yes, you're much more likely to gain a higher appreciation of something like FormData if you look at the MDN docs than if you look at the axios docs. But also, that's kinda beside the point if the idiomatic way to do HTTP requests in React has a different API than in Angular. You could argue that despite the superficial API differences, what is transferable is the understanding of the platform itself: what is CORS, what is CSRF, what are HTTP headers, what is idempotency in the context of HTTP, etc. Learning the standard Request API doesn't necessarily teach any of that any more than learning axios' API. But knowing the platform lets you feel your way around new framework APIs. Another example: the naked history.pushState API is frankly horrendous to work with. Who wants to think about state machines and mess with scroll positions manually? Routers, on the other hand, are present in pretty much every self-respecting framework, and while their APIs don't always map 1:1 among themselves, the concept of declarative routing is transferable knowledge, because that's what every framework does. That's the "meta". So I think of transferable knowledge along two axes: - the first axis is how much can the framework get out of the way of learning the platform. Can I easily figure out what API translates to history.replaceState? Can I easily figure out which API maps to the `credentials` field for a CORS-enabled endpoint? Can I easily reason about CSRF tokens? Can I tell the framework to just take a hike and access the underlying API directly? - the second axis is how much the framework conforms to developer expectations. How much does a framework conform to the "meta" of declarative views and routers, state and error propagation, etc, and how much is gained or lost by breaking away from mainstream patterns. There's also something to be said about the emergence of emulation of transferable knowledge. The biggest example of this is Svelte, which looks a lot like "plain vanilla JS", but it achieves this via some non-trivial compilation, which sometimes leaves gaping abstraction holes like the `list = list` pattern. The transferable knowledge here for a more seasoned developer is not so much the basics of JS, but the understanding of how reactivity models are implemented. But this may or may not be the level of knowledge that is relevant for you.

pier25 5y ago

Remix is looking super cool. A breath of fresh air really in the JS ecosystem. Rich Harris (creator of Svelte) has actually been introducing new features to SvelteKit inspired by Remix. https://github.com/sveltejs/kit/issues/3533 https://github.com/sveltejs/kit/issues/3533 https://github.com/sveltejs/kit/issues/3532 https://github.com/sveltejs/kit/issues/3532 A lot of people in this thread are having weird opinions because they don't really understand the context of Remix. The point of Remix is that it facilitates SSR + hydration + progressive enhancement full stack dev in the most efficient way possible regarding DX. Network wise it's also much more efficient than Next, which is the predominant framework in this space. Of course if you just want to spit out HTML from your server, Remix would be a pretty stupid choice. In part because React's render to string is very slow, but also because there are already very mature options to do that (Rails, Django, Laravel, etc).

dmitriid 5y ago
> A lot of people in this thread are having weird opinions because they don't really understand the context of Remix. Because Remix goes out if the way to never describe what it actually does. > The point of Remix is that it facilitates SSR + hydration + progressive enhancement full stack dev in the most efficient way possible regarding DX. See, if this was written on Remix's website, or in the blog post we're discussing, there would be significantly fewer people "missing the point".
- pier25 5y ago
  I'm so immersed in this stuff it seems obvious to me (and probably the creators of React) but you're absolutely right.

aobdev 5y ago

I don’t think anyone here is giving remix enough credit for what they’re trying to do. In fact I’ve been a long time lurker and finally made an account today to share this opinion. My company is building a B2B ordering system. We take reservations and store fulfillment details with some email and SMS functionality bolted on to a web interface; at least for now it’s a simple business CRUD app. We chose to use Vue for the frontend and Python REST APIs on the backend. And it has been thoroughly frustrating to just ship our MVP, because when I look into our frontend codebase, more than half of it is a bunch of API calls, state management, authentication, and error handling that honestly does not provide much value to the product that we’re offering. I half wish that we had built this in Rails or Django. Except, we are geospatial-enabled and have a killer interactive map view that powers this whole thing. And it’s not just a single asset-tracking view, but this map component is going to be embedded in several places across the app. And when you zoom, pan, or search the relevant data on screen is updated. I wouldn’t dare try to build this in anything other than one of the big 3 SPA frameworks today. Why do I have to choose between a traditional app with poor ergonomics for developing frontend JS, and a clunky SPA that reinvents everything the browser has gotten good at in the last 20 years? Remix is a hybrid and I think they are on to something really great here. I can write my server side models and controllers as in days of yore and pass them straight to a renderer that happens to be full blown React + React Router that does as many fancy interactive things on the frontend as I wish once the page is hydrated. I think it’s easy for backend devs to discount how nice it is to use JSX across the stack if they’re used to a templating language and writing JS sprinkles to manipulate the DOM. And it’s easy for frontend devs to discount how much extra work it is to create an API when your team is only using it internally for a first-party app, because you need APIs for SPAs. But once you realize that you can eliminate these entire bodies of work (manipulating the DOM and writing an unnecessary API), you get the best of both worlds and everything about complicated web dev today feels so achievable. Even if it’s early days yet, and Remix can’t hold a candle to comprehensive frameworks like Rails, this is much more than just Sinatra or Flask written in JS. I’m seriously excited about where Remix is headed and I’m rooting for these guys all the way.

dmitriid 5y ago
> I don’t think anyone here is giving remix enough credit for what they’re trying to do. We would give it credit if Remix actually told us what they are trying to do. Instead we see very heavy-hanvded marketing claiming nothing short of a revolution and failing.

Chyzwar 5y ago

I will not touch remix with 10 foot pole. It is from react-router authors, it is only open source that bring my worst emotions.

pandesal 5y ago
Why?
- ithrow 5y ago
  Every new release was like "we broke backwards compatibility but we got it right this time", rinse and repeat
  - dmitriid 5y ago
    The upgrade docs for the latest release is like War and Peace. For a frigging router. With lots of things like "we renamed this or that option or component for literally no reason"
    - doteka 5y ago
      What do you mean for no reason? The authors run a consulting shop and give trainings on this library. They are clearly incentivized to break things regularly.
midrus 5y ago
Same. Got burned so badly by it. And I'm pretty sure same thing will happen with this framework. Can see how 1 year from now it is a totally different thing impossible to update without rewriting everything because they've got a new idea.

cblconfederate 5y ago

> The worst part is feeling like all the deep knowledge I have with my current tools is now obsolete, and I'm a beginner all over again The worst part is that there are millions of github projects that are abandoned, obsolete, uncompilable, unworkable, broken etc. Meanwhile you can still find every kind of widget in jqueryscript.net and it works! Seriously, screw more frameworks, javascript programming is fundamentally broken and no amount of frameworking or godawful constructs will fix that basic fact. After dabbling a bit with 'modern' javascript i m convinced there's a mass epidemic of masochism in the community. And in the meanwhile browser development is progressing at snail-pace. It's 2022 and we still have to deal with unfinished implementations of ubercomplex things like webrtc.

midrus 5y ago

Sorry yes, it's yet another framework. This one happens to have more marketing than others.

flykespice 5y ago