9 ms·

> 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’

> 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. Let's compare it with some server-side technologies: Python/Django: 2005 Python/Flask: 2010 Nginx: 2004 Perl/Catalyst: 2006 Maybe I'm biased towards older software, but the difference to the popular frontend stuff is striking. The only thing in the frontend with a comparable history (that I can think of) is jQuery -- and I still use it today, but it seems many developers frown upon it these days. And it's a library, not a framework.

outsidetheparty 8y ago
Node probably belongs on this list (2009, it's older than I thought).
- tracker1 8y ago
  I used it before then, but could see why a lot wouldn't touch it until well after 2013-2015 or so. Despite following and using pretty early on... it wasn't until 0.8 that a lot of the core issues were really resolved and it stabilized a lot at that point. The ensuing iojs split, joyent handoff, and node org was a lot of turmoil. Add to that, the fact that NPM is its' own company, and not part of the Node Foundation could be mildly concerning. Don't get me wrong, I love node/npm but it wasn't really a catalyst until a little later than 2009.
zitterbewegung 8y ago
I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .
- aaron-lebo 8y ago
  They really shouldn't. Modern browsers have lots of the selector magic built-in, and frameworks that are very, very small can handle the rest without the spaghetti.
  - ozim 8y ago
    What if I tell you, you can write spaghetti code in vanilla javascript, small framework or big framework. You can also write decent code using jQuery.
    - collyw 8y ago
      I can confirm. I am trying to refactor an Angular monstrosity at the moment.
    - imtringued 8y ago
      jQuery alone isn't enough because it solves a completely different problem. It doesn't have a built in templating system which means you need a seperate plugin at which point it makes more sense to use Vue or React instead.
- no1youknowz 8y ago
  > I think more developers should use jquery to prototype an app and move torward a framework when it is needed. They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer. Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0]. However, one thing that I have learned. It's much simpler and easier to develop code in Vue compared to jQuery. It took me a day to develop a wizard exactly the same as [1]. Of which it's now a component which I can drop in anywhere in my codebase (which I do numerous times) and in future Vue projects. So FuelUX code: 463 LOC vs my Wizard: 180 LOC. One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions. Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC. Completely unbelievable from my perspective and I'm still only a newbie when it comes to Vue, Webpack, Babel, etc. jQuery/jQuery UI. It was great, but it's time to move on. [0]: https://github.com/bgrins/spectrum/issues/480#issuecomment-316187422 https://github.com/bgrins/spectrum/issues/480#issuecomment-3... [1]: http://getfuelux.com/javascript.html#wizard http://getfuelux.com/javascript.html#wizard
  - aaron-lebo 8y ago
    Mithril is similarly small and very easy to get started.
    - RodericDay 8y ago
      Mithril is my favorite by far. It's not even close. It's depressing how little-known it remains.
      - pygy_ 8y ago
        @RodericDay, I just vouched this comment which was [dead]. You've been shadowbanned since https://news.ycombinator.com/item?id=14982937 https://news.ycombinator.com/item?id=14982937 (9 months ago) you may want to appeal that decision or create a new account.
- machiaweliczny 8y ago
  IMO VueJs is new JQuery (evolotion). JSX(React) is more revolutionary way to build UI and not only web specific. If you need web specific or progressive enhancement or you just don't know modern JS development tools it's better to start with Vue. My friend who can barely code does quite nice pages in Vue. It's a big success of this framework. Although I prefer React as it's gives me more control/freedom. And if you want easy start just open https://codesandbox.io/ https://codesandbox.io/
- rimliu 8y ago
  I think more people should understand what problem jQuery was meant to solve: a) provide sane API for DOM manipulation b) hide all the ugly bits and bugs of different browsers.
aaron-lebo 8y ago
The difference is that the backend model has been around for 20 years if not more. You're locating lots of old-ish and stable libraries because that's when that stuff was made. Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same. I personally don't feel it's that unstable. Pick a library, stick with it, stop jumping to the next framework and the churn stops. It's part of being a mature dev. Things always look worse to outsiders than they are.
- freedomben 8y ago
  These are some very fair points. React also really does seem to be becoming a "standard" more so than anything I've seen in years. Time will tell of course, but I think you're on to something.
- perlgeek 8y ago
  > Pick a library, stick with it, stop jumping to the next framework and the churn stops. I wish it were that easy. At work, we've picked angular 1, and now there's angular 5, which is a totally different framework (and the migration path only works well if you did everything juuuust right), and no clear policy on how long angular 1 will be maintained. So either we churn, or we have no idea how long there will be any support.
  - underwater 8y ago
    This is the risk in the authors advice to just pick a monolithic framework. We’ve been building a React framework. We’ve been careful about how we choose components to use, so there has been very little churn. And because we control the implementation we’ve been able to build things we could never have done with a library like Angular.
  - hvs 8y ago
    They made a fair number of mistakes with Angular.js (1), so the rewrite was a sensible, if painful change for early adopters. Since version 2, the model has remained relatively stable with changes being improvements rather than completely breaking.
freedomben 8y ago
> but it seems many developers frown upon it these days This is sadly very true. jQuery is almost used as an insult these days. Having code be called "jQuery Spaghetti" is about the worst epithet that can be hurled at a javascript codebase these days.
- underwater 8y ago
  jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. Most jQuery applications couple their business logic to the mechanics of working with the DOM. It was also intended to smooth over browser inconsistencies and gaps in APIs. This is less relevant these days now that browsers are more mature.
  - rhapsodic 8y ago
    > jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. I keep hearing (well, reading on HN) criticisms of this sort about jQuery and they are absolutely not supported by the years of experience I have using jQuery for front-ends that have in many cases been quite complex. I use it because it greatly simplifies DOM manipulation and event handling. (e.g., no need to remove event handlers for a subtree removed by the .remove() method.)
    - underwater 8y ago
      In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure. This is not a fault of jQuery, as it never intended to solve those problems. Like you said, it is purely meant to solve the DOM issue.
      - rhapsodic 8y ago
        >In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?
maemilius 8y ago
No love for Rails? It's also been around since 2005.
- btreecat 8y ago
  Seems like they are a Pythonista
- nunez 8y ago
  I hate the fact that Ruby doesn’t get more love. It’s a great language on its own. It doesn’t need Rails.
  - philliphaydon 8y ago
    I like Ruby, I hate Rails. But Sinatra is awesome.
    - eropple 8y ago
      Personally I'd rather use Grape over Sinatra. I also wrote Modern[0] to provide a really nice, functionally-oriented OpenAPI server for Ruby that is very much Not Rails. (Looking at porting it to TypeScript soon to provide a similar-feeling API.) [0]: https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby
      - philliphaydon 8y ago
        Will take a look, thanks.
    - deleted 8y ago
      [deleted]
    - nunez 8y ago
      LOVE Sinatra. It’s so easy to get a web app going with it, and it’s super easy to test against!
freshhawk 8y ago
So you were there when Python went through it's own "everyone make a web framework until we figure out what we want" phase. I personally dislike js but this doesn't seem like an unusual phase, although js is so widely used it involves a lot more people than normal. Developers don't frown on jQuery for a tiny dynamic thing, but it is not for applications. jQuery is CGI and they need WSGI, Django and Flask now.
umanwizard 8y ago
PHP: 1995.

outsidetheparty 8y ago

Node probably belongs on this list (2009, it's older than I thought).

tracker1 8y ago
I used it before then, but could see why a lot wouldn't touch it until well after 2013-2015 or so. Despite following and using pretty early on... it wasn't until 0.8 that a lot of the core issues were really resolved and it stabilized a lot at that point. The ensuing iojs split, joyent handoff, and node org was a lot of turmoil. Add to that, the fact that NPM is its' own company, and not part of the Node Foundation could be mildly concerning. Don't get me wrong, I love node/npm but it wasn't really a catalyst until a little later than 2009.

zitterbewegung 8y ago

I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .

aaron-lebo 8y ago
They really shouldn't. Modern browsers have lots of the selector magic built-in, and frameworks that are very, very small can handle the rest without the spaghetti.
- ozim 8y ago
  What if I tell you, you can write spaghetti code in vanilla javascript, small framework or big framework. You can also write decent code using jQuery.
  - collyw 8y ago
    I can confirm. I am trying to refactor an Angular monstrosity at the moment.
  - imtringued 8y ago
    jQuery alone isn't enough because it solves a completely different problem. It doesn't have a built in templating system which means you need a seperate plugin at which point it makes more sense to use Vue or React instead.
no1youknowz 8y ago
> I think more developers should use jquery to prototype an app and move torward a framework when it is needed. They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer. Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0]. However, one thing that I have learned. It's much simpler and easier to develop code in Vue compared to jQuery. It took me a day to develop a wizard exactly the same as [1]. Of which it's now a component which I can drop in anywhere in my codebase (which I do numerous times) and in future Vue projects. So FuelUX code: 463 LOC vs my Wizard: 180 LOC. One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions. Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC. Completely unbelievable from my perspective and I'm still only a newbie when it comes to Vue, Webpack, Babel, etc. jQuery/jQuery UI. It was great, but it's time to move on. [0]: https://github.com/bgrins/spectrum/issues/480#issuecomment-316187422 https://github.com/bgrins/spectrum/issues/480#issuecomment-3... [1]: http://getfuelux.com/javascript.html#wizard http://getfuelux.com/javascript.html#wizard
- aaron-lebo 8y ago
  Mithril is similarly small and very easy to get started.
  - RodericDay 8y ago
    Mithril is my favorite by far. It's not even close. It's depressing how little-known it remains.
    - pygy_ 8y ago
      @RodericDay, I just vouched this comment which was [dead]. You've been shadowbanned since https://news.ycombinator.com/item?id=14982937 https://news.ycombinator.com/item?id=14982937 (9 months ago) you may want to appeal that decision or create a new account.
machiaweliczny 8y ago
IMO VueJs is new JQuery (evolotion). JSX(React) is more revolutionary way to build UI and not only web specific. If you need web specific or progressive enhancement or you just don't know modern JS development tools it's better to start with Vue. My friend who can barely code does quite nice pages in Vue. It's a big success of this framework. Although I prefer React as it's gives me more control/freedom. And if you want easy start just open https://codesandbox.io/ https://codesandbox.io/
rimliu 8y ago
I think more people should understand what problem jQuery was meant to solve: a) provide sane API for DOM manipulation b) hide all the ugly bits and bugs of different browsers.

aaron-lebo 8y ago

The difference is that the backend model has been around for 20 years if not more. You're locating lots of old-ish and stable libraries because that's when that stuff was made. Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same. I personally don't feel it's that unstable. Pick a library, stick with it, stop jumping to the next framework and the churn stops. It's part of being a mature dev. Things always look worse to outsiders than they are.

freedomben 8y ago
These are some very fair points. React also really does seem to be becoming a "standard" more so than anything I've seen in years. Time will tell of course, but I think you're on to something.
perlgeek 8y ago
> Pick a library, stick with it, stop jumping to the next framework and the churn stops. I wish it were that easy. At work, we've picked angular 1, and now there's angular 5, which is a totally different framework (and the migration path only works well if you did everything juuuust right), and no clear policy on how long angular 1 will be maintained. So either we churn, or we have no idea how long there will be any support.
- underwater 8y ago
  This is the risk in the authors advice to just pick a monolithic framework. We’ve been building a React framework. We’ve been careful about how we choose components to use, so there has been very little churn. And because we control the implementation we’ve been able to build things we could never have done with a library like Angular.
- hvs 8y ago
  They made a fair number of mistakes with Angular.js (1), so the rewrite was a sensible, if painful change for early adopters. Since version 2, the model has remained relatively stable with changes being improvements rather than completely breaking.

freedomben 8y ago

> but it seems many developers frown upon it these days This is sadly very true. jQuery is almost used as an insult these days. Having code be called "jQuery Spaghetti" is about the worst epithet that can be hurled at a javascript codebase these days.

underwater 8y ago
jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. Most jQuery applications couple their business logic to the mechanics of working with the DOM. It was also intended to smooth over browser inconsistencies and gaps in APIs. This is less relevant these days now that browsers are more mature.
- rhapsodic 8y ago
  > jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. I keep hearing (well, reading on HN) criticisms of this sort about jQuery and they are absolutely not supported by the years of experience I have using jQuery for front-ends that have in many cases been quite complex. I use it because it greatly simplifies DOM manipulation and event handling. (e.g., no need to remove event handlers for a subtree removed by the .remove() method.)
  - underwater 8y ago
    In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure. This is not a fault of jQuery, as it never intended to solve those problems. Like you said, it is purely meant to solve the DOM issue.
    - rhapsodic 8y ago
      >In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?

maemilius 8y ago

No love for Rails? It's also been around since 2005.

btreecat 8y ago
Seems like they are a Pythonista
nunez 8y ago
I hate the fact that Ruby doesn’t get more love. It’s a great language on its own. It doesn’t need Rails.
- philliphaydon 8y ago
  I like Ruby, I hate Rails. But Sinatra is awesome.
  - eropple 8y ago
    Personally I'd rather use Grape over Sinatra. I also wrote Modern[0] to provide a really nice, functionally-oriented OpenAPI server for Ruby that is very much Not Rails. (Looking at porting it to TypeScript soon to provide a similar-feeling API.) [0]: https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby
    - philliphaydon 8y ago
      Will take a look, thanks.
  - deleted 8y ago
    [deleted]
  - nunez 8y ago
    LOVE Sinatra. It’s so easy to get a web app going with it, and it’s super easy to test against!

freshhawk 8y ago

So you were there when Python went through it's own "everyone make a web framework until we figure out what we want" phase. I personally dislike js but this doesn't seem like an unusual phase, although js is so widely used it involves a lot more people than normal. Developers don't frown on jQuery for a tiny dynamic thing, but it is not for applications. jQuery is CGI and they need WSGI, Django and Flask now.

umanwizard 8y ago

PHP: 1995.