7 ms·

I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction. Sometimes I feel that with Javascript, we developers have ta

by janfoeh 10y ago

I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction. Sometimes I feel that with Javascript, we developers have taken something that wasn't ours, and we're in the process of destroying the best thing there ever was about it. One of its best qualities used to be that you could have absolutely no idea what you're doing, read a few bad tutorials somewhere on the web, mash your head onto the keyboard and end up with something horrifying that was nevertheless close to what you wanted to achieve. It was beautiful, egalitarian. Like the web is supposed to be. I've spent quite a bit of time on Stackoverflow, coaching people who you would not call developers (nor would they themselves) on how to do that one tiny thing they wanted to add to the site for their bakery, yoga studio or blog. And almost got it working themselves. I know of no other language that can tell a similar success story, with that high an impact. Just insert that <script> for that jQuery plugin here and modify that initializer over there with a vague understand of how it needs to be adapted to your situation. Voilà! But we couldn't let that stand, could we? Because what works for Alice and Bob doesn't work for somebody writing that 200.000 line image editor or CRM in JS, and let's face it, that's what the web is about. So here we are, the single <script> tag having been replaced with compilers, transpilers, five mutually incompatible build systems, three different module systems in God knows how many implementations, frameworks changing their API every ten minutes and five thousand lines of NPM module code to be installed for even the simplest of tasks. We did it, gals and guys! The web is safely back in the hands of full-time professionals (with Hindu cow-like frustration tolerance). Where it belongs. Bah.

lmkg 10y ago
> One of its best qualities used to be that you could > have absolutely no idea what you're doing, read a few > bad tutorials somewhere on the web, mash your head > onto the keyboard and end up with something > horrifying that was nevertheless close to what you > wanted to achieve. > I know of no other language that can tell a similar > success story, with that high an impact. I assure you, the same is definitely true of VBA. And I agree with your overall point. Shitty code often makes the world a better place. It gets a bad rap from developers because we compare it to good code. But shitty code written by non-devs is not replacing good code, it is replacing an absence of code. And shitty code, for all its sins, is still often better than no code at all (which usually has the same sins).
- janfoeh 10y ago
  > Shitty code often makes the world a better place. That's one of those things I have probably read - and agreed with - a hundred times before, but never that succinct. I will make that mine; I hope you don't mind.
Andrex 10y ago
I get where you're coming from but your comment boils down in favor of unoptimized and insecure code. And I can't agree with that. I would also point out that the web is the most backwards-compatible platform of all time and Alice and Bob can continue doing their thing for as long as they want. The tools that professionals use today are an abstraction to increase efficiency and reduce code reuse, in the same way most programmers don't code assembly or C anymore. I'm not sure every part of the modern web stack is a universal good, but I'd be lying if I didn't say I'm more pleased coding on the web today than I was hacking together a Geocities page in my teenage years.
- janfoeh 10y ago
  I appreciate your position, I really do. It's not like I am clear-cut on this myself, even if my frustration makes it sounds like I am. I appreciate that the language, the platform and the web itself needs to evolve. But I object to the argument that people can just continue to do their thing, because people in that position are overwhelmingly dependent on the ecosystem. Guidance, libraries, tools. And that ecosystem has left them behind, or is at least very far along that road. Of course reasonable people might disagree, but to me, that people might write unoptimized (or just plain horrible) code is a very, very small price to pay for the empowerment the web delivers to them. And as to "insecure" - Jane and Joe want to show a slideshow of their hand-baked Macarons, not write banking auth systems. If they manage to open up a security risk, the attack surface is usually rather small, and the fault lies with the platform. No, I stand by this: Javascript was our generations Hypercard, on steroids, and we've almost completely squandered its potential.
  - rsyntax 10y ago
    jQuery still exists. IMO, the ecosystem has just moved towards rich-client front end applications. There was no good tool/framework for that and people started fulfilling that need. Of course you could write like you said "unoptimized (or just plain horrible) code" which in an actual application is huge price to pay. I think it all boils down to being able to use the right tool for the job. I wouldn't advise using React or Angular to show static content e.g an splash page.
oldmanjay 10y ago
If it were impossible to trivially build low-function websites, you'd have more impact with your point. As it stands, it comes off more like union guys complaining that hardworking people make them look bad.
- Zelphyr 10y ago
  Seems to me OP is stating the exact opposite. That the JS ecosystem used to be more egalitarian with a much lower barrier to entry than (ironically) what frameworks like React and Angular provide.
  - oldmanjay 10y ago
    If the OP is stating that it is possible to trivially create low-function websites then I am befuddled. Why complain that what is wanted is achievable? Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. Still isn't a very helpful point to make.
    - khedoros 10y ago
      > Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. It could be related to the signal-to-noise ratio. If I'm a non-dev looking to throw something together and 98% of the information I find is about some pro-level frameworks, it'll be hard for me to sort through that and find information appropriate to my skill level, level of interest, and needs. Maybe it's still a net-gain for the world as a whole, but it's certainly a loss for the non-dev. It makes the learning curve (perhaps needlessly, perhaps not) more regressive.
deleted 10y ago
[deleted]
rpeden 10y ago
Don't worry too much. I don't see browsers dropping ES5 support any time soon, and jQuery isn't going to disappear. There will still be plenty of opportunity for people to jump in seize great market opportunities using PHP, jQuery, and chewing gum while all of us full-time professionals are here on HN arguing about Angular vs React and whether npm is insane, awesome, or both.
- janfoeh 10y ago
  Thank you, and I hope you are right. Again, don't get me wrong - when I was writing what was called DHTML almost fifteen years ago, I would have killed for the APIs, capabilities and cross-platform stability we have today. It's a good thing. Lots of shiny. I simply feel that this is a concern that doesn't get enough attention, certainly not around circles like these that in the end drive the further evolution of development on the web platform. And that we collectively would do well to at least acknowledge the trade-offs we're making in the process.
altern8 10y ago
You can still do the exact horrible thing you're describing. However, JavaScript now gets used by real programmers for real applications, and has therefore evolved to accomodate for that. You're saying (incorrectly) that now inexperienced programmers can't put crappy scripts online without knowing what they're doing and hope the thing works. Well, you can still do that, but you can also actually learn the language and build serious stuff. I can't see how this is the wrong direction for JavaScript.
untog 10y ago
jQuery isn't dead - they're still releasing new versions. You can still do everything you used to be able to. But now you can also do more - you can sensibly modularise your code. Virtual DOMs bring huge performance boosts with very little work. IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't great, but it's still better to have an irritating package manager than no package manager at all. But there's no price to be paid here - if you don't want to use any of it, you don't have to.
- Zelphyr 10y ago
  The problem is, it has become popular in our industry to equate new with "quality". So, while you're correct that jQuery isn't dead and in fact is more mature, there are too many who won't use it almost because its mature. Its not the new shiny that it once was. But frameworks like React and Angular are very shiny. Even though, in my opinion, they're quite simply a mess.
  - untog 10y ago
    I think there is an element of people using things because they are new and shiny, yes. But plenty of people use React and Angular over jQuery because they make 1000x more sense when putting together a large web application with multiple developers contributing to the codebase.
    - janfoeh 10y ago
      Sure, for larger projects a good, well-thought out and consistent framework is a godsend. No doubt about it that plenty of people make very good use of the frameworks and libraries at our disposal. But on the other hand I cannot count the number of times I've seen Angular included for a simple contact form with validation on a static site, React to render a single trivial dynamic list or a nice, but basic JS lib that only works in module form via NPM exports. Sorry if I sound like a fortune cookie, but it's true - if all you've got is a hammer, everything looks like a nail. Since 2001 or so, I can count on three fingers the number of variable collisions I have experienced in small- to medium scale projects. That I as a newbie now have to understand and manage various module systems in order to embed a lightbox on my site is a huge jump in complexity for a gain that is at best negligible in practice. And while you and I probably have worked on some higher-complexity use cases, I think we would be kidding ourselves if we assumed that this constitutes the majority of the web. Because that's not Facebook-scale, it's the dude around your corner selling dishwashers and reparing washing machines, trying to get his inventories's prices from an Excel sheet onto his page with a minimum of fuzz.
spankalee 10y ago
Complex frameworks have historically made up for a lack of capabilities, starting with the lack of a component model and composition facilities. This is changing for the better with web components. Now you'll be able to have just a `<script>` tag and define a component and use it in markup. It'll be even simpler than jQuery, and saner at the same time. So you can do this: <script> class MyElement extends HTMLElement { constructor() { super(); console.log('yay!'); } } customElements.define('my-element', MyElement); </script> <my-element></my-element> And use no external libraries at all.
DigitalSea 10y ago
I sometimes yearn for the days of the simple script tag that seemingly gave us the world at our fingertips. Especially when I have spent hours trying to get tooling to work alone. The constant updates, deprecation of libraries and tools before they even hit version 1.0, it can be tedious. Having said that, I think in the case of the direction of Javascript itself: I believe it is going in the right direction. ECMAScript 2015 was a mammoth release that really took Javascript in a nice direction, the smaller ES2016 release adds a few minor features and ES2017 is shaping up to be another monumental release for Javascript. The ecosystem as you mention is really in a confusing state at present. The only constant in all of this is Javascript. We are living in an era where things are being deprecated before they even hit 1.0. The one part of front-end development heading in the wrong direction is the questionable design choices of frameworks like Angular and React. The only framework I have seen which is abiding by actual web standards is Aurelia. The lack of Aurelia specific concepts means you're not committing to something proprietary you're stuck using, like the case with Angular 2 and ReactJS. Then you have the elephant in the tooling room: Webpack. People are using it, it is becoming increasingly popular in the front-end space, but it has basically no documentation and it is incredibly confusing. People are using it, without even understanding it or knowing how to use it. Mostly learning from blog posts and StackOverflow. Webpack 2 looks promising, but it probably won't have any documentation either. It is almost like nobody seems to plan anything, choosing to develop and release off of the cuff. Even when Babel dramatically broke things out and changed the way it works for v6, that was a painful experience for the ecosystem in itself. Then you have System.js, JSPM and other tooling/module loaders breaking things every release.
ng12 10y ago
Uhm, why can't we have both? Sure, Mr. Bakery, do everything in jQuery in a <script> tag. I'd even argue that's probably the correct approach. But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago. I see comments like this in every one of these threads. It's shocking to me how misunderstood web development really is. If the web was meant to be strictly utilitarian we never should have moved off gopher.
- flukus 10y ago
  > But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Or rewritten because the flavor of the month has changed. >Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago. What exactly couldn't you do 3-4 years ago that you can now?
  - ng12 10y ago
    The big shift has been from managing complexity to avoiding it where possible, encapsulating it when not. In my current favorite webstack, every logical view is abstracted behind an API (which happens to be a React Component). Internally, everything about that component is encapsulated -- the internal implementation, the sub-components, even the CSS thanks to CSS Modules. In fact, if I really had a reason to write a specific component in Angular or jQuery I would be able to: it's easy to embed non-React code inside React, and as long as it exposes a top-level React Component I'm hunky dory. I refer to React because that's my library of choice -- but you can say similar things about Angular and Aurelia. This has only been something we've gotten right over the last few years. jQuery trampled all over the DOM, data-binding heavy frameworks like Backbone were impossible to reason about, Closure Library turned your Javascript into Java-flavored spaghetti, Coffeescript was basically Perl, and CSS was global by default. Now React lets me write perfectly performant abstractable code. Redux lets me manage state in a functional, reproducible way. Webpack supports CSS modules which let me write sane styles and code-splitting so I don't need to worry about managing resources. Typescript lets me write code that's safe and easy for others to consume. ES6 modules allow me to actually architect my codebase without shoving everything onto window. And the ringer is I'm not married to any of these technologies -- I can scalp out Redux for another data store, Typescript for Babel, go back to global CSS, etc. Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. Web apps are a HUGE hack, and it's funny to me that a forum dedicated to hackers has so many who shun it for that reason. It's not "flavor-of-the-month", it's finally making progress towards a really hard problem in really exciting ways.
erikpukinskis 10y ago
I feel the same. I've just straight up stopped using frameworks. I refuse to use ES6 or any module which depends on it. No more coffeescript, no SASS. No promises, no templates. And really, what all of this boils down to is: avoid declarative control structures at all costs. Procedural design by default. There are a handful of situations where I will build a declarative API, but they are rare. I will use libraries, but only if they have a single well defined purpose and are largely procedural. The result? It's wonderful. All of my code is completely traceable. If something doesn't work, I never have to go read online for an hour, dig around in the source code for random modules trying to understand boot and build processes well enough that I can form a hypothesis about where a bug is. I just start at whatever point my expectation is violated, and work directly back to whatever is broken. I can always insert a debugger statement, and instantly stop state either in Node or in the browser. The execution path and data handoffs never disappear into a mysterious framework or executable. The code in production is always in . or ./node_modules. The entire class of headaches so prevalent in Rails/Ember/every other declarative-is-best system are just gone. Granted, I deal with other headaches. I have to really think about how data moves through the system. I can't just add a flag to access data from one end of the system in a totally different part of my app, because there's no magical framework code using light AI to figure out how to marshal data around based on some declarative configuration conditions. Essentially what I've decided is it's better to sacrifice convenience in order to get inspectability. You lose speed in your initial hacking, but you gain a predictable pace of debugging. Bugs never really stay mysterious longer than 15 minutes or so. I never have those instances where I spend a whole workday scratching my head about framework internals. I do spend a day scratching my head about how my data should be structured and how it should flow through the system. But that's effort that will continue to pay dividends. It generally leads to better interfaces that require less maintenance. Work that is often continually put off when you have a framework that offers every shortcut that could be sanely crammed into it.
patj 10y ago
You can still do all of those things you're talking about. In most cases you don't even need jQuery anymore and can just use browser APIs. Why do you argue about something that clearly doesn't interest you? From a so-called professional: It's perfectly fine to continue doing websites the way you do if that works for you and your client. End of story. Everything else that confuses you is just the world of software getting bigger, Javascript being used in different places, people trying out things and promoting them, good stuff, bad stuff, you know – like the real world. Imagine knowing every aspect (political, economical, social) of a larger city and you would go crazy as well. Breathe and relax.

by janfoeh 10y ago

lmkg 10y ago

> One of its best qualities used to be that you could > have absolutely no idea what you're doing, read a few > bad tutorials somewhere on the web, mash your head > onto the keyboard and end up with something > horrifying that was nevertheless close to what you > wanted to achieve. > I know of no other language that can tell a similar > success story, with that high an impact. I assure you, the same is definitely true of VBA. And I agree with your overall point. Shitty code often makes the world a better place. It gets a bad rap from developers because we compare it to good code. But shitty code written by non-devs is not replacing good code, it is replacing an absence of code. And shitty code, for all its sins, is still often better than no code at all (which usually has the same sins).

janfoeh 10y ago
> Shitty code often makes the world a better place. That's one of those things I have probably read - and agreed with - a hundred times before, but never that succinct. I will make that mine; I hope you don't mind.

Andrex 10y ago

I get where you're coming from but your comment boils down in favor of unoptimized and insecure code. And I can't agree with that. I would also point out that the web is the most backwards-compatible platform of all time and Alice and Bob can continue doing their thing for as long as they want. The tools that professionals use today are an abstraction to increase efficiency and reduce code reuse, in the same way most programmers don't code assembly or C anymore. I'm not sure every part of the modern web stack is a universal good, but I'd be lying if I didn't say I'm more pleased coding on the web today than I was hacking together a Geocities page in my teenage years.

janfoeh 10y ago
I appreciate your position, I really do. It's not like I am clear-cut on this myself, even if my frustration makes it sounds like I am. I appreciate that the language, the platform and the web itself needs to evolve. But I object to the argument that people can just continue to do their thing, because people in that position are overwhelmingly dependent on the ecosystem. Guidance, libraries, tools. And that ecosystem has left them behind, or is at least very far along that road. Of course reasonable people might disagree, but to me, that people might write unoptimized (or just plain horrible) code is a very, very small price to pay for the empowerment the web delivers to them. And as to "insecure" - Jane and Joe want to show a slideshow of their hand-baked Macarons, not write banking auth systems. If they manage to open up a security risk, the attack surface is usually rather small, and the fault lies with the platform. No, I stand by this: Javascript was our generations Hypercard, on steroids, and we've almost completely squandered its potential.
- rsyntax 10y ago
  jQuery still exists. IMO, the ecosystem has just moved towards rich-client front end applications. There was no good tool/framework for that and people started fulfilling that need. Of course you could write like you said "unoptimized (or just plain horrible) code" which in an actual application is huge price to pay. I think it all boils down to being able to use the right tool for the job. I wouldn't advise using React or Angular to show static content e.g an splash page.

oldmanjay 10y ago

If it were impossible to trivially build low-function websites, you'd have more impact with your point. As it stands, it comes off more like union guys complaining that hardworking people make them look bad.

Zelphyr 10y ago
Seems to me OP is stating the exact opposite. That the JS ecosystem used to be more egalitarian with a much lower barrier to entry than (ironically) what frameworks like React and Angular provide.
- oldmanjay 10y ago
  If the OP is stating that it is possible to trivially create low-function websites then I am befuddled. Why complain that what is wanted is achievable? Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. Still isn't a very helpful point to make.
  - khedoros 10y ago
    > Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. It could be related to the signal-to-noise ratio. If I'm a non-dev looking to throw something together and 98% of the information I find is about some pro-level frameworks, it'll be hard for me to sort through that and find information appropriate to my skill level, level of interest, and needs. Maybe it's still a net-gain for the world as a whole, but it's certainly a loss for the non-dev. It makes the learning curve (perhaps needlessly, perhaps not) more regressive.

deleted 10y ago

[deleted]

rpeden 10y ago

Don't worry too much. I don't see browsers dropping ES5 support any time soon, and jQuery isn't going to disappear. There will still be plenty of opportunity for people to jump in seize great market opportunities using PHP, jQuery, and chewing gum while all of us full-time professionals are here on HN arguing about Angular vs React and whether npm is insane, awesome, or both.

janfoeh 10y ago
Thank you, and I hope you are right. Again, don't get me wrong - when I was writing what was called DHTML almost fifteen years ago, I would have killed for the APIs, capabilities and cross-platform stability we have today. It's a good thing. Lots of shiny. I simply feel that this is a concern that doesn't get enough attention, certainly not around circles like these that in the end drive the further evolution of development on the web platform. And that we collectively would do well to at least acknowledge the trade-offs we're making in the process.

altern8 10y ago

You can still do the exact horrible thing you're describing. However, JavaScript now gets used by real programmers for real applications, and has therefore evolved to accomodate for that. You're saying (incorrectly) that now inexperienced programmers can't put crappy scripts online without knowing what they're doing and hope the thing works. Well, you can still do that, but you can also actually learn the language and build serious stuff. I can't see how this is the wrong direction for JavaScript.

untog 10y ago

jQuery isn't dead - they're still releasing new versions. You can still do everything you used to be able to. But now you can also do more - you can sensibly modularise your code. Virtual DOMs bring huge performance boosts with very little work. IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't great, but it's still better to have an irritating package manager than no package manager at all. But there's no price to be paid here - if you don't want to use any of it, you don't have to.

Zelphyr 10y ago
The problem is, it has become popular in our industry to equate new with "quality". So, while you're correct that jQuery isn't dead and in fact is more mature, there are too many who won't use it almost because its mature. Its not the new shiny that it once was. But frameworks like React and Angular are very shiny. Even though, in my opinion, they're quite simply a mess.
- untog 10y ago
  I think there is an element of people using things because they are new and shiny, yes. But plenty of people use React and Angular over jQuery because they make 1000x more sense when putting together a large web application with multiple developers contributing to the codebase.
  - janfoeh 10y ago
    Sure, for larger projects a good, well-thought out and consistent framework is a godsend. No doubt about it that plenty of people make very good use of the frameworks and libraries at our disposal. But on the other hand I cannot count the number of times I've seen Angular included for a simple contact form with validation on a static site, React to render a single trivial dynamic list or a nice, but basic JS lib that only works in module form via NPM exports. Sorry if I sound like a fortune cookie, but it's true - if all you've got is a hammer, everything looks like a nail. Since 2001 or so, I can count on three fingers the number of variable collisions I have experienced in small- to medium scale projects. That I as a newbie now have to understand and manage various module systems in order to embed a lightbox on my site is a huge jump in complexity for a gain that is at best negligible in practice. And while you and I probably have worked on some higher-complexity use cases, I think we would be kidding ourselves if we assumed that this constitutes the majority of the web. Because that's not Facebook-scale, it's the dude around your corner selling dishwashers and reparing washing machines, trying to get his inventories's prices from an Excel sheet onto his page with a minimum of fuzz.

spankalee 10y ago

Complex frameworks have historically made up for a lack of capabilities, starting with the lack of a component model and composition facilities. This is changing for the better with web components. Now you'll be able to have just a `<script>` tag and define a component and use it in markup. It'll be even simpler than jQuery, and saner at the same time. So you can do this: <script> class MyElement extends HTMLElement { constructor() { super(); console.log('yay!'); } } customElements.define('my-element', MyElement); </script> <my-element></my-element> And use no external libraries at all.

DigitalSea 10y ago

I sometimes yearn for the days of the simple script tag that seemingly gave us the world at our fingertips. Especially when I have spent hours trying to get tooling to work alone. The constant updates, deprecation of libraries and tools before they even hit version 1.0, it can be tedious. Having said that, I think in the case of the direction of Javascript itself: I believe it is going in the right direction. ECMAScript 2015 was a mammoth release that really took Javascript in a nice direction, the smaller ES2016 release adds a few minor features and ES2017 is shaping up to be another monumental release for Javascript. The ecosystem as you mention is really in a confusing state at present. The only constant in all of this is Javascript. We are living in an era where things are being deprecated before they even hit 1.0. The one part of front-end development heading in the wrong direction is the questionable design choices of frameworks like Angular and React. The only framework I have seen which is abiding by actual web standards is Aurelia. The lack of Aurelia specific concepts means you're not committing to something proprietary you're stuck using, like the case with Angular 2 and ReactJS. Then you have the elephant in the tooling room: Webpack. People are using it, it is becoming increasingly popular in the front-end space, but it has basically no documentation and it is incredibly confusing. People are using it, without even understanding it or knowing how to use it. Mostly learning from blog posts and StackOverflow. Webpack 2 looks promising, but it probably won't have any documentation either. It is almost like nobody seems to plan anything, choosing to develop and release off of the cuff. Even when Babel dramatically broke things out and changed the way it works for v6, that was a painful experience for the ecosystem in itself. Then you have System.js, JSPM and other tooling/module loaders breaking things every release.

ng12 10y ago

Uhm, why can't we have both? Sure, Mr. Bakery, do everything in jQuery in a <script> tag. I'd even argue that's probably the correct approach. But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago. I see comments like this in every one of these threads. It's shocking to me how misunderstood web development really is. If the web was meant to be strictly utilitarian we never should have moved off gopher.

flukus 10y ago
> But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Or rewritten because the flavor of the month has changed. >Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago. What exactly couldn't you do 3-4 years ago that you can now?
- ng12 10y ago
  The big shift has been from managing complexity to avoiding it where possible, encapsulating it when not. In my current favorite webstack, every logical view is abstracted behind an API (which happens to be a React Component). Internally, everything about that component is encapsulated -- the internal implementation, the sub-components, even the CSS thanks to CSS Modules. In fact, if I really had a reason to write a specific component in Angular or jQuery I would be able to: it's easy to embed non-React code inside React, and as long as it exposes a top-level React Component I'm hunky dory. I refer to React because that's my library of choice -- but you can say similar things about Angular and Aurelia. This has only been something we've gotten right over the last few years. jQuery trampled all over the DOM, data-binding heavy frameworks like Backbone were impossible to reason about, Closure Library turned your Javascript into Java-flavored spaghetti, Coffeescript was basically Perl, and CSS was global by default. Now React lets me write perfectly performant abstractable code. Redux lets me manage state in a functional, reproducible way. Webpack supports CSS modules which let me write sane styles and code-splitting so I don't need to worry about managing resources. Typescript lets me write code that's safe and easy for others to consume. ES6 modules allow me to actually architect my codebase without shoving everything onto window. And the ringer is I'm not married to any of these technologies -- I can scalp out Redux for another data store, Typescript for Babel, go back to global CSS, etc. Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. Web apps are a HUGE hack, and it's funny to me that a forum dedicated to hackers has so many who shun it for that reason. It's not "flavor-of-the-month", it's finally making progress towards a really hard problem in really exciting ways.

erikpukinskis 10y ago

I feel the same. I've just straight up stopped using frameworks. I refuse to use ES6 or any module which depends on it. No more coffeescript, no SASS. No promises, no templates. And really, what all of this boils down to is: avoid declarative control structures at all costs. Procedural design by default. There are a handful of situations where I will build a declarative API, but they are rare. I will use libraries, but only if they have a single well defined purpose and are largely procedural. The result? It's wonderful. All of my code is completely traceable. If something doesn't work, I never have to go read online for an hour, dig around in the source code for random modules trying to understand boot and build processes well enough that I can form a hypothesis about where a bug is. I just start at whatever point my expectation is violated, and work directly back to whatever is broken. I can always insert a debugger statement, and instantly stop state either in Node or in the browser. The execution path and data handoffs never disappear into a mysterious framework or executable. The code in production is always in . or ./node_modules. The entire class of headaches so prevalent in Rails/Ember/every other declarative-is-best system are just gone. Granted, I deal with other headaches. I have to really think about how data moves through the system. I can't just add a flag to access data from one end of the system in a totally different part of my app, because there's no magical framework code using light AI to figure out how to marshal data around based on some declarative configuration conditions. Essentially what I've decided is it's better to sacrifice convenience in order to get inspectability. You lose speed in your initial hacking, but you gain a predictable pace of debugging. Bugs never really stay mysterious longer than 15 minutes or so. I never have those instances where I spend a whole workday scratching my head about framework internals. I do spend a day scratching my head about how my data should be structured and how it should flow through the system. But that's effort that will continue to pay dividends. It generally leads to better interfaces that require less maintenance. Work that is often continually put off when you have a framework that offers every shortcut that could be sanely crammed into it.

patj 10y ago

You can still do all of those things you're talking about. In most cases you don't even need jQuery anymore and can just use browser APIs. Why do you argue about something that clearly doesn't interest you? From a so-called professional: It's perfectly fine to continue doing websites the way you do if that works for you and your client. End of story. Everything else that confuses you is just the world of software getting bigger, Javascript being used in different places, people trying out things and promoting them, good stuff, bad stuff, you know – like the real world. Imagine knowing every aspect (political, economical, social) of a larger city and you would go crazy as well. Breathe and relax.