4 ms·

Crazy to me how far we’ve come from HTML and some script tags. Part of me is really sad that the web is big and complicated and ugly now. I just don’t have the

Crazy to me how far we’ve come from HTML and some script tags. Part of me is really sad that the web is big and complicated and ugly now. I just don’t have the patience to read some new framework author’s long winded and grandiose tutorial and ode to themselves. Why is it so hard to do seemingly simple things? I can remember 10 years ago training up someone with no programming experience at all to competency in a few weeks, on the job. They had to learn HTML, some CSS, Perl, and JavaScript was left for extra credit. Something is very, very wrong if you now need to master dozens of technologies to add the same value to the world you used to be able to 10 years ago without so much effort. And before someone says it the applications were of similar complexity and scope to today’s SPA behomths. Too many cooks in the kitchen!

fastball 8y ago
Are you implying that the websites being built in 2008 were as sophisticated and complex as the sites in 2018? Have you considered technologies like React Native which mean you don't need to maintain 4 different entirely separate codebases for your 4 different frontends?
- mosdl 8y ago
  And instead we have a 1 bloated codebase that is slow on 3 platforms and doesn't provide native features? The fascination with 1 codebase doing multiple things is funny.
  - fastball 8y ago
    You're acting as if React makes it impossible to do anything else. As needs to be iterated every time we have one of these threads: you're still free to do it the "old way" -- writing your backend in X lang, your iPhone app in Swift, your Desktop apps in C++, your Android app in Java, and your web frontend in HTML/SASS/JS/jQuery. Nobody is stopping you. The truth is that people want their apps on multiple devices these days, and many apps wouldn't exist without react, at least not a port for your platform of choice. Yes, React sacrifices convenience for performance, but that has always been a trade-off. You'll notice very few people writing apps in C these days. That being said: What native features are you lacking? What apps are you using that are noticeably slower than native alternatives? My main complaint with React Native is the memory usage, but that is getting better and better and my computer has tons of RAM these days.
    - mosdl 8y ago
      React (or vdom in general) has high memory costs and won't be close to native performance anytime soon (or ever). As long as you are cognizant about the trade offs it can be the right choice, but never blind. People forget the old applet days.
  - Scooty 8y ago
    > The fascination with 1 codebase doing multiple things is funny. Isn't it baked into most programmer's best-practices? Don't repeat yourself? Writing two programs that do the same thing doesn't sound very DRY.
    - mosdl 8y ago
      Each solution has pros and cons, and engineering is really about making those choices and dealing with the repercussions.
tptacek 8y ago
Modern programming languages are a lot more featureful and sophisticated than assembly language, and they change a lot more than instruction set architectures do. How is your lament different than that of an assembly language programmer, who might complain "crazy how far we've come from conditional jumps and some stack manipulation"? I'm 41 and got started in the 1990s, and those assembly advocates really did exist. What makes you think that 20 years from now people won't have a hard time believing that anyone could have advocated "just HTML and some script tags" over modern development practices?
- pvg 8y ago
  The assembly people were cranks even in the 90s whereas this complaint, even when put inartfully or outright inaccurately is not completely nuts. In 20 years, people will hopefully wonder how it was that every runtime (or even framework) came with its own set (or multiple sets) of dependency management, build, test and god-knows-what-else toolchains that that do almost but not entirely the same thing as every other one.
- tedunangst 8y ago
  There was a time when compiled languages compiled into a somewhat predictable finite sequence of machine instruction, and thus one might use them but still understand everything happening. I think that is less true of modern web frameworks.
  - pvg 8y ago
    You probably didn't reach for disassembly dumps of some half-assed mid-90s C++ compiler to figure out why it's spewing 37 screens of error messages on some innocent-looking STL thing. Or maybe you did! But I'm not convinced 'rate of encounter with annoyingly incomprehensible magic' has really changed all that much since then.
Scooty 8y ago
It's really not that complex when you understand the reason for these tools, and you don't need to know all or even most of them. You learn them as you encounter the problems they were built to solve (or once the problem becomes too burdensome to manage with a simpler solution). Until then, you don't need to learn anything. OP's roadmap should include some information about why each tool is useful. Without that, it's like someone telling you how to become a mechanic by giving you a list of tools to buy.

fastball 8y ago

Are you implying that the websites being built in 2008 were as sophisticated and complex as the sites in 2018? Have you considered technologies like React Native which mean you don't need to maintain 4 different entirely separate codebases for your 4 different frontends?

mosdl 8y ago
And instead we have a 1 bloated codebase that is slow on 3 platforms and doesn't provide native features? The fascination with 1 codebase doing multiple things is funny.
- fastball 8y ago
  You're acting as if React makes it impossible to do anything else. As needs to be iterated every time we have one of these threads: you're still free to do it the "old way" -- writing your backend in X lang, your iPhone app in Swift, your Desktop apps in C++, your Android app in Java, and your web frontend in HTML/SASS/JS/jQuery. Nobody is stopping you. The truth is that people want their apps on multiple devices these days, and many apps wouldn't exist without react, at least not a port for your platform of choice. Yes, React sacrifices convenience for performance, but that has always been a trade-off. You'll notice very few people writing apps in C these days. That being said: What native features are you lacking? What apps are you using that are noticeably slower than native alternatives? My main complaint with React Native is the memory usage, but that is getting better and better and my computer has tons of RAM these days.
  - mosdl 8y ago
    React (or vdom in general) has high memory costs and won't be close to native performance anytime soon (or ever). As long as you are cognizant about the trade offs it can be the right choice, but never blind. People forget the old applet days.
- Scooty 8y ago
  > The fascination with 1 codebase doing multiple things is funny. Isn't it baked into most programmer's best-practices? Don't repeat yourself? Writing two programs that do the same thing doesn't sound very DRY.
  - mosdl 8y ago
    Each solution has pros and cons, and engineering is really about making those choices and dealing with the repercussions.

tptacek 8y ago

Modern programming languages are a lot more featureful and sophisticated than assembly language, and they change a lot more than instruction set architectures do. How is your lament different than that of an assembly language programmer, who might complain "crazy how far we've come from conditional jumps and some stack manipulation"? I'm 41 and got started in the 1990s, and those assembly advocates really did exist. What makes you think that 20 years from now people won't have a hard time believing that anyone could have advocated "just HTML and some script tags" over modern development practices?

pvg 8y ago
The assembly people were cranks even in the 90s whereas this complaint, even when put inartfully or outright inaccurately is not completely nuts. In 20 years, people will hopefully wonder how it was that every runtime (or even framework) came with its own set (or multiple sets) of dependency management, build, test and god-knows-what-else toolchains that that do almost but not entirely the same thing as every other one.
tedunangst 8y ago
There was a time when compiled languages compiled into a somewhat predictable finite sequence of machine instruction, and thus one might use them but still understand everything happening. I think that is less true of modern web frameworks.
- pvg 8y ago
  You probably didn't reach for disassembly dumps of some half-assed mid-90s C++ compiler to figure out why it's spewing 37 screens of error messages on some innocent-looking STL thing. Or maybe you did! But I'm not convinced 'rate of encounter with annoyingly incomprehensible magic' has really changed all that much since then.

Scooty 8y ago

It's really not that complex when you understand the reason for these tools, and you don't need to know all or even most of them. You learn them as you encounter the problems they were built to solve (or once the problem becomes too burdensome to manage with a simpler solution). Until then, you don't need to learn anything. OP's roadmap should include some information about why each tool is useful. Without that, it's like someone telling you how to become a mechanic by giving you a list of tools to buy.