5 ms·

The joys of the javascript ecosystem: (1) creating complex solutions for problems no one has or (2) creating complex solutions to fix the problem of complex sol

by gtmb 7y ago

The joys of the javascript ecosystem: (1) creating complex solutions for problems no one has or (2) creating complex solutions to fix the problem of complex solutions that didn't need to exist in the first place It is an endless loop. The first dot-com bubble resource wastefulness was spending so much money on networking gear. Every one had oversized expensive Cisco gear. This dot-com bubble resource wastefulness is so many hundreds of thousands of engineering hours devoted to mega super over engineered Javascript solutions.

wongarsu 7y ago
But if it's the right tool for a FAANG company surely it must be the right tool for my use-case /s
meritt 7y ago
> devoted to mega super over engineered Javascript solutions Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning! It'll be nice when people get back to solving real business problems.
- bmiller2 7y ago
  Fall of NOSQL?
  - simonw 7y ago
    I feel like many experienced developers I know have gone back to defaulting to SQL databases again, because it turns out the trade-offs of NoSQL (schema-free, horizontally-scaled-but-eventually-consistent etc) weren't worth the trade-offs.
  - djsumdog 7y ago
    Is your shop still using it? Most NoSQL systems I've seen in the wild are pretty much just used as a caching store .. fancy Reddis really. All the big shops I've worked at still use Postgres for persistant storage. If they need speed; they'll add Elastic Search or Spark and have indexing services to make sure they stay up to date.
    - vosper 7y ago
      I think there are probably quite a lot of production Mongo databases out there from companies founded around the peak of the (bootcamp-driven) NoSQL hype train. No one's bragging about it, probably everyone regrets it, and most companies will never practically be able to get off it (because, when your data is an unstructured mess it's a huge project to try and figure out how to get to structure, not to mention maintaining consistency during the migration. And you have that home-grown "relational" layer someone wrote for Mongo when they realised that they really did have relational data after all, and which is now coupled to everything...) (If you thought I was describing the primary database at my day job, well...)
      - ComputerGuru 7y ago
        Most companies that adopted MongoDB at peak NoSQL either failed or were forced to switch to a better option (NoSQL or otherwise): that was a steaming pile of crap that couldn’t be trusted with data. The people behind it were concerned with marketing and going viral and succeeded at just that, it’s only recently that the money and time has been put into making the product itself actually any good.
        vosper 7y ago
        Then perhaps we really are an outlier. That'd be nice: fewer people than I thought toiling under the yoke of a crappy database. The post-IPO success of Mongodb Inc, and Amazon's recent roll out of their own compatible hosted solution makes me suspect not, though.
        ComputerGuru 7y ago
        Perhaps I was a little too optimistic ;)
    - quickthrower2 7y ago
      It’s not sexy but we use both Azure table storage and Amazon Redshift and they are nosql in my book.
rictic 7y ago
I get framework and tooling fatigue, but it seems misaimed here. This project is an attempt at minimizing complexity, not adding onto it. There's a fundamental problem with writing JS for the browser: how do you expresses your dependencies? jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual. More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is) With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.
- core-questions 7y ago
  > how do you expresses your dependencies? because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
  - ratww 7y ago
    > some of which seem to have to do with JS's lack of an include() function This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
- doublerabbit 7y ago
  > how do you expresses your dependencies? By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks. If everyone wrote their own kits then the web would be a more of a mature place. Downvoted without any reasons? The web once before didn’t rely on frameworks. PHPNuke wasn’t a framework. PHPBB wasn’t a framework. E107 wasn’t a framework. If you wanted something. you coded it yourself. /shrug maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.

by gtmb 7y ago

wongarsu 7y ago

But if it's the right tool for a FAANG company surely it must be the right tool for my use-case /s

meritt 7y ago

> devoted to mega super over engineered Javascript solutions Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning! It'll be nice when people get back to solving real business problems.

bmiller2 7y ago
Fall of NOSQL?
- simonw 7y ago
  I feel like many experienced developers I know have gone back to defaulting to SQL databases again, because it turns out the trade-offs of NoSQL (schema-free, horizontally-scaled-but-eventually-consistent etc) weren't worth the trade-offs.
- djsumdog 7y ago
  Is your shop still using it? Most NoSQL systems I've seen in the wild are pretty much just used as a caching store .. fancy Reddis really. All the big shops I've worked at still use Postgres for persistant storage. If they need speed; they'll add Elastic Search or Spark and have indexing services to make sure they stay up to date.
  - vosper 7y ago
    I think there are probably quite a lot of production Mongo databases out there from companies founded around the peak of the (bootcamp-driven) NoSQL hype train. No one's bragging about it, probably everyone regrets it, and most companies will never practically be able to get off it (because, when your data is an unstructured mess it's a huge project to try and figure out how to get to structure, not to mention maintaining consistency during the migration. And you have that home-grown "relational" layer someone wrote for Mongo when they realised that they really did have relational data after all, and which is now coupled to everything...) (If you thought I was describing the primary database at my day job, well...)
    - ComputerGuru 7y ago
      Most companies that adopted MongoDB at peak NoSQL either failed or were forced to switch to a better option (NoSQL or otherwise): that was a steaming pile of crap that couldn’t be trusted with data. The people behind it were concerned with marketing and going viral and succeeded at just that, it’s only recently that the money and time has been put into making the product itself actually any good.
      - vosper 7y ago
        Then perhaps we really are an outlier. That'd be nice: fewer people than I thought toiling under the yoke of a crappy database. The post-IPO success of Mongodb Inc, and Amazon's recent roll out of their own compatible hosted solution makes me suspect not, though.
        ComputerGuru 7y ago
        Perhaps I was a little too optimistic ;)
  - quickthrower2 7y ago
    It’s not sexy but we use both Azure table storage and Amazon Redshift and they are nosql in my book.

rictic 7y ago

I get framework and tooling fatigue, but it seems misaimed here. This project is an attempt at minimizing complexity, not adding onto it. There's a fundamental problem with writing JS for the browser: how do you expresses your dependencies? jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual. More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is) With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.

core-questions 7y ago
> how do you expresses your dependencies? because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
- ratww 7y ago
  > some of which seem to have to do with JS's lack of an include() function This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
doublerabbit 7y ago
> how do you expresses your dependencies? By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks. If everyone wrote their own kits then the web would be a more of a mature place. Downvoted without any reasons? The web once before didn’t rely on frameworks. PHPNuke wasn’t a framework. PHPBB wasn’t a framework. E107 wasn’t a framework. If you wanted something. you coded it yourself. /shrug maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.