18 ms·

Yup. Everyone wants to use the latest and greatest, but there is a reason that certain things like SQL have stood the test of time. I think the same could be s

by craigc 8y ago

Yup. Everyone wants to use the latest and greatest, but there is a reason that certain things like SQL have stood the test of time. I think the same could be said of the design world. There was a time not too long ago when designs actually felt polished and had real shapes, shadows, gradients. When you clicked on a button you actually knew you were clicking on a button. Then iOS 7 came along and everything became white and flat and buttons were replaced with text with no borders. I think we are slowly moving back to where we were ten years ago. PS How long until people start ditching React for jQuery?

chrisco255 8y ago
Ha, JQuery. I just had to look at a legacy JQuery code base...and I shudder the thought of ever going back to that paradigm. Sometimes new patterns/frameworks/architectures do really change the game for good.
- timr 8y ago
  I still use jQuery regularly. It works well and doesn't get in the way. I'd rather work on a jQuery codebase written by a good engineer than a React codebase written by an average engineer, and there's no amount you could pay me to work on a Javascript codebase written by a bad engineer. The problem you've identified is that most code, in general, is terrible. The code written by people who chase trends tends to be worse than average.
  - deleted 8y ago
    [deleted]
  - chrisco255 8y ago
    I wouldn't. React makes it hard to FUBAR a front end. JQuery makes it stupidly easy to write a spaghetti code unmaintainable mess.
    - timr 8y ago
      React makes it easier for bad developers to do complicated things. They still end up writing spaghetti code.
      - chrisco255 8y ago
        You literally can't write spaghetti code in React due to one-way data flow. That's what prevents the spaghetti. UI is a function of state and props. JQuery is an imperative DOM altering library that isn't even necessary with modern browsers.
        timr 8y ago
        If I had a dollar for every person who told me that X prevents people from writing bad code, I wouldn't need to write code.
  - collyw 8y ago
    > The code written by people who chase trends tends to be worse than average. This. Instead of learning a handfull of technologies well they learn a lot of technologies very poorly. If I am hiring I now look at it as a red flag when people have too many frameworks listed.
- collyw 8y ago
  I have an angular codebase to maintain, on Angular 1.3 - probably when it was peak of the hype cycle. Its a spaghetti mess. Using a different framwork doesn't make you immune to these problems. Especially when people don't seem to understand the new tech especially well.
  - gbersac 8y ago
    Angular is not react.
crimsonalucard 8y ago
The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than a traditional imperative language. A select search over an index is an abstraction that is too high level to be placed over a bottleneck. What algorithm does a select search execute? Why does using select * slow down a query? Different permutations of identical queries causes slow downs or speed ups for no apparent reason in SQL. SQL is a leaky abstraction that has created a whole generation of SQL admins or people who memorize a bunch of SQL hacks rather than understand algorithms.
- deleted 8y ago
  [deleted]
- bunderbunder 8y ago
  One person's trash is another person's treasure. Part of the reason SQL has stood the test of time is the very fact that it allows such a high level of abstraction. The big problem that it solved, compared to much of what existed at the time, was that it allowed you to decouple the physical format of the data from the applications that used it. That made it relatively easy to do two things that were previously very hard: Ask a database to answer questions it wasn't originally designed to answer, and modify a database's physical structure without having to change the code of every application that uses it. A lot of "easier" technologies - including, arguably, ORM on top of relational databases - make things easier by sacrificing or compromising those very features that allow for such flexibility. Which speaks to the grandparent's point about technologies that make it easy to get started in the short term, at the cost of having major disadvantages in the long term.
- ljw1001 8y ago
  You've demonstrated above that using RDBMS and SQL involves making tradeoffs, like everything else. But you probably can't imagine a world without relational databases. I know I can't. Many of the problems you mention above occur because the database handles stuff for programmers. Sure. you could create a custom solution around your biggest bottlenecks, but do you want to create a custom solution for every query, or do you want the database to do it for you. The generation of SQL admins is a replacement for a much larger group of programmers that would be needed if they weren't here, and more importantly, an army of people to deal with security, reliability, etc. that people using a good RDBMS get to take for granted.
andrepd 8y ago
Absolutely. The flat design thing is a pet peeve of mine.
pjmlp 8y ago
Still doing jQuery with server side rendering, not bothering with React. Yep dinosaur here.
- m-localhost 8y ago
  It's so nice to build something that works without JS in the first place and then just add some JS and CSS3 animations.
  - pjmlp 8y ago
    Absolutely, then eventually sprinkle some PWA or Web Components stuff.
  - rhapsodic 8y ago
    >It's so nice to build something that works without JS in the first place and then just add some JS and CSS3 animations. Yeah, but JS buys you a lot. There are certain things that you can accomplish with JS that you absolutely cannot accomplish without it. OTOH, anything that you can accomplish with React, you can accomplish without React. I'm with the GP on that one.
jonny_eh 8y ago
What does iOS's flat design have to do with jQuery?
- craigc 8y ago
  It doesn’t. I was referring to the idea of new technologies eventually circling back to old and saying that I think that is true in the design world too.
zonkd1234 8y ago
I agree with what you are saying but you can't compare jQuery and React - they are very different tools. If something works for you and makes life easier then you should use it. There is no right answer. You just need to be honest with yourself when planning things out - am I using this technology because it's new and shiny or because it is the right tool for the job right now.
- craigc 8y ago
  > I agree with what you are saying but you can't compare jQuery and React - they are very different tools. I am well aware. It was mostly a joke :]
acjohnson55 8y ago
You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago. So really it would be more like React vs vanilla JS. There's definitely a place for vanilla, when you just need minor dynamism on an otherwise basic UI.
- amclennon 8y ago
  > You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago You say that, but from time to time I still discover slight variations in browser behavior or bugs that were opened 8 years ago that would've been avoided if I had just used jQuery. Most modern frameworks will abstract away these differences, but sometimes you'll need to access the DOM directly.

by craigc 8y ago

chrisco255 8y ago

Ha, JQuery. I just had to look at a legacy JQuery code base...and I shudder the thought of ever going back to that paradigm. Sometimes new patterns/frameworks/architectures do really change the game for good.

timr 8y ago
I still use jQuery regularly. It works well and doesn't get in the way. I'd rather work on a jQuery codebase written by a good engineer than a React codebase written by an average engineer, and there's no amount you could pay me to work on a Javascript codebase written by a bad engineer. The problem you've identified is that most code, in general, is terrible. The code written by people who chase trends tends to be worse than average.
- deleted 8y ago
  [deleted]
- chrisco255 8y ago
  I wouldn't. React makes it hard to FUBAR a front end. JQuery makes it stupidly easy to write a spaghetti code unmaintainable mess.
  - timr 8y ago
    React makes it easier for bad developers to do complicated things. They still end up writing spaghetti code.
    - chrisco255 8y ago
      You literally can't write spaghetti code in React due to one-way data flow. That's what prevents the spaghetti. UI is a function of state and props. JQuery is an imperative DOM altering library that isn't even necessary with modern browsers.
      - timr 8y ago
        If I had a dollar for every person who told me that X prevents people from writing bad code, I wouldn't need to write code.
- collyw 8y ago
  > The code written by people who chase trends tends to be worse than average. This. Instead of learning a handfull of technologies well they learn a lot of technologies very poorly. If I am hiring I now look at it as a red flag when people have too many frameworks listed.
collyw 8y ago
I have an angular codebase to maintain, on Angular 1.3 - probably when it was peak of the hype cycle. Its a spaghetti mess. Using a different framwork doesn't make you immune to these problems. Especially when people don't seem to understand the new tech especially well.
- gbersac 8y ago
  Angular is not react.

crimsonalucard 8y ago

The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than a traditional imperative language. A select search over an index is an abstraction that is too high level to be placed over a bottleneck. What algorithm does a select search execute? Why does using select * slow down a query? Different permutations of identical queries causes slow downs or speed ups for no apparent reason in SQL. SQL is a leaky abstraction that has created a whole generation of SQL admins or people who memorize a bunch of SQL hacks rather than understand algorithms.

deleted 8y ago
[deleted]
bunderbunder 8y ago
One person's trash is another person's treasure. Part of the reason SQL has stood the test of time is the very fact that it allows such a high level of abstraction. The big problem that it solved, compared to much of what existed at the time, was that it allowed you to decouple the physical format of the data from the applications that used it. That made it relatively easy to do two things that were previously very hard: Ask a database to answer questions it wasn't originally designed to answer, and modify a database's physical structure without having to change the code of every application that uses it. A lot of "easier" technologies - including, arguably, ORM on top of relational databases - make things easier by sacrificing or compromising those very features that allow for such flexibility. Which speaks to the grandparent's point about technologies that make it easy to get started in the short term, at the cost of having major disadvantages in the long term.
ljw1001 8y ago
You've demonstrated above that using RDBMS and SQL involves making tradeoffs, like everything else. But you probably can't imagine a world without relational databases. I know I can't. Many of the problems you mention above occur because the database handles stuff for programmers. Sure. you could create a custom solution around your biggest bottlenecks, but do you want to create a custom solution for every query, or do you want the database to do it for you. The generation of SQL admins is a replacement for a much larger group of programmers that would be needed if they weren't here, and more importantly, an army of people to deal with security, reliability, etc. that people using a good RDBMS get to take for granted.

andrepd 8y ago

Absolutely. The flat design thing is a pet peeve of mine.

pjmlp 8y ago

Still doing jQuery with server side rendering, not bothering with React. Yep dinosaur here.

m-localhost 8y ago
It's so nice to build something that works without JS in the first place and then just add some JS and CSS3 animations.
- pjmlp 8y ago
  Absolutely, then eventually sprinkle some PWA or Web Components stuff.
- rhapsodic 8y ago
  >It's so nice to build something that works without JS in the first place and then just add some JS and CSS3 animations. Yeah, but JS buys you a lot. There are certain things that you can accomplish with JS that you absolutely cannot accomplish without it. OTOH, anything that you can accomplish with React, you can accomplish without React. I'm with the GP on that one.

jonny_eh 8y ago

What does iOS's flat design have to do with jQuery?

craigc 8y ago
It doesn’t. I was referring to the idea of new technologies eventually circling back to old and saying that I think that is true in the design world too.

zonkd1234 8y ago

I agree with what you are saying but you can't compare jQuery and React - they are very different tools. If something works for you and makes life easier then you should use it. There is no right answer. You just need to be honest with yourself when planning things out - am I using this technology because it's new and shiny or because it is the right tool for the job right now.

craigc 8y ago
> I agree with what you are saying but you can't compare jQuery and React - they are very different tools. I am well aware. It was mostly a joke :]

acjohnson55 8y ago

You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago. So really it would be more like React vs vanilla JS. There's definitely a place for vanilla, when you just need minor dynamism on an otherwise basic UI.

amclennon 8y ago
> You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago You say that, but from time to time I still discover slight variations in browser behavior or bugs that were opened 8 years ago that would've been avoided if I had just used jQuery. Most modern frameworks will abstract away these differences, but sometimes you'll need to access the DOM directly.