6 ms·

> We've collectively complicated the hell out of things. Yes. > I loved Rails, it made me as a young developer able to finally realize way more ambitious proj

by timr 2y ago

> We've collectively complicated the hell out of things. Yes. > I loved Rails, it made me as a young developer able to finally realize way more ambitious projects than I'd ever done before. I also liked the promise (not implementation) of Meteor - it felt like the clear future, I guess just a bit too early (and a bit too scope-creeped). Meteor and Rails were fundamentally incompatible views of the world, and the root of the "complicated the hell out of things" problem is that the Meteor approach wasn't practical for the vast majority of web development projects. Once you've decided to build everything in the front end and turn the server channel into a glorified database connection, you've created a nightmare for yourself on multiple levels. Setting aside the fact that javascript lacked (lacks?) even the basics of a practical programming language -- real packages and dependency management and the like, all of which needed to be implemented via a panoply of non-standard libraries that have been subsequently re-written every 2.5 weeks -- you're re-inventing wheels (like routing, rendering, cacheing and a request/response paradigm) that the browser does for you, for free. Maybe that's worth it in a few niche cases (say, making a web-based code editor), but for the vast majority of CRUD websites, you're just swimming upstream. Spinning languages and libraries misses the point that the problem is fundamental to the approach. I guess what I'm saying is: lean into your first instinct. It's all too complex. Go back to the root of what makes Rails -- traditional web development, really -- good.

CharlieDigital 2y ago
Given that we're not dumping JS anytime soon, I think that the shortcomings of JS are kind of moot. Once you accept that 1) JS and the ecosystem has a ton of shortcomings, 2) JS isn't going to be replaced on the web for front-end for a while, then I think you can move on and think about things more objectively. I like this project because at this point in 2024, it feels like it should be easier to build and deploy cross platform web/mobile apps (I blame Apple for PWA not taking off). React is not my cup of tea, but if One's mission pans out, then I'd use it to streamline my workflow if I were building across web and mobile. I'd personally prefer PWAs and Apple making it easier to install PWAs as apps since that would make it even easier and more streamlined from a DX perspective. Right now, we all have to jump through these hoops and build this extraneous tooling and infrastructure because of Apple's resistance on installable web apps.
- timr 2y ago
  Nobody said "dump Javascript", and that clearly isn't what I meant [1]. I put that part in only to illustrate that these problems were knowable at the time that Meteor was created. What I am saying is that the paradigms of "modern" front-end development are all wrong. Don't re-invent basic functionalities of the browser. Don't try to turn the web server connection into a glorified database (either by implementing bastardized HTTP-SQL, or by treating the socket as a bidirectional JSON channel). Accept that server-side generation of HTML is fundamental to the medium. Embrace progressive enhancement. I could go on. None of these things requires that you drop JS as your language. If you wanted to build Rails in JS, you totally could [2]. If I had to draw a crude metaphor, the state of web development today would be as if an entirely new generation of engineers decided that TCP was wrong because most stacks are implemented in C, and therefore re-created bad versions of handshakes, etc. by writing a new protocol on top of UDP in Javascript. It's not the language, it's the architecture. [1] Though you absolutely should consider that JS isn't perhaps isn't a great language for most forms of development, and be open to, you know...using better tools when they're available, instead of trying to do everything in the lowest common denominator, while patching over all of the stuff you're missing with gobs and gobs of bad libraries. [2] Though again, why would you want to? I submit that the core cognitive dissonance here is that as soon as you accept that these "modern" paradigms are wrong, you quickly conclude that Javascript is a net burden on your development process. But sure, if you really like it for some reason, then great. You can use it.
  - v1ne 2y ago
    I'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;) I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay). Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps. And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).
bbor 2y ago
To play devil’s/react-dev’s advocate: the appeal of local-first is that you can easily configure which business logic you want done on the server, leaving anything that can be done on the client to the client for latency and cloud bill reasons. javascript lacked (lacks?) even the basics of a practical programming language -- real packages and the like Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? Like, splitting up your code into packages gets you some performance benefit in other languages? I have python packages (read: __init__.py files) in my Flask app, but I’m not sure I’ve ever missed them in TS - am I missing some big picture? In general web bundling is so complex I tend to treat it as a black box, so that could easily be on me. you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free. I’m having trouble seeing what you mean here. I know the typical “implementing an SPA is tough because you have to fake pathname manipulation/history” warnings, but I think you’re going a step beyond that. React does rendering on a way more performant level than browsers if you’re just changing subsets of the DOM, and I’m really not sure what you mean by the “request/response” paradigm at all, sorry. SPAs do have to handle async requests on the client and normal websites make the server do that when building the page, but ultimately the difference seems slight. What am I missing? for the vast majority of CRUD websites I mean, do people making crud websites really need any frameworks, and do they browse hacker news? Aren’t static sites a pretty solved problem by people like WordPress? Seems like the hard part of that would just be writing content and filling templates, maybe some styling — not any engineering work.
- rgbrgb 2y ago
  Agree with you pushing back on the TS hate. The ecosystem and tooling have gotten very mature and very productive IMO for building UIs. However, static sites are by definition not CRUD sites and yes I would guess most HN web devs make CRUD sites. And I would submit that in 2024 there is still not a rails-level happy path for doing that in ts (though Redwood is trying).
- timr 2y ago
  > Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? The very fact that you cite Typescript (itself a hack built on top of Javascript to make up for its deficiencies), and npm (a third-party packaging system...since, you know...JS doesn't/didn't have one), is just emphasizing my point. Setting aside the goodness or badness of either of these things, you're so immersed in the complexity of all of the hacks that you don't even see it anymore. It's the old joke about the fish and water. Imagine a world where packages and types were a built-in, first-class feature of the language...oh wait.
nwienert 2y ago
100% honest as someone who loved Rails - i really love building with react and tamagui if you put together the right tooling. 95% of apps people glue together are quite bad so i get that some people see it as a lost cause, but i could never go back, it's clearly better to me but only if you do manage to have the time to put together a great stack. once zero is released i'd be interested to see your opinion of trying it out.

by timr 2y ago

CharlieDigital 2y ago

Given that we're not dumping JS anytime soon, I think that the shortcomings of JS are kind of moot. Once you accept that 1) JS and the ecosystem has a ton of shortcomings, 2) JS isn't going to be replaced on the web for front-end for a while, then I think you can move on and think about things more objectively. I like this project because at this point in 2024, it feels like it should be easier to build and deploy cross platform web/mobile apps (I blame Apple for PWA not taking off). React is not my cup of tea, but if One's mission pans out, then I'd use it to streamline my workflow if I were building across web and mobile. I'd personally prefer PWAs and Apple making it easier to install PWAs as apps since that would make it even easier and more streamlined from a DX perspective. Right now, we all have to jump through these hoops and build this extraneous tooling and infrastructure because of Apple's resistance on installable web apps.

timr 2y ago
Nobody said "dump Javascript", and that clearly isn't what I meant [1]. I put that part in only to illustrate that these problems were knowable at the time that Meteor was created. What I am saying is that the paradigms of "modern" front-end development are all wrong. Don't re-invent basic functionalities of the browser. Don't try to turn the web server connection into a glorified database (either by implementing bastardized HTTP-SQL, or by treating the socket as a bidirectional JSON channel). Accept that server-side generation of HTML is fundamental to the medium. Embrace progressive enhancement. I could go on. None of these things requires that you drop JS as your language. If you wanted to build Rails in JS, you totally could [2]. If I had to draw a crude metaphor, the state of web development today would be as if an entirely new generation of engineers decided that TCP was wrong because most stacks are implemented in C, and therefore re-created bad versions of handshakes, etc. by writing a new protocol on top of UDP in Javascript. It's not the language, it's the architecture. [1] Though you absolutely should consider that JS isn't perhaps isn't a great language for most forms of development, and be open to, you know...using better tools when they're available, instead of trying to do everything in the lowest common denominator, while patching over all of the stuff you're missing with gobs and gobs of bad libraries. [2] Though again, why would you want to? I submit that the core cognitive dissonance here is that as soon as you accept that these "modern" paradigms are wrong, you quickly conclude that Javascript is a net burden on your development process. But sure, if you really like it for some reason, then great. You can use it.
- v1ne 2y ago
  I'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;) I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay). Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps. And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).

bbor 2y ago

To play devil’s/react-dev’s advocate: the appeal of local-first is that you can easily configure which business logic you want done on the server, leaving anything that can be done on the client to the client for latency and cloud bill reasons. javascript lacked (lacks?) even the basics of a practical programming language -- real packages and the like Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? Like, splitting up your code into packages gets you some performance benefit in other languages? I have python packages (read: __init__.py files) in my Flask app, but I’m not sure I’ve ever missed them in TS - am I missing some big picture? In general web bundling is so complex I tend to treat it as a black box, so that could easily be on me. you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free. I’m having trouble seeing what you mean here. I know the typical “implementing an SPA is tough because you have to fake pathname manipulation/history” warnings, but I think you’re going a step beyond that. React does rendering on a way more performant level than browsers if you’re just changing subsets of the DOM, and I’m really not sure what you mean by the “request/response” paradigm at all, sorry. SPAs do have to handle async requests on the client and normal websites make the server do that when building the page, but ultimately the difference seems slight. What am I missing? for the vast majority of CRUD websites I mean, do people making crud websites really need any frameworks, and do they browse hacker news? Aren’t static sites a pretty solved problem by people like WordPress? Seems like the hard part of that would just be writing content and filling templates, maybe some styling — not any engineering work.

rgbrgb 2y ago
Agree with you pushing back on the TS hate. The ecosystem and tooling have gotten very mature and very productive IMO for building UIs. However, static sites are by definition not CRUD sites and yes I would guess most HN web devs make CRUD sites. And I would submit that in 2024 there is still not a rails-level happy path for doing that in ts (though Redwood is trying).
timr 2y ago
> Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? The very fact that you cite Typescript (itself a hack built on top of Javascript to make up for its deficiencies), and npm (a third-party packaging system...since, you know...JS doesn't/didn't have one), is just emphasizing my point. Setting aside the goodness or badness of either of these things, you're so immersed in the complexity of all of the hacks that you don't even see it anymore. It's the old joke about the fish and water. Imagine a world where packages and types were a built-in, first-class feature of the language...oh wait.

nwienert 2y ago

100% honest as someone who loved Rails - i really love building with react and tamagui if you put together the right tooling. 95% of apps people glue together are quite bad so i get that some people see it as a lost cause, but i could never go back, it's clearly better to me but only if you do manage to have the time to put together a great stack. once zero is released i'd be interested to see your opinion of trying it out.