10 ms·

Modern JavaScript tooling is too complicated?

libria 7y ago
Is there transcript for the hearing impaired? Otherwise people are just going to respond to the title.
- tyingq 7y ago
  Not sure it would help as: "it’s 1v1v1 with Mikeal reppin’ team Yep, Divya on team Nope, and Feross sitting in the middle on team It Depends." That is, the transcript, if it existed, is just 3 people reacting to the title.
  - maltenuhn 7y ago
    Thanks, you saved me 20 minutes :)
- drngdds 7y ago
  It's a post on HN about modern JavaScript, everyone's gonna do that either way
electrotype 7y ago
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.
spankalee 7y ago
I hope someone pointed out that it's legacy JavaScript that's too complicated. Very modern JavaScript is quite a bit _less_ complicated.
- tyingq 7y ago
  Hard to make that as a blanket statement. I don't know that I've seen two different teams assemble the same pieces for a React stack.
  - tenaciousDaniel 7y ago
    So we just switched from Angular 1 to React. We decided about a year ago. So I spend a year writing side projects in React and Redux. In the meantime, a new dev was hired to begin writing the React/Redux code. I just jumped into his code today and tried to add my own stuff, and I feel like I'm learning programming all over again, because it looks like absolute gibberish compared to the code I had been writing on the side. So even if you are using React and Redux, you can write code that has virtually no resemblance to another repo. It's insane.
    - mosdl 7y ago
      Redux forces you to write lots of ugly boilerplate, its the same way in all code bases that use it.
      - davidjnelson 7y ago
        // reuse this export const createAction<T>(type: string, payload: T) => { return { type, payload }; }; // some component onClick={event => dispatch(createAction<SomeInterface>(TYPE_CONSTANT, event.target.value))} Where’s the boilerplate?
- moon2 7y ago
  IMO, there are two big problems with Javascript: - there are too many ways to do something: it's hard to understand patterns (they change with every framework, for example), many different standards that aren't compatible with each other. - javascript delays failure and fails silently: it makes software prone to bugs as well and it also makes the language hard to debug. NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the language.
zamadatix 7y ago
No more than you choose to make it over complicated.
tlrobinson 7y ago
Blanket statements about "web development" are not reasonable to make because there's such a wide variety of applications. Is using TypeScript, Webpack, React, and 20 other external libraries "too complicated" for a static marketing site? Probably. For a 200,000 LOC complex productivity tool? Probably not.
- barberousse 7y ago
  Seriously, it's just poor professional discretion. I work on a cross-browser multimedia sequencer, no fucking way you're hand writing all necessary DOM management code. You absolutely need React for that to prevent that kind of shit show. This custom video player project the team got assigned? Probably can write those on our own. To be fair though, framework and library marketing tends to be fairly disinterested in talking about suitable and unsuitable problem cases. I don't think that's completely intentional, but front-end tends to have more engineers with non-CS and other untraditional software education backgrounds in situations where they feel pressure to "get shit done"
aphextron 7y ago
Webpack is a godsend. Do you not remember Gulp? Or....Gradle...? Modern JS is a dream to work with. The days of pre-transpilation and modularization with hundreds of script tags and giant IIFE's and worrying about cross-browser was a total mess. It finally feels like the web has matured as an application platform and I've been waiting for this day for a long time.
- Aeolun 7y ago
  I could understand what was going on before transpilation. There was just Javascript, and while some functions might not exist in different browsers, the core was the same. Now I have to figure out the difference between: ‘umd’, ‘commonjs’, ‘esnext’, ‘es2015’, ‘es2018’, and a whole bunch more. I don’t want to keep up with JS politics just to be able to develop with the latest version.
  - mffnbs 7y ago
    You could just not do any of that and be fine.
  - commandlinefan 7y ago
    Just about the time Chrome and Firefox came out with working debuggers for JavaScript, everybody rushed onto non-debuggable bandwagons, so we’re back to the bad old days of using “alert” to debug...
- timw4mail 7y ago
  Webpack is still a nightmare of terrible configuration.
siempreb 7y ago
Yes, but if only the tooling was too complicated, it would not be too bad. IMAO the entire front-end JS world is one big pile of MISERY, complicated is not the word or the problem at all. Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making. And if all the new things in the JS world would be great solutions it could be awesome (maybe). But the reality learns that it only gets more complex and tiresome every day. Juggling with design patterns, not because they are a better solution than the design pattern you were using before, no, it's because some famous JS artist came up with an 'idea' and the entire JS herd is following it blindly. Think you can still write in the old fashion? Nope, PR declined! You protest? Beware of the company politics, the herd always wins. Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains. It goes on and on, really, unbelievable.. Web development took all the love I had for programming away.. And I acknowledge it is a great recipe for burn-out, if you fancy that. I originally came from C++ and recently went back to it after 8 years of web development. I totally unexpected rediscovered my joy for programming. I can code things again that actually work and are understandable, without all those black boxes of magic that are pure hell when something goes wrong. I gave up on it, it's not for me.. But still, I can imagine when you're young you can kind of enjoy the JS(TS) world with all those new and exiting things.
- hliyan 7y ago
  Also originally from C++, now been working with the likes of React for about five years. After grappling with Redux, React Router, Immutable, Typescript, Flow Typing and a hundred other libraries, my solution was to go back to basics: build applications with vanilla JS, using a bare minimum of libraries and a lot of standard browser APIs. In my case, basically React only. How do I do client-side routing? addEventListener('hashchange'). Type safety? Unit tests. Mapping actions to components? onClick: dispatch(new CustomEvent('foo')) etc. Edit: Parcel for module bundling and transpile, but I'm waiting for JS native modules. Eventually React too, will go away in favor of Web Components.
vikingcaffiene 7y ago
Seeing a lot of hate here for modern JS workflows. The truth is you can make a mess no matter what ecosystem you buy into. I’ve encountered some absolute trash fires of complexity in Java, PHP, C, and (yes) Javascript code bases. They all suffered from the same problem: lack of communication and planning. This is a framework agnostic problem IMHO.
- duxup 7y ago
  Also as the user hliyan notes.... you don't have to do all that stuff.
- hliyan 7y ago
  Different perspective: In Java, PHP and C (I've worked with each), comes very close to "no assembly required" to get a simple project running: install, write code, optionally compile and then run. In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from.
  - mffnbs 7y ago
    I see you've never developed in Java if you think that comes 'no assembly required".
    - gnusty_gnurc 7y ago
      definitely - having recently started working in Java it's far from "no assembly required" for certain things but feels _much_ more sane the types of problems I'd encounter in web/mobile dev land
  - vikingcaffiene 7y ago
    > In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from. That might have been true once but its not anymore. Assuming you have node installed, its a one liner to get started in React[0] and Angular[1]. I've found that many of the criticisms of the modern JS stack come from outdated views about the ecosystem (no offense intended). I'd encourage you to give it another try (especially TypeScript) It's matured quite a bit. [0] https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app [1] https://cli.angular.io/ https://cli.angular.io/
namelosw 7y ago
A lot of people complaint about Webpack. But most other languages only provides up to Grunt and Gulp equivalent, namely Gradle, Fake etc. As who had maintained large Gulp scripts, those Scripts would eventually become a huge pile of non-standard and ad-hoc scripts. Webpack is complicated, I admit. But it's much better than Gulp I my experience, so why is everyone complaining? It turns out the problem Webpack or JavaScript solves are more complex than other language solves. JavaScript is the center of the Web, you cannot expect let CSS bundling itself, so do images and fonts. Let alone compression, prefixing, and giving fonts and stuff size thresholds to in-line them in JavaScript. There would definitely better tools in the future like Parcel and Pika are trying but the problem doesn't go away. I'm looking forward to see other languages facing the same issue in WASM age.
JMTQp8lwXL 7y ago
JavaScript itself has a complicated, hairy history. It's hard to write a single line of code without wondering, must I query https://caniuse.com https://caniuse.com to be sure this API is supported by all of my organization's targeted browsers? It shouldn't be all that surprising, that in order to rectify the lack of parity, we have to accept come additional levels of complexity in our tooling. Sure, I could import all of corejs and call it a day. Everything would be polyfilled, but then I'd be wasting precious bytes and negatively impacting page load times. Some will even say the concern is no more than bikeshedding. But if you give little thought to bundle optimization, your carelessness will add up, and materially impact TTFB. It's a death by a thousand cuts. My personal answer is no. Whether it's Stockholm Syndrome or not, you can conquer the complexities of shipping web applications written in modern JavaScript. Becoming aware of the nuances has made me a stronger developer. Developing a deep understanding of polyfills, bundlers, transpilers, module formats (CJS, SystemJS, UMD, ES Module) and which browsers support which APIs has made led to me being more thoughtful in the code that I write. For people just looking to solve a business problem, without understanding the more tedious parts of JavaScript, it absolutely is too complicated for them. I empathize. But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal.
- xthestreams 7y ago
  > But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal. I guess what we are saying is that there must be a better, not yet invented way to do frontend, without having to deal with this huge complexity that is unique to this specific field.
  - JMTQp8lwXL 7y ago
    You can make it zero-config, polyfill everything, apply all babel plugins so everything is transpiled to support IE 7, for all you care. But everyone has different needs. So tools like Babel and Webpack allow you to pick-and-choose what polyfills and transpilations are necessary.
cutler 7y ago
Most young Javascript devs have no experience of hacking "DHTML" for Netscape Navigator and sundry incompatible versions of IE back in the late 90s. That was the real low point of front-end development. Nothing comes close to those life-sapping days so enjoy the immense resources you have today, particularly evergreen browsers following a standard.
- timw4mail 7y ago
  And yet, with a little thought, we could use those hard-won compatible apis more directly, and for the vast majority of websites, write less code, configuration, etc. But we still act as though the very basic DOM functionality is some arcane art that has to be "fixed" by a library like jQuery, or as is more common now, an entire stack of large tools. Having done paid work with React-stack apps, and personal projects with vanilla JS, I still see more advantage with less code on the vanilla side.
deleted 7y ago
[deleted]
pictur 7y ago
Javascript libraries are good at creating problems other than problem solving.
barberousse 7y ago
Everything terrible about the front-end is a consequence of scale and demand for warm bodies pumping out code that targets the world's largest networked application runtime: upper- and middle-management everywhere exerting downward pressure to ship for the cheapest rates facilitating code bootcamps, etc to pump out more non-traditional CS educated labor, meaning less shared generational communal knowledge that normally standardizes names for things like patterns, etc. Devs are thus even more interchangeable and we see less opportunity for mentoring, yet another means of transferring generational knowledge (and software engineering is _not_ a science), and people regularly leaving companies after 1 - 5 years. None of this really has anything to do with the question of whether JS tooling is too complicated save for the implication that professional _discretion_ has less and less reason to be cultivated - grab a framework/library and glue it together to meet the deadline that isn't a deadline but it's actually a deadline
Justsignedup 7y ago
Honestly. I used to build the buildmaster for Ant builds back in the day. They could actually be quite incredibly elegant (if you used Ant-contrib). The reason was actually a lack of magic. SURE, ant was very verbose compared to modern build systems, but it did a lot of things relatively straightforward. You invoke tools in the chain you want. Today it is very different. There is a huge chain of auto-wiring tools with very cryptic error messages. To just build a basic ES6 javascript webpack project with React I need over 800 libraries, many of which are automagically invoked via convention. I literally have no idea what my build does, and hope my lucky underwear actually works today. Most of the time I am browsing through weird bug reports trying random snippets on the internet because there's no sane way to debug anything. So the point is, explicit is a huge virtue. It is code you can trace and debug. Sure it adds a bit of time, but it is time up front that saves A LOT down stream. Meanwhile today's tools are built to save time up front and waste time downstream. You either follow the exact formula the original developers wanted or you're shit out of luck.
mbrodersen 7y ago
The answer is simple: Don't use a tool if the benefit doesn't outweigh the cost. Also, only use tools that are "market leaders" in their segment. So that there will be plenty of fixes/tutorials/help available to get you over bumps on the road.
alex78 7y ago
I agree that a lot of mainstream tooling and frameworks are too complicated. But there are simple tools out there for building your typical business applications. Stateful apps with NodeRun.com (https://noderun.com/docs/concepts/stateful-apps https://noderun.com/docs/concepts/stateful-apps) make development similar to what VB used to be like back in the day (but for JavaScript). There is a Visual drag-and-drop designer for the UI and inherent database integration. I find that building normal database-driven apps is 10x easier compared to rolling your own HTML, CSS, React, Angular, Express, etc.

Is there transcript for the hearing impaired? Otherwise people are just going to respond to the title.

tyingq 7y ago
Not sure it would help as: "it’s 1v1v1 with Mikeal reppin’ team Yep, Divya on team Nope, and Feross sitting in the middle on team It Depends." That is, the transcript, if it existed, is just 3 people reacting to the title.
- maltenuhn 7y ago
  Thanks, you saved me 20 minutes :)
drngdds 7y ago
It's a post on HN about modern JavaScript, everyone's gonna do that either way

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.

spankalee 7y ago

I hope someone pointed out that it's legacy JavaScript that's too complicated. Very modern JavaScript is quite a bit _less_ complicated.

tyingq 7y ago
Hard to make that as a blanket statement. I don't know that I've seen two different teams assemble the same pieces for a React stack.
- tenaciousDaniel 7y ago
  So we just switched from Angular 1 to React. We decided about a year ago. So I spend a year writing side projects in React and Redux. In the meantime, a new dev was hired to begin writing the React/Redux code. I just jumped into his code today and tried to add my own stuff, and I feel like I'm learning programming all over again, because it looks like absolute gibberish compared to the code I had been writing on the side. So even if you are using React and Redux, you can write code that has virtually no resemblance to another repo. It's insane.
  - mosdl 7y ago
    Redux forces you to write lots of ugly boilerplate, its the same way in all code bases that use it.
    - davidjnelson 7y ago
      // reuse this export const createAction<T>(type: string, payload: T) => { return { type, payload }; }; // some component onClick={event => dispatch(createAction<SomeInterface>(TYPE_CONSTANT, event.target.value))} Where’s the boilerplate?
moon2 7y ago
IMO, there are two big problems with Javascript: - there are too many ways to do something: it's hard to understand patterns (they change with every framework, for example), many different standards that aren't compatible with each other. - javascript delays failure and fails silently: it makes software prone to bugs as well and it also makes the language hard to debug. NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the language.

zamadatix 7y ago

No more than you choose to make it over complicated.

tlrobinson 7y ago

Blanket statements about "web development" are not reasonable to make because there's such a wide variety of applications. Is using TypeScript, Webpack, React, and 20 other external libraries "too complicated" for a static marketing site? Probably. For a 200,000 LOC complex productivity tool? Probably not.

barberousse 7y ago
Seriously, it's just poor professional discretion. I work on a cross-browser multimedia sequencer, no fucking way you're hand writing all necessary DOM management code. You absolutely need React for that to prevent that kind of shit show. This custom video player project the team got assigned? Probably can write those on our own. To be fair though, framework and library marketing tends to be fairly disinterested in talking about suitable and unsuitable problem cases. I don't think that's completely intentional, but front-end tends to have more engineers with non-CS and other untraditional software education backgrounds in situations where they feel pressure to "get shit done"

aphextron 7y ago

Webpack is a godsend. Do you not remember Gulp? Or....Gradle...? Modern JS is a dream to work with. The days of pre-transpilation and modularization with hundreds of script tags and giant IIFE's and worrying about cross-browser was a total mess. It finally feels like the web has matured as an application platform and I've been waiting for this day for a long time.

Aeolun 7y ago
I could understand what was going on before transpilation. There was just Javascript, and while some functions might not exist in different browsers, the core was the same. Now I have to figure out the difference between: ‘umd’, ‘commonjs’, ‘esnext’, ‘es2015’, ‘es2018’, and a whole bunch more. I don’t want to keep up with JS politics just to be able to develop with the latest version.
- mffnbs 7y ago
  You could just not do any of that and be fine.
- commandlinefan 7y ago
  Just about the time Chrome and Firefox came out with working debuggers for JavaScript, everybody rushed onto non-debuggable bandwagons, so we’re back to the bad old days of using “alert” to debug...
timw4mail 7y ago
Webpack is still a nightmare of terrible configuration.

siempreb 7y ago

Yes, but if only the tooling was too complicated, it would not be too bad. IMAO the entire front-end JS world is one big pile of MISERY, complicated is not the word or the problem at all. Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making. And if all the new things in the JS world would be great solutions it could be awesome (maybe). But the reality learns that it only gets more complex and tiresome every day. Juggling with design patterns, not because they are a better solution than the design pattern you were using before, no, it's because some famous JS artist came up with an 'idea' and the entire JS herd is following it blindly. Think you can still write in the old fashion? Nope, PR declined! You protest? Beware of the company politics, the herd always wins. Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains. It goes on and on, really, unbelievable.. Web development took all the love I had for programming away.. And I acknowledge it is a great recipe for burn-out, if you fancy that. I originally came from C++ and recently went back to it after 8 years of web development. I totally unexpected rediscovered my joy for programming. I can code things again that actually work and are understandable, without all those black boxes of magic that are pure hell when something goes wrong. I gave up on it, it's not for me.. But still, I can imagine when you're young you can kind of enjoy the JS(TS) world with all those new and exiting things.

hliyan 7y ago
Also originally from C++, now been working with the likes of React for about five years. After grappling with Redux, React Router, Immutable, Typescript, Flow Typing and a hundred other libraries, my solution was to go back to basics: build applications with vanilla JS, using a bare minimum of libraries and a lot of standard browser APIs. In my case, basically React only. How do I do client-side routing? addEventListener('hashchange'). Type safety? Unit tests. Mapping actions to components? onClick: dispatch(new CustomEvent('foo')) etc. Edit: Parcel for module bundling and transpile, but I'm waiting for JS native modules. Eventually React too, will go away in favor of Web Components.

vikingcaffiene 7y ago

Seeing a lot of hate here for modern JS workflows. The truth is you can make a mess no matter what ecosystem you buy into. I’ve encountered some absolute trash fires of complexity in Java, PHP, C, and (yes) Javascript code bases. They all suffered from the same problem: lack of communication and planning. This is a framework agnostic problem IMHO.

duxup 7y ago
Also as the user hliyan notes.... you don't have to do all that stuff.
hliyan 7y ago
Different perspective: In Java, PHP and C (I've worked with each), comes very close to "no assembly required" to get a simple project running: install, write code, optionally compile and then run. In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from.
- mffnbs 7y ago
  I see you've never developed in Java if you think that comes 'no assembly required".
  - gnusty_gnurc 7y ago
    definitely - having recently started working in Java it's far from "no assembly required" for certain things but feels _much_ more sane the types of problems I'd encounter in web/mobile dev land
- vikingcaffiene 7y ago
  > In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from. That might have been true once but its not anymore. Assuming you have node installed, its a one liner to get started in React[0] and Angular[1]. I've found that many of the criticisms of the modern JS stack come from outdated views about the ecosystem (no offense intended). I'd encourage you to give it another try (especially TypeScript) It's matured quite a bit. [0] https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app [1] https://cli.angular.io/ https://cli.angular.io/

namelosw 7y ago

A lot of people complaint about Webpack. But most other languages only provides up to Grunt and Gulp equivalent, namely Gradle, Fake etc. As who had maintained large Gulp scripts, those Scripts would eventually become a huge pile of non-standard and ad-hoc scripts. Webpack is complicated, I admit. But it's much better than Gulp I my experience, so why is everyone complaining? It turns out the problem Webpack or JavaScript solves are more complex than other language solves. JavaScript is the center of the Web, you cannot expect let CSS bundling itself, so do images and fonts. Let alone compression, prefixing, and giving fonts and stuff size thresholds to in-line them in JavaScript. There would definitely better tools in the future like Parcel and Pika are trying but the problem doesn't go away. I'm looking forward to see other languages facing the same issue in WASM age.

JMTQp8lwXL 7y ago

JavaScript itself has a complicated, hairy history. It's hard to write a single line of code without wondering, must I query https://caniuse.com https://caniuse.com to be sure this API is supported by all of my organization's targeted browsers? It shouldn't be all that surprising, that in order to rectify the lack of parity, we have to accept come additional levels of complexity in our tooling. Sure, I could import all of corejs and call it a day. Everything would be polyfilled, but then I'd be wasting precious bytes and negatively impacting page load times. Some will even say the concern is no more than bikeshedding. But if you give little thought to bundle optimization, your carelessness will add up, and materially impact TTFB. It's a death by a thousand cuts. My personal answer is no. Whether it's Stockholm Syndrome or not, you can conquer the complexities of shipping web applications written in modern JavaScript. Becoming aware of the nuances has made me a stronger developer. Developing a deep understanding of polyfills, bundlers, transpilers, module formats (CJS, SystemJS, UMD, ES Module) and which browsers support which APIs has made led to me being more thoughtful in the code that I write. For people just looking to solve a business problem, without understanding the more tedious parts of JavaScript, it absolutely is too complicated for them. I empathize. But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal.

xthestreams 7y ago
> But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal. I guess what we are saying is that there must be a better, not yet invented way to do frontend, without having to deal with this huge complexity that is unique to this specific field.
- JMTQp8lwXL 7y ago
  You can make it zero-config, polyfill everything, apply all babel plugins so everything is transpiled to support IE 7, for all you care. But everyone has different needs. So tools like Babel and Webpack allow you to pick-and-choose what polyfills and transpilations are necessary.

cutler 7y ago

Most young Javascript devs have no experience of hacking "DHTML" for Netscape Navigator and sundry incompatible versions of IE back in the late 90s. That was the real low point of front-end development. Nothing comes close to those life-sapping days so enjoy the immense resources you have today, particularly evergreen browsers following a standard.

timw4mail 7y ago
And yet, with a little thought, we could use those hard-won compatible apis more directly, and for the vast majority of websites, write less code, configuration, etc. But we still act as though the very basic DOM functionality is some arcane art that has to be "fixed" by a library like jQuery, or as is more common now, an entire stack of large tools. Having done paid work with React-stack apps, and personal projects with vanilla JS, I still see more advantage with less code on the vanilla side.

deleted 7y ago

[deleted]

pictur 7y ago

Javascript libraries are good at creating problems other than problem solving.

barberousse 7y ago

Everything terrible about the front-end is a consequence of scale and demand for warm bodies pumping out code that targets the world's largest networked application runtime: upper- and middle-management everywhere exerting downward pressure to ship for the cheapest rates facilitating code bootcamps, etc to pump out more non-traditional CS educated labor, meaning less shared generational communal knowledge that normally standardizes names for things like patterns, etc. Devs are thus even more interchangeable and we see less opportunity for mentoring, yet another means of transferring generational knowledge (and software engineering is _not_ a science), and people regularly leaving companies after 1 - 5 years. None of this really has anything to do with the question of whether JS tooling is too complicated save for the implication that professional _discretion_ has less and less reason to be cultivated - grab a framework/library and glue it together to meet the deadline that isn't a deadline but it's actually a deadline

Justsignedup 7y ago

Honestly. I used to build the buildmaster for Ant builds back in the day. They could actually be quite incredibly elegant (if you used Ant-contrib). The reason was actually a lack of magic. SURE, ant was very verbose compared to modern build systems, but it did a lot of things relatively straightforward. You invoke tools in the chain you want. Today it is very different. There is a huge chain of auto-wiring tools with very cryptic error messages. To just build a basic ES6 javascript webpack project with React I need over 800 libraries, many of which are automagically invoked via convention. I literally have no idea what my build does, and hope my lucky underwear actually works today. Most of the time I am browsing through weird bug reports trying random snippets on the internet because there's no sane way to debug anything. So the point is, explicit is a huge virtue. It is code you can trace and debug. Sure it adds a bit of time, but it is time up front that saves A LOT down stream. Meanwhile today's tools are built to save time up front and waste time downstream. You either follow the exact formula the original developers wanted or you're shit out of luck.

mbrodersen 7y ago

The answer is simple: Don't use a tool if the benefit doesn't outweigh the cost. Also, only use tools that are "market leaders" in their segment. So that there will be plenty of fixes/tutorials/help available to get you over bumps on the road.

alex78 7y ago

I agree that a lot of mainstream tooling and frameworks are too complicated. But there are simple tools out there for building your typical business applications. Stateful apps with NodeRun.com (https://noderun.com/docs/concepts/stateful-apps https://noderun.com/docs/concepts/stateful-apps) make development similar to what VB used to be like back in the day (but for JavaScript). There is a Visual drag-and-drop designer for the UI and inherent database integration. I find that building normal database-driven apps is 10x easier compared to rolling your own HTML, CSS, React, Angular, Express, etc.