7 ms·

I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were

I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.

tvaughan 6y ago
Couldn’t have come soon enough. I’m exhausted
rorykoehler 6y ago
I’m glad I’m not the only one who thought this.
blorenz 6y ago
You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.
- epistasis 6y ago
  I'm not a front end engineer, but it always seemed crazy to me. I remember testing out the Google Web Toolkit when it came out more than a decade ago, and the craziest thing about it to me wasn't the Java --> JavaScript compilation, it was that the server just dumped an empty page and filled everything in with JavaScript on the client. Then, remember the awful awful #! URLs? Atrocious, and seemed like obviously a terrible idea from the start, yet they spread, and have mostly died, thankfully. But even with the lessons from these bad tech designs, new frameworks come out that repeat mistakes, yet get incredible hype.
  - Twirrim 6y ago
    AWS used to rely on JWT for their consoles (haven't for a few years now, most folks migrated away some 5 years ago) It's why they used to be horrendously bloated with large javascript bundles that took so long to process on the client side. Roughly speaking the idea was "We don't have any Javascript developers, but we do have Java developers. JWT allows us to bridge that divide". Neat in theory, and an understandable decision, but diabolical in practice!
    - solarengineer 6y ago
      I believe you mean “GWT” and not “JWT”.
      - Twirrim 6y ago
        Yup you're right, that was quite a brainfart :)
  - filmor 6y ago
    Hashbang URLs are gone because of the PushState API, not because people have given up on the idea.
    - epistasis 6y ago
      Hashbangs preclude even the option of the server even seeing the state that the client wants from the first request, necessitating severa hops. PushState, though it allows URL transitions without a full reload, is an entirely better and different idea.
  - mruniverse 6y ago
    Around the time that GWT came out, offshoring was a big thing. And most of the contractors only knew Java. Also Java was the trusted language and javascript was not.
    - bryanrasmussen 6y ago
      The only big GWT project I've ever been on was a governmental project that I won't go into (because it's Danish and I would have to describe a bunch of stuff that everyone in Denmark knows and nobody outside would probably care about), but the company providing it was porting their Java version to JavaScript and had a significantly large codebase to leverage.
- Twirrim 6y ago
  > You have the benefit of hindsight at this time. People have been pointing out it's a shit show with no end in sight for the entire duration of the phase. Pointing out the performance impact and cost to end users, how diabolical it is for those on lower latency or poorer network connectivity (i.e. most of the world), and so on. Same thing as always happens with these pendulum swings, newer engineers come in convinced everyone before them is an idiot, are capable of building their new thing and hyping it up such that other newer engineers are sold on it while the "old guard" effectively says "please listen to me, there's good reasons why we don't do it this way" and get ignored. Worse, they'll get told they're wrong, only to be proven right all along. I'm not denying there are obstructionist greybeard types that just refuse to acknowledge merits in new approaches, but any and all critique is written off as being cut from the same cloth. It's perfectly possible to iterate on new ideas and approaches while not throwing away what we've spent decades learning ('Those who do not learn history are doomed to repeat it'), but tech just seems especially determined not to grow up.
  - freeopinion 6y ago
    I guess I've become a grey beard. I've done the whole journey from CGI everything to a bit of js to SPA. As much as I'd really like to be nostalgic about the good old days, there are reasons everything got pushed into the client. One of those reasons is maintaining state. "HTML over the wire" isn't really a return to the good ol' days. It's still the client maintaining state and using tons of js to move data back and forth without page reloads. It just changes the nature of 1/2 the data and moves the burden of templating back to the server. It is amusing that they make a claim that reads a lot like "eliminate 80% of your Javascript and replace it with Stimulus". What is Stimulus? A Javascript framework.
    - combatentropy 6y ago
      They mean JavaScript that you write.
- Cederfjard 6y ago
  Very true. I think that mostly, web dev mainstream has taken a rational path. It’s with the benefit of hindsight as you say, or the yoke of unusual requirements, that people now say ”we did it all wrong”.
- robmurrer 6y ago
  except we could fly before ;D
philote 6y ago
Same. And I'm still amazed that people loved JS so much they put it on the SERVER too! And now node/npm is everywhere.
- Scarbutt 6y ago
  Node has a better runtime than ruby or python, so why not? and you also have TS.
  - mhh__ 6y ago
    The node runtime is actually pretty quick (It's roughly as fast as an optimizing compiler from 10-15 years ago, give or take, which is fairly impressive), but even TS is still makeup on a wart - you can't escape JS's more bizarre semantics that easily.
- maccard 6y ago
  I think it's less about loving JS so much, and more about not having any options on the client. If there were any better client options they might have won!
- mhh__ 6y ago
  I think a huge amount of that success is because JS is cheap to hire, i.e. Node is fast enough so why bother using a good language (cynically). Anecdotally, most people I see who really really love JavaScript are kids who haven't really don't much else.
  - qudat 6y ago
    Yikes, what a condescending comment. I’d argue why this comment is beyond misguided but I’d be wasting my time.
- Lio 6y ago
  Server side javascript was one of its original intended uses. Here's the Netscape Enterprise Server manual from 1998[1]. Sorry I couldn't find an earlier version. 1. https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10.pdf https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10...
some1else 6y ago
> The last 10 years of JavaScript on the client have been an utter shit show A fair number of people would disagree. I'd say it's advanced a lot, considering the limited role of JavaScript on the client in the past.
devwastaken 6y ago
Yeah people shouldn't make applications in programming languages. If your application can't be made with html/css then it's bloatware. All this java, .net and C are totally unnecessary.
- Trasmatta 6y ago
  Literally nobody is saying this
  - devwastaken 6y ago
    They are, look at the context of what they're saying. JS is simply a programming language in a VM like plenty of others, there's nothing inherently bad about it. But every thread here's the uneducated hate for it, completely misunderstanding that html/css static pages don't solve the problems a programming language does. I'd like to see these people make applications in pure XML. No programming.
    - Trasmatta 6y ago
      No, the argument has never been "replace all JS with static HTML/CSS". The argument is "JavaScript frontends are becoming unnecessarily bloated, slow, and complicated, and we can do better". Solutions like the one Basecamp is proposing with Hotwire include pushing as much rendering logic as possible to the server, where you're using a language like Ruby for logic. Nobody thinks you can just remove all logic from a web application unless it's literally just static content. And even with Hotwire, you're not getting rid of JavaScript entirely. You can write it with Stimulus. The idea is just that frontend web development has become a mess, and it's possible to simplify things. > there's nothing inherently bad about it Disagree.
      - qudat 6y ago
        “Bloated.” This is actually the opposite. Go into a language like python and install numpy (30mb) and then come back to complain to me about a 2mb js bundle. This argument is so bogus if you look at alternative language dependency sizes.

I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.

tvaughan 6y ago

Couldn’t have come soon enough. I’m exhausted

rorykoehler 6y ago

I’m glad I’m not the only one who thought this.

blorenz 6y ago

You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.

epistasis 6y ago
I'm not a front end engineer, but it always seemed crazy to me. I remember testing out the Google Web Toolkit when it came out more than a decade ago, and the craziest thing about it to me wasn't the Java --> JavaScript compilation, it was that the server just dumped an empty page and filled everything in with JavaScript on the client. Then, remember the awful awful #! URLs? Atrocious, and seemed like obviously a terrible idea from the start, yet they spread, and have mostly died, thankfully. But even with the lessons from these bad tech designs, new frameworks come out that repeat mistakes, yet get incredible hype.
- Twirrim 6y ago
  AWS used to rely on JWT for their consoles (haven't for a few years now, most folks migrated away some 5 years ago) It's why they used to be horrendously bloated with large javascript bundles that took so long to process on the client side. Roughly speaking the idea was "We don't have any Javascript developers, but we do have Java developers. JWT allows us to bridge that divide". Neat in theory, and an understandable decision, but diabolical in practice!
  - solarengineer 6y ago
    I believe you mean “GWT” and not “JWT”.
    - Twirrim 6y ago
      Yup you're right, that was quite a brainfart :)
- filmor 6y ago
  Hashbang URLs are gone because of the PushState API, not because people have given up on the idea.
  - epistasis 6y ago
    Hashbangs preclude even the option of the server even seeing the state that the client wants from the first request, necessitating severa hops. PushState, though it allows URL transitions without a full reload, is an entirely better and different idea.
- mruniverse 6y ago
  Around the time that GWT came out, offshoring was a big thing. And most of the contractors only knew Java. Also Java was the trusted language and javascript was not.
  - bryanrasmussen 6y ago
    The only big GWT project I've ever been on was a governmental project that I won't go into (because it's Danish and I would have to describe a bunch of stuff that everyone in Denmark knows and nobody outside would probably care about), but the company providing it was porting their Java version to JavaScript and had a significantly large codebase to leverage.
Twirrim 6y ago
> You have the benefit of hindsight at this time. People have been pointing out it's a shit show with no end in sight for the entire duration of the phase. Pointing out the performance impact and cost to end users, how diabolical it is for those on lower latency or poorer network connectivity (i.e. most of the world), and so on. Same thing as always happens with these pendulum swings, newer engineers come in convinced everyone before them is an idiot, are capable of building their new thing and hyping it up such that other newer engineers are sold on it while the "old guard" effectively says "please listen to me, there's good reasons why we don't do it this way" and get ignored. Worse, they'll get told they're wrong, only to be proven right all along. I'm not denying there are obstructionist greybeard types that just refuse to acknowledge merits in new approaches, but any and all critique is written off as being cut from the same cloth. It's perfectly possible to iterate on new ideas and approaches while not throwing away what we've spent decades learning ('Those who do not learn history are doomed to repeat it'), but tech just seems especially determined not to grow up.
- freeopinion 6y ago
  I guess I've become a grey beard. I've done the whole journey from CGI everything to a bit of js to SPA. As much as I'd really like to be nostalgic about the good old days, there are reasons everything got pushed into the client. One of those reasons is maintaining state. "HTML over the wire" isn't really a return to the good ol' days. It's still the client maintaining state and using tons of js to move data back and forth without page reloads. It just changes the nature of 1/2 the data and moves the burden of templating back to the server. It is amusing that they make a claim that reads a lot like "eliminate 80% of your Javascript and replace it with Stimulus". What is Stimulus? A Javascript framework.
  - combatentropy 6y ago
    They mean JavaScript that you write.
Cederfjard 6y ago
Very true. I think that mostly, web dev mainstream has taken a rational path. It’s with the benefit of hindsight as you say, or the yoke of unusual requirements, that people now say ”we did it all wrong”.
robmurrer 6y ago
except we could fly before ;D

philote 6y ago

Same. And I'm still amazed that people loved JS so much they put it on the SERVER too! And now node/npm is everywhere.

Scarbutt 6y ago
Node has a better runtime than ruby or python, so why not? and you also have TS.
- mhh__ 6y ago
  The node runtime is actually pretty quick (It's roughly as fast as an optimizing compiler from 10-15 years ago, give or take, which is fairly impressive), but even TS is still makeup on a wart - you can't escape JS's more bizarre semantics that easily.
maccard 6y ago
I think it's less about loving JS so much, and more about not having any options on the client. If there were any better client options they might have won!
mhh__ 6y ago
I think a huge amount of that success is because JS is cheap to hire, i.e. Node is fast enough so why bother using a good language (cynically). Anecdotally, most people I see who really really love JavaScript are kids who haven't really don't much else.
- qudat 6y ago
  Yikes, what a condescending comment. I’d argue why this comment is beyond misguided but I’d be wasting my time.
Lio 6y ago
Server side javascript was one of its original intended uses. Here's the Netscape Enterprise Server manual from 1998[1]. Sorry I couldn't find an earlier version. 1. https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10.pdf https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10...

some1else 6y ago

> The last 10 years of JavaScript on the client have been an utter shit show A fair number of people would disagree. I'd say it's advanced a lot, considering the limited role of JavaScript on the client in the past.

devwastaken 6y ago

Yeah people shouldn't make applications in programming languages. If your application can't be made with html/css then it's bloatware. All this java, .net and C are totally unnecessary.

Trasmatta 6y ago
Literally nobody is saying this
- devwastaken 6y ago
  They are, look at the context of what they're saying. JS is simply a programming language in a VM like plenty of others, there's nothing inherently bad about it. But every thread here's the uneducated hate for it, completely misunderstanding that html/css static pages don't solve the problems a programming language does. I'd like to see these people make applications in pure XML. No programming.
  - Trasmatta 6y ago
    No, the argument has never been "replace all JS with static HTML/CSS". The argument is "JavaScript frontends are becoming unnecessarily bloated, slow, and complicated, and we can do better". Solutions like the one Basecamp is proposing with Hotwire include pushing as much rendering logic as possible to the server, where you're using a language like Ruby for logic. Nobody thinks you can just remove all logic from a web application unless it's literally just static content. And even with Hotwire, you're not getting rid of JavaScript entirely. You can write it with Stimulus. The idea is just that frontend web development has become a mess, and it's possible to simplify things. > there's nothing inherently bad about it Disagree.
    - qudat 6y ago
      “Bloated.” This is actually the opposite. Go into a language like python and install numpy (30mb) and then come back to complain to me about a 2mb js bundle. This argument is so bogus if you look at alternative language dependency sizes.