5 ms·

I use server side generated HTML pages with progressive enhancement using JQuery (I prefere it to plain Javascript). Not complicated and works very well. Of c

I use server side generated HTML pages with progressive enhancement using JQuery (I prefere it to plain Javascript). Not complicated and works very well. Of course this is not popular/cool, though.

steve_adams_86 7y ago
I would argue this actually is popular - I've come across it on most projects I've been contracted to work on. Clients often defend their choice, saying react/vue/angular/webpack prevents them from 'just getting things done'. It's funny because they worry they're in the dark ages, but in reality many young and old projects alike are still using this approach. As for being cool, my opinion is that shipping stuff is cool, and if your project is maintainable that's very cool no matter how you do it.
- bonesss 7y ago
  There are a million cool camping gadgets out there... Before I go out on a trip I take a sec to figure out what I'm doing on this trip, and what I'm gonna need. A lot of cool gadgets get left on the floor because they're totally irrelevant. It's odd that we're coming up on 2020 and software projects checking their dependencies and overhead against their goals is still seen as a matter of fashion. KISS isn't sexy, and doesn't sell consultant hours. Those are features, not bugs, IMO.
ericmcer 7y ago
I use the latest and greatest React at my work. It is definitely better than jquery, some of the stuff I can do in 100 lines and how clear it is to me is impressive (React hooks are awesome). I have a ton of worry about other devs, especially ones with no React experience walking into my code though. With jquery it is totally reasonable to expect anyone who calls themselves a front end developer to have a working understanding of it. Can’t think of any other JS framework that can boast that.
madhadron 7y ago
Most of my JavaScript these days is little interactive things embedded in web pages, and I use raw JavaScript. All the stuff I used jQuery for back in the 1990's is in the language and DOM API now. They generally have the form: document.addEventListener('DOMContentLoaded', function() { var m = { ...model fields... _observers: new Set(), notify: function() { this._observers.forEach(function(observer) { observer(); } } }; var elem1 = document.getElementById('...'); elem1.addEventListener('...', function() { ...update fields on m... m.notify(); }); m._observers.add(function() { ...update elem1 from m... }); m.notify(); });
- adventured 7y ago
  > All the stuff I used jQuery for back in the 1990's is in the language and DOM API now. Huh? Wrong decade I think. jQuery wasn't released until 2006.
  - madhadron 7y ago
    ...am I going crazy? There was a library with the $ that we used in the late '90's to handle cross browser issues. I thought it was an early version of jQuery. What was it called?
    - MildlySerious 7y ago
      MooTools and Dojo come to mind, but I'm thinking of the 2000s also.
    - benbristow 7y ago
      Prototype maybe?
    - thrownaway954 7y ago
      Nope, you're not... everyone seems to forget the decade of 2000-2010 when calculating any dates nowadays. It's like that old saying... Remember kids, 1990 was 28 years ago, not 18.
robertoandred 7y ago
It's not complicated because you're not doing anything complicated with it.
- skore 7y ago
  It has long been my conviction that tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems. All of those framework-du-jour praises sound to me like people have found The New Great Tool for building a Tower of Babel¹. Just, you know, have simpler problems? SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with. ¹ one common tool in the pipeline actually being called babel never fails to amuse me.
  - bonesss 7y ago
    > tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity. It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.
- csande17 7y ago
  In practice, a lot of complexity in front-end development comes because front-end developers only solve problems by adding layers of abstraction, never removing them. Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components. But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it. Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity. See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"
benbristow 7y ago
Instead of jQuery why not use a more minimalistic reactive library like Vue.JS? Using jQuery will just make you suffer in the end. You end up having to write loads of code to manage the state of the DOM and it just gets more complicated as your project expands.

I use server side generated HTML pages with progressive enhancement using JQuery (I prefere it to plain Javascript). Not complicated and works very well. Of course this is not popular/cool, though.

steve_adams_86 7y ago

I would argue this actually is popular - I've come across it on most projects I've been contracted to work on. Clients often defend their choice, saying react/vue/angular/webpack prevents them from 'just getting things done'. It's funny because they worry they're in the dark ages, but in reality many young and old projects alike are still using this approach. As for being cool, my opinion is that shipping stuff is cool, and if your project is maintainable that's very cool no matter how you do it.

bonesss 7y ago
There are a million cool camping gadgets out there... Before I go out on a trip I take a sec to figure out what I'm doing on this trip, and what I'm gonna need. A lot of cool gadgets get left on the floor because they're totally irrelevant. It's odd that we're coming up on 2020 and software projects checking their dependencies and overhead against their goals is still seen as a matter of fashion. KISS isn't sexy, and doesn't sell consultant hours. Those are features, not bugs, IMO.

ericmcer 7y ago

I use the latest and greatest React at my work. It is definitely better than jquery, some of the stuff I can do in 100 lines and how clear it is to me is impressive (React hooks are awesome). I have a ton of worry about other devs, especially ones with no React experience walking into my code though. With jquery it is totally reasonable to expect anyone who calls themselves a front end developer to have a working understanding of it. Can’t think of any other JS framework that can boast that.

madhadron 7y ago

Most of my JavaScript these days is little interactive things embedded in web pages, and I use raw JavaScript. All the stuff I used jQuery for back in the 1990's is in the language and DOM API now. They generally have the form: document.addEventListener('DOMContentLoaded', function() { var m = { ...model fields... _observers: new Set(), notify: function() { this._observers.forEach(function(observer) { observer(); } } }; var elem1 = document.getElementById('...'); elem1.addEventListener('...', function() { ...update fields on m... m.notify(); }); m._observers.add(function() { ...update elem1 from m... }); m.notify(); });

adventured 7y ago
> All the stuff I used jQuery for back in the 1990's is in the language and DOM API now. Huh? Wrong decade I think. jQuery wasn't released until 2006.
- madhadron 7y ago
  ...am I going crazy? There was a library with the $ that we used in the late '90's to handle cross browser issues. I thought it was an early version of jQuery. What was it called?
  - MildlySerious 7y ago
    MooTools and Dojo come to mind, but I'm thinking of the 2000s also.
  - benbristow 7y ago
    Prototype maybe?
  - thrownaway954 7y ago
    Nope, you're not... everyone seems to forget the decade of 2000-2010 when calculating any dates nowadays. It's like that old saying... Remember kids, 1990 was 28 years ago, not 18.

robertoandred 7y ago

It's not complicated because you're not doing anything complicated with it.

skore 7y ago
It has long been my conviction that tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems. All of those framework-du-jour praises sound to me like people have found The New Great Tool for building a Tower of Babel¹. Just, you know, have simpler problems? SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with. ¹ one common tool in the pipeline actually being called babel never fails to amuse me.
- bonesss 7y ago
  > tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity. It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.
csande17 7y ago
In practice, a lot of complexity in front-end development comes because front-end developers only solve problems by adding layers of abstraction, never removing them. Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components. But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it. Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity. See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"

benbristow 7y ago

Instead of jQuery why not use a more minimalistic reactive library like Vue.JS? Using jQuery will just make you suffer in the end. You end up having to write loads of code to manage the state of the DOM and it just gets more complicated as your project expands.