8 ms·

The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago. I g

The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago. I genuinely don’t understand it.

FpUser 5y ago
>"I genuinely don’t understand it." There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".
- still_grokking 5y ago
  Some, especially younger folks, sadly just don't know better. Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times. Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end! Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
  - FpUser 5y ago
    >"Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly"" I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI. As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps. JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
    - denton-scratch 5y ago
      > Personally I've started with straight machine codes, never mind assembly. Me too - the first computer I used was an IBM Schools Computer. This was a thing a bit like an Apple I or something, but it had no assembler, no editor, no OS. To load a program, you typed it directly into memory in hex. I think (this was a long time ago) it contained an 8080. It had a TV output, and an integrated keyboard with flat membrane "keys". There was no storage - you had to copy stuff off the screen using a pencil and paper. I expect it cost a small fortune. [Edit] Apparently it wasn't an 8080, and it didn't take input/produce output in hex - it used decimal. https://books.google.co.uk/books?id=2kMIqdfyT8kC&pg=PA242&lpg=PA242&dq=%22ibm+schools+computer%22&source=bl&ots=Mn5urgJCCG&sig=ACfU3U2z6ozWe3Ap4ZkbarXywvKTxMh-pA&hl=en&sa=X&ved=2ahUKEwjX_5fEran0AhVJ-qQKHUMYBnIQ6AF6BAgnEAM#v=onepage&q=%22ibm%20schools%20computer%22&f=false https://books.google.co.uk/books?id=2kMIqdfyT8kC&pg=PA242&lp... I can't find much info about that thing.
whoknowswhat11 5y ago
Yep - we did a largish (300K user) site 18 years ago in PHP and static HTML. Was pretty high scale at the time with a lot of complexity and state (mysql with read replicas at the time). We didn't have concurrency totally solved but it wasn't critical and the thing ran great. If you looked at the html so so simple. HTML / CSS. I don't even think we did javascript at the time? The toolchains now to just do the most basic form with a submit button - it's wild.
- memco 5y ago
  > The toolchains now to just do the most basic form with a submit button Oh how I long for a submit button and a form. I’ve worked on code where there’s just a bunch of divs and input fields: no form no action, no fieldsets, no labels, no submit button. I do not have words for the emotions it causes.
- still_grokking 5y ago
  And don't forget what you paid back then for hosting. Compare to all those Kubernetes clusters on the cloud for all those microservices that are totally needed today to operate such a large site for one third of a million users correctly. And maybe it would make even sense to talk about build and deployment times back than.
  - d00bianista 5y ago
    Back in the day... I used to maintain and manually scale a platform that ran a regionally large social site. It was written in PHP, by two geeks in a dorm, served by Apache and had a single MySQL database and host, in a respectable datacenter. At it's greatest moment, it had a pair of keepalived-hosts in front of around 7 Apache hosts and still that single database host. That was expensive, but not in maintenance. The amount of moving parts in that, compared to all the doohickeys of modern times, seems like 1:100. As someone who understands very little of modern web-doohickeys, I'm very afraid of the direction we are going in and it seems like my job-security is quite high, because schools don't produce infrastructure people any more... Just happy-go-lucky developers who know how to run things on top of a credit card, on someone else's computer.
deleted 5y ago
[deleted]
miki_tyler 5y ago
If only standard HTML would support templating we could get rid of 80% of the tooling, maybe 100%. In fact, if I had to choose between two super simple tech stacks for static sites: 1) HTML + CSS + JS 2) HTML + CSS + Templating system I would pick 2) for sure. This is basically why we are building kit55 (https://stack55.com https://stack55.com).
- vbezhenar 5y ago
  HTML supports some mechanisms to implement templates: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...
  - miki_tyler 5y ago
    There is indeed a <template> tag in HTML but it only works inside the current loaded page, i.e. to render rows inside a table. You cannot use it to include a header or a banner. In addition, the the tag relies on JS to be rendered.
zmmmmm 5y ago
My analogy for you is a house that was built 6 inches to the right of where it should be. It's almost perfectly good. You can live in it. But there are these niggling things wrong. They will always be wrong. Over time, enough people say "hey if we just do this work, get this done, we can move the house". So finally some people actually do it - they move the house, brick by brick, 6 inches to the left. And hence end up with Webpack and npm and 1gb of node_modules etc etc. And the house is now 6 inches to the left. To many it looks identical to how it did before. But for those to whom it really matters - people who's quality of life depends a lot on exactly where the house is - it is a massive difference. So many small things are just now better - aligned with what we really needed to start with. Whether it's the automatic reactive updating dev server, the fact I can embed CSS directly with my component and have it scoped there, or that I can use properly DRY CSS, or that I can unit test my code separate to the DOM, that I can build my pages in a truly "functional" way such that they are free from complex state bugs ... all these things are small ... but big.
- 1123581321 5y ago
  And to take this analogy further, adding HTMX to a traditional web framework or switching to Phoenix LiveView is like jacking up the whole house and moving it to a better spot in an afternoon, which is what my coworker’s family did to their first home the week they bought it after moving to the US. If you don’t know it can’t be done…
  - dreyfan 5y ago
    Phoenix Liveview is far more similar to a python or ruby app. You just have a websocket keeping things synced perfectly and maintaining state. It’s awesome, yes, but it’s quite orthogonal to the nodejs/npm way of doing things. It’s far better.
    - 1123581321 5y ago
      I'm a big fan. :) I think many people would be happier making 'real-time' apps with the approach than with a messy JS stack.

The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago. I genuinely don’t understand it.

FpUser 5y ago

>"I genuinely don’t understand it." There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".

still_grokking 5y ago
Some, especially younger folks, sadly just don't know better. Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times. Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end! Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
- FpUser 5y ago
  >"Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly"" I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI. As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps. JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
  - denton-scratch 5y ago
    > Personally I've started with straight machine codes, never mind assembly. Me too - the first computer I used was an IBM Schools Computer. This was a thing a bit like an Apple I or something, but it had no assembler, no editor, no OS. To load a program, you typed it directly into memory in hex. I think (this was a long time ago) it contained an 8080. It had a TV output, and an integrated keyboard with flat membrane "keys". There was no storage - you had to copy stuff off the screen using a pencil and paper. I expect it cost a small fortune. [Edit] Apparently it wasn't an 8080, and it didn't take input/produce output in hex - it used decimal. https://books.google.co.uk/books?id=2kMIqdfyT8kC&pg=PA242&lpg=PA242&dq=%22ibm+schools+computer%22&source=bl&ots=Mn5urgJCCG&sig=ACfU3U2z6ozWe3Ap4ZkbarXywvKTxMh-pA&hl=en&sa=X&ved=2ahUKEwjX_5fEran0AhVJ-qQKHUMYBnIQ6AF6BAgnEAM#v=onepage&q=%22ibm%20schools%20computer%22&f=false https://books.google.co.uk/books?id=2kMIqdfyT8kC&pg=PA242&lp... I can't find much info about that thing.

whoknowswhat11 5y ago

Yep - we did a largish (300K user) site 18 years ago in PHP and static HTML. Was pretty high scale at the time with a lot of complexity and state (mysql with read replicas at the time). We didn't have concurrency totally solved but it wasn't critical and the thing ran great. If you looked at the html so so simple. HTML / CSS. I don't even think we did javascript at the time? The toolchains now to just do the most basic form with a submit button - it's wild.

memco 5y ago
> The toolchains now to just do the most basic form with a submit button Oh how I long for a submit button and a form. I’ve worked on code where there’s just a bunch of divs and input fields: no form no action, no fieldsets, no labels, no submit button. I do not have words for the emotions it causes.
still_grokking 5y ago
And don't forget what you paid back then for hosting. Compare to all those Kubernetes clusters on the cloud for all those microservices that are totally needed today to operate such a large site for one third of a million users correctly. And maybe it would make even sense to talk about build and deployment times back than.
- d00bianista 5y ago
  Back in the day... I used to maintain and manually scale a platform that ran a regionally large social site. It was written in PHP, by two geeks in a dorm, served by Apache and had a single MySQL database and host, in a respectable datacenter. At it's greatest moment, it had a pair of keepalived-hosts in front of around 7 Apache hosts and still that single database host. That was expensive, but not in maintenance. The amount of moving parts in that, compared to all the doohickeys of modern times, seems like 1:100. As someone who understands very little of modern web-doohickeys, I'm very afraid of the direction we are going in and it seems like my job-security is quite high, because schools don't produce infrastructure people any more... Just happy-go-lucky developers who know how to run things on top of a credit card, on someone else's computer.

deleted 5y ago

[deleted]

miki_tyler 5y ago

If only standard HTML would support templating we could get rid of 80% of the tooling, maybe 100%. In fact, if I had to choose between two super simple tech stacks for static sites: 1) HTML + CSS + JS 2) HTML + CSS + Templating system I would pick 2) for sure. This is basically why we are building kit55 (https://stack55.com https://stack55.com).

vbezhenar 5y ago
HTML supports some mechanisms to implement templates: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...
- miki_tyler 5y ago
  There is indeed a <template> tag in HTML but it only works inside the current loaded page, i.e. to render rows inside a table. You cannot use it to include a header or a banner. In addition, the the tag relies on JS to be rendered.

zmmmmm 5y ago

My analogy for you is a house that was built 6 inches to the right of where it should be. It's almost perfectly good. You can live in it. But there are these niggling things wrong. They will always be wrong. Over time, enough people say "hey if we just do this work, get this done, we can move the house". So finally some people actually do it - they move the house, brick by brick, 6 inches to the left. And hence end up with Webpack and npm and 1gb of node_modules etc etc. And the house is now 6 inches to the left. To many it looks identical to how it did before. But for those to whom it really matters - people who's quality of life depends a lot on exactly where the house is - it is a massive difference. So many small things are just now better - aligned with what we really needed to start with. Whether it's the automatic reactive updating dev server, the fact I can embed CSS directly with my component and have it scoped there, or that I can use properly DRY CSS, or that I can unit test my code separate to the DOM, that I can build my pages in a truly "functional" way such that they are free from complex state bugs ... all these things are small ... but big.

1123581321 5y ago
And to take this analogy further, adding HTMX to a traditional web framework or switching to Phoenix LiveView is like jacking up the whole house and moving it to a better spot in an afternoon, which is what my coworker’s family did to their first home the week they bought it after moving to the US. If you don’t know it can’t be done…
- dreyfan 5y ago
  Phoenix Liveview is far more similar to a python or ruby app. You just have a websocket keeping things synced perfectly and maintaining state. It’s awesome, yes, but it’s quite orthogonal to the nodejs/npm way of doing things. It’s far better.
  - 1123581321 5y ago
    I'm a big fan. :) I think many people would be happier making 'real-time' apps with the approach than with a messy JS stack.