4 ms·

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I do

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style, and function) and not have issues with load or speed. I'm not sure if there's a footgun here, but the issue falls squarely on the developers.

eeeeeeeeeeeee 8y ago
Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.
- ddoolin 8y ago
  Couldn't agree more. Anybody sitting down to start a _serious_ project should spend some time possibly researching and definitely planning, which would hopefully lead to the right decision here.
- mrec 8y ago
  "people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is. There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance, stability, maturity, state of tooling, community, training resources and a zillion others. How do you balance all those? Wait, let me guess, "correctly". Sorry about the snark, this has just been a personal peeve of mine ever since the Slashdot days, when any word salad whatsoever would get upvoted Insightful provided it contained the magic phrase "right tool for the job".
  - ddoolin 8y ago
    It wasn't posited as advice to a specific question, but rather a guiding principle, which is still valid and bears repeating given the frequency of the mistake.
  - incadenza 8y ago
    It’s a quip used to remind people to work backwards from the problem they’re trying to solve, not the other way around. I think it’s an appropriate response to blanket advice on choice of tech stacks.
  - eeeeeeeeeeeee 8y ago
    I don’t deny any of those things. I think you’re reading way too much into my statement. I understand why people pick familiar tools and the cost of hiring and training people and getting up to speed on new stuff. It’s always a balance, and it’s why I don’t really like these posts that completely dismiss JavaScript and act like it has zero benefits. I was on a team recently that only wanted to do Rails apps. They only wanted to make monolithic apps. Any mention of a more modular design would be met with derision. I don’t think this attitude is unique, though. And it’s really hard to overcome and see balance when the entire team clearly has no interest in changing or updating their skill set.
smokeyj 8y ago
The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day. If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line. In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE
- lhorie 8y ago
  > I could have gotten the same benefits with SSR and ported it to react native Are you saying that rhetorically? In my experience, React is no silver bullet (e.g. different router and styling mechanisms for RN), trickiness dealing w/ timezones in SSR, etc. And besides, the point here was largely about bundle size and fast time-to-interactive. Next.js optimizes a lot for developer experience, but you're definitely still going to be shipping a pretty sizeable JS bundle with slower characteristics than a hand-coded "closer-to-the-metal" thing.
  - smokeyj 8y ago
    > Are you saying that rhetorically? No. > And besides, the point here was largely about bundle size and fast time-to-interactive. As long as the point wasn't to be productive I'll just mind my own business.
- tomca32 8y ago
  > Author could have installed next.js and called it a day. Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed. Javascript apps are tremendously complex, why would do this if you don't have to?
  - smokeyj 8y ago
    Imagine you have a team of rails developers and you're asked to create a simple portal. Rails as a tool may be "overkill" but what does it matter? If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..

eeeeeeeeeeeee 8y ago

Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.

ddoolin 8y ago
Couldn't agree more. Anybody sitting down to start a _serious_ project should spend some time possibly researching and definitely planning, which would hopefully lead to the right decision here.
mrec 8y ago
"people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is. There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance, stability, maturity, state of tooling, community, training resources and a zillion others. How do you balance all those? Wait, let me guess, "correctly". Sorry about the snark, this has just been a personal peeve of mine ever since the Slashdot days, when any word salad whatsoever would get upvoted Insightful provided it contained the magic phrase "right tool for the job".
- ddoolin 8y ago
  It wasn't posited as advice to a specific question, but rather a guiding principle, which is still valid and bears repeating given the frequency of the mistake.
- incadenza 8y ago
  It’s a quip used to remind people to work backwards from the problem they’re trying to solve, not the other way around. I think it’s an appropriate response to blanket advice on choice of tech stacks.
- eeeeeeeeeeeee 8y ago
  I don’t deny any of those things. I think you’re reading way too much into my statement. I understand why people pick familiar tools and the cost of hiring and training people and getting up to speed on new stuff. It’s always a balance, and it’s why I don’t really like these posts that completely dismiss JavaScript and act like it has zero benefits. I was on a team recently that only wanted to do Rails apps. They only wanted to make monolithic apps. Any mention of a more modular design would be met with derision. I don’t think this attitude is unique, though. And it’s really hard to overcome and see balance when the entire team clearly has no interest in changing or updating their skill set.

smokeyj 8y ago

The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day. If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line. In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE

lhorie 8y ago
> I could have gotten the same benefits with SSR and ported it to react native Are you saying that rhetorically? In my experience, React is no silver bullet (e.g. different router and styling mechanisms for RN), trickiness dealing w/ timezones in SSR, etc. And besides, the point here was largely about bundle size and fast time-to-interactive. Next.js optimizes a lot for developer experience, but you're definitely still going to be shipping a pretty sizeable JS bundle with slower characteristics than a hand-coded "closer-to-the-metal" thing.
- smokeyj 8y ago
  > Are you saying that rhetorically? No. > And besides, the point here was largely about bundle size and fast time-to-interactive. As long as the point wasn't to be productive I'll just mind my own business.
tomca32 8y ago
> Author could have installed next.js and called it a day. Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed. Javascript apps are tremendously complex, why would do this if you don't have to?
- smokeyj 8y ago
  Imagine you have a team of rails developers and you're asked to create a simple portal. Rails as a tool may be "overkill" but what does it matter? If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..