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.
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.
However, it's important to realize that the way the web is moving is to not only benefit the working professionals being paid to write it, but also the consumers who experience it.
Why do we have minifiers and transpilers and modules and font icons? Why do we aim for one script tag instead of 50?
Because for a consumer, the web sucked (and still sucks to an extent, but less so with AMP and offline APIs.) For "prosumers" like Alice and Bob, it was a buffet, but for people browing their web pages it sucked. It was slow and unresponsive and that's even before the rise of the mobile web.
And whether the ecosystem leaves them behind or not, Alice and Bob can always create a new slideshow.js file on any given platform they want.
The web is moving towards being better for professionals and consumers, and I agree that those in the middle might lose out a little, but they are very small peanuts. I'd rather optimize for the next billion users in Africa, India and beyond, most of whom are on sub-2G speeds, than for the script kiddies making an easy living pilfering jQuery widgets without learning the platform.
There are embedded YouTube videos, MP3s, and code samples to illustrate what he's writing about. He's implemented their ideas using the Web Audio API and you can run the code from within the page and listen to the music being generated in real-time. It's a real testament to how great the web can be.
I think being able to do things like that is worth all the annoying parts of the modern web, in the end. For the developer and the end user. I wouldn't want to go back to the old way. I think it's easy to focus on the annoying parts and take the good parts for granted.
Doing something in a browser that we could do 30 years ago on a desktop isn't that great a testament.
Is this that much more efficient than "apt-get install foo"?
Not every platform/OS even has a (good) package manager. So I think this alone is what makes the web great.
Furthermore, free isn't free when my privacy is sold and/or my eye balls are subjected to even more ads. This is progress? No fucking way.
I don't know what you are on about as there weren't any app stores controlled by Apple or MS. Anyone was able to release crap software on floppy disks or BBS, and they did.
Mediocre solutions are fixed with an endless array of tools. Learning tools takes time. And that's just to break even. And around we go again.
Can we really say the average web experience is better than the average of 10 or just 5 years ago? (Hint: Nope.) Find someone who is less frustrated with technology and you'll find someone who has given up on technology.
I'm not sure it's completely comparable though, file sizes would have increased even without minification.
I think that many of the front end tools we use now result in an optimized developer workflow, but usually not optimized code.
> 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.
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).
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.
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.
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?
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.
But it really isn't and the proof is HyperCard from the 1980s. It's only hard because you have made it hard, for no reason that anyone can fathom (apart perhaps from job security).
Do you really think everybody -- from Android/iOS to Swing to qt to Web 2.0 -- just had no idea what they were doing?
Probably because every feature you listed was achievable before react.
How did you do type checking before TypeScript (or the like) in JS? give me a real answer.......
One very common way though was to avoid the need for it altogether in javascript, by rendering html on the server.
What does server-side rendering have to do with Typescript? Are you advocating avoiding javascript all together?
But yes, I do advocate avoiding javascript altogether whenever possible (which is more often than current trends). There were a number of other transpilers too, all of which were a pain and I don't see how typescript is going to improve on that.
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.
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.
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.
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.
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.
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>
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.
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.
Do they? In most tests I've seen straight javascript / jquery on the DOM is faster. eg. https://objectpartners.com/2015/11/19/comparing-react-js-per...
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.
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.
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.
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.