The Sad State of Web Development
medium.com
medium.com
Interesting how we can have so completely opposite experiences. I'm feeling like webdev is just finally geting a tiny bit sane. When I started doing it in '98 or so, it was horrible beyond description. Now, with ES6/7, Typescript, Less and Jade (and the Chrome dev tools), I can actually get some work done instead of fighting the browser at all time.
I would say LOL if only it wasn't so sad.
Edit:
> A SPA will lock you into a framework that has the shelf life of a hamster dump. When you think you need a SPA, just stop thinking.
Seriously? Backbone is super mature, but with a steady trickle of minor updates and fixes. And it isn't really a framework, just a small library.
There are plenty of great use cases for an SPA. A blog probably isn't one, but like with all technologies, part of your job is knowing when not to use it.
We should expect a rise in complexity if our ability to reach users has increased accordingly.
> Maybe 1 or 2 pages on your app will have really complex UI, but the other 95% of the app does not.
I guess I wish I had his problems. I work on an app where nearly every page has a complex UI, because it's a control panel for a domain with a lot of inherent complexity. Making manual DOM manipulation calls for every UI change would be a nightmare.
99% of the SPA's I've encountered in life had no business being SPAs.
I think the primary reason people are tired of new JS libraries is because there exists a certain kind of pressure that is hard to describe, but I will try. It's kind of like, "I don't want to miss out on the hottest framework"/"I don't want to fall behind current tech." The truth is, we should all ditch this mentality. Use what works for you and learn what you care about learning.
When a new JS library comes out, don't groan, take a quick peek and decide if it's worth it to try to integrate it into your workflow. I think it's great to have options and the options in web development are seemingly neverending. I'm happy I write software for the web, and I think we should all recognize how far things have come. Yet, we should always strive to make the web better for users and developers alike.
I find the authors sentiment very similar to that of those who complain about "all of this terrible music." Music is much easier to create and distribute and that means more of it, which, IMHO, is a good thing.
When selecting technology, I want to make a decision that will grow with me over the next several years. When perception is that each library of the day will be thrown out in 3 months, falling back to jquery/php is a really attractive option.
But Django has the DSF behind it moving point releases, bugfixes and major releases in a very sane way. The same absolutely cannot be said for angular (major rewrite in progress!) or a lot of similar projects in the Node.js community.
None of this means Node.js is bad, just that there is something to be said for consistency in development. Now watch as Python/Django devs slowly morph into what Delphi devs used to be ;)
One of the great things about being a programmer is that we know how to program in general. If we have to adopt a new syntax or learn the intricacies of some new methods that's ok, and not nearly equal to the amount of effort we expended to learn how to write code in the beginning.
Keep writing your Django apps. I agree that it's great that DSF is backing a stable and productive framework like Django.
I like the 1 branch, and will be happy to continue with it for a while.
Ember is a very under-rated framework.
I'm reminded of Mitch Hedberg: "I used to do drugs. I still do, but I used to too."
But speaking purely as a user, I think the statement "browsers suck, like really bad" still holds very true.
Yet the amount of code needed to do this has increased by huge amounts, and it churns constantly. Something is very wrong here.
The bad part of this is the disappearance of WYSIWYG editors for HTML. You weren't supposed to write this stuff by hand. That wasn't the plan. Tim Bernars-Lee's first browser had an editor. Mozilla had an editor. Microsoft had FrontPage. There used to be good open source editors. There was Nvu (dead)[1], and then Kompozer (abandoned)[2] Now, about the only thing left is Dreamweaver, which you now have to rent by the month. (Is BlueGriffon any good?) You didn't need a "content management system" unless you were constantly publishing new content, like a newspaper.
[1] https://en.wikipedia.org/wiki/Nvu [2] https://en.wikipedia.org/wiki/KompoZer
Seems like a lot of people being a bit depressed that they're not working on a big problem and hence trying to make even the simplest websites into gigantic software development projects.
The point about WYSIWYG editors is interesting, though I suspect the complexity of generating decent HTML/CSS/Javascript/whatever is what originally killed them. That said, surely someone is able to figure out a decent system now, right? 2015 technology has to be at the point where a program can figure out how to code a (semantic, well coded) layout in CSS, right?
It really doesn't matter what you were "supposed" to do with HTML. It's become something entirely different than what was originally intended.
When Tim Berners-Lee was at CERN he really just needed a way to link research papers to one another when, for instance, one cited another. His creation of the 'Web' referred to a web of mostly static documents. Nothing like the interactive applications we have today.
The fact that no WYSIWYG editor can keep up with the latest front-end application design trends is no surprise. (Would you expect a WYSIWYG editor for your iOS app?)
Interestingly, I was looking around the net recently for a simple web UI builder. Pickings were quite sparse, either online tools attached to some cloud provider, or elaborate proprietary systems way more than I needed. The ironic thing is that current "front-end tools" still require tediously writing out the UI whether in JSX, JsonML or whatever, pointing up where GUI tools would be most useful.
It's crossed my mind that writing a web UI generator in, say Tcl/Tk, would be possible and quite surprised no one has done it. ATM I don't have the time to pursue such a project, but a small GUI application to produce the "boilerplate" part of the code would be particularly helpful.
I pretty much hated every min of it, and there's a fair chance things will break if I update any of the deps, but I can't imagine getting something as organized and functional as I did with just jQuery, or even Knockout.
I have code broken up into organized modules (was never a fan of AMD/require.js), and truly re-usable components. The hot reloader renders my changes more often than not without a refresh. Production code is combined and minified into a single .js (no more downloading 15 different .js files). The feedback I have received from the business consistently mentions how fast and responsive the UI is.
Yes, the front-end JS scene kinda sucks, but I don't think I could go back to what it was 10 years ago and accomplish what I was able to in the course of a few months.
That seems like hands-down the best way to mix server rendered HTML with SPAs, especially if you have to support fallback to pure server rendering.
"You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server."
"That’s right. All you guys using React like it’s the only way to solve every problem ever are using it because Facebook couldn’t build a fucking notification icon."
"PostCSS - People actually use this thing. Can a library actually do shit out of the box anymore? I just want to install something and use it, not decide all the little plugins I want to use."
New JS libraries are coming out several times per year, and employers and engineers expect you to be familiar with them in order to get hired (e.x., we need React, Angular, Ember, Node and Meteor skills).
But what really happens, is when you have 12 months of time, and you need to know a new library / framework every three months you are burning something like four months of time per year just getting used to the new tech.
With RoR & AngularJS 1.5 I get a full-stack web application loaded with best practices that I can keep chugging away at building without ever worrying about what I need to hop onto next month.
I've been in and about technology since the late 1970s. There've been periods where it seemed that there were a large number of new technologies being promoted -- OLE, SOAP, and XML were several of the big ones, with a burst seeming to emerge just as the first dot-com bubble shattered. I still recall walking into a (now closed, of course) technical bookstore in a tech hub, and finding an O'Reilly title I hadn't seen before, with the blurb "The only book on $TECHNOLOGY_X you'll ever need". I did my standard scan: title page, contents, introduction, index.
I never got the least idea of what $TECHNOLOGY_X was.
That said, the blurb was accurate -- it was the only book I'd ever need, it only neglected to consider that I never needed it.
For young techies who happened to cut their teeth on a skillset that is widely adopted by the industry, the world is your oyster. Eventually, that skillset erodes or is abandoned. I watched that happen to mainframe and VMS programmers, to Perl hackers, to various all-inclusive toolkits aimed at what were once called "Open Systems" (apparently nobody wanted to say "Unix"). And many Microsoft technologies (though some have been surprisingly robust).
I'm watching it now with the set of Web technologies that have emerged post-2005. For many HN readers, Rails, Ajax, Angular, etc., are all you've ever known. For others, they're one more set of word-and-TLA-salad tossed out in front of us.
When I cared to do so, I'd learn the technologies in front of me, well, and try to keep an eye on what's coming down the pipe. But with tech half-lives measured in single-digit years, if not months, that's increasingly difficult. And frankly, the results are also increasingly difficult to deal with.
I see a recaptitulation coming, almost certainly with a vast simplification. I strongly suspect that someone's going to look up from Node.js-SOAP-COBOL one day and realise that they're accomplishing nothing Codd, Englebert, or Ritchie didn't pressage decades ago.
We'll get a simple document format. Probably based on HTML or LaTeX. We'll get an applications platform. Commerce will be standardised to a small set of apps, almost certainly growing out of iTunes, Amazon, Google Play, eBay, or Craigslist, or someone taking on one of their positions. Media will get its own dedicated standalone player.
And the titles "Web Designer" and "Web Applications Engineer" will be consigned to the same Schumpeterian scrap-heap of history as "stable boy". Perhaps retained for sentimental value by a small group of eccentric (although, by definition, fanatical) hobbyists. But otherwise rightly forgotten.
https://news.ycombinator.com/item?id=10880604
https://news.ycombinator.com/item?id=10882762
I bet Medium has a nice social graph of blogger and social share influencers based on this tracking, leveraging this might be the biggest value of their platform.
signalvnoise and buzzfeed also do this.
There are a handful of domains that are repeatedly submitted and have very predictable behavior...nytimes.com and medium.com. Everytime you go to an article URL at nytimes.com, at the minimum, `?r=0` is appended. As far as I can tell, every NYT article has a permalink in which query parameters have no effect to the end user. So writing a rule to strip out query params when testing for uniqueness would probably be of minimal harm.
Obviously such a rule would be terrible to apply for all domains...for starters, it would penalize all sites that use the `q=x` type param to query for unique pages, such as PHP bulletin boards.
gamedevdaily.io uses that tactic.
- There are loads of options for the back-end – Rails if you're building something CRUDdy, Java if you're building something enterprise-y, Go if you're building a simple API, Node if you like Javascript… They're all suited to particular niches, and it's great.
- The front-end is getting much better. For quite a while we had nothing except mad DOM-twiddling, then we had jQuery (which helped to some extent), now we have better frameworks that work more effectively with the way we want to develop apps. And there are options there too – React can help to control view complexity, for example, or you can go right ahead and build a full SPA using Angular or Ember or whatever.
Now I'm no fan of using Node for a server app. Personal opinion is that there's no requirements that aren't fulfilled better by another language. And indeed, I'm often frustrated by the extent to which people develop SPAs for things that should be static sites - Blogger, I'm looking at you.
But you know what? I'd take this in a second over the buggy soup of untested PHP, incompatible browsers, Prototype.js, IE6 and so on from only six or seven years ago. It's so incomparably better in every way.
Those are not shiny new kids on the block, but they are understood, proven technologies.
why Java instead of... well, i guess there isn't a language w/ GC and an ecosystem as "mature" as Java.
with clojure, which is indeed shiny and new, some people have cake and eat it too: speed of the jvm + flexibility of scripting. i guess a samish sort of thing could be accomplished w/ jython+Java if clj is too flashy.
anywho, i hear the "don't go for the glamor," thing and indeed try (i.e. make a conscious effort) to lag 'teh new hotness' by some interval. ES5 strict is usually good enough. indeed, tail calls are the one coolest feat.s ES6 to me, and they're pretty much everywhere unimplemented, including Babel, except maybe for some special cases.
w/ Java... it's a language i wish would move toward vanishing -- or at least go one layer deeper than everyday application development. when i first started writing applets, it was the coolest thing ever: Sun was awesome, the same program ran everywhere, there was automagic memory management, etc... now, Oracle's laying down all kinds of noise a/b owning the language, there are other runs-everywhere platforms/methods (ES, LLVM), and the Java language itself just looks incredibly noisy unless one uses some of the really excellent (but wo/man-hour costly) tooling expressly designed for handling it.
Partially, because I've been burned too much by pythons packaging madness. But beyond that, there is a bunch of strong, mature tooling done in ruby. Rake as a task runner, Thor as a simple library for more complex tools, guard as a general nice-ness, if you wanna go there, the entire chef-stack.
And if your main application is in ruby, there's very little overhead to use these strong tools to make your entire infrastructure better for little additional education, build chains or further investment.
Good to see others who have decided to keep on with what works.
And on top of it, add the fact that I also enjoy learning new programming languages for the backend, and the mental overload is definitely ensured.
Don't make the same mistake he did. Use the mature tech that is designed for small teams to be maximally productive. Use Rails.
People that adopted Node.js because of this may be set for a nasty surprise.
I had to familiarize myself with react, es6, babel + plugin, scss, redux & its concepts, react-router, npm and its packages, material-ui, browsersync, eslint and that's just to get started. Now that's a lot.
By the time I am comfortable in that arena something new would have replaced them.
There, I've saved you from reading the article.
It has never been a better time to be an (insert your preferred coding environment) programmer: if you're unhappy with the code you're writing, I'm certain you can find a company that offers what you want in no time. Finding a job that suits your demands is a better use of your time than whining on Medium.
I don't understand disliking npm though, I think npm is pretty great. Every time I spend a bunch of time wresting with pip, coming back to npm is like taking a warm bath.
That misinformation aside, all package managers are agnostic about how large your dependency tree is; the large trees are purely a consequence (or choice, depending on your outlook) of the community. Could you imagine a package manager telling you you're using too many or too few dependencies? If you want fewer dependencies, use fewer dependencies. npm won't get in your way.
Speaking of the community, it is primarily what people like about node and npm. Sure, there are lots of bad packages. That's a side effect of javascript being the lingua franca of the web. Everyone and their grandmother is writing npm packages, so of course there are going to be a lot of bad ones. _But there are also a lot of good ones._ npm has driven web development forward at such a fast pace, I wonder how anyone can't appreciate what it's done.
Finally, some stats: ~230,000 packages, ~3,300,000,000 package downloads last month. That is a lot of users for something fundamentally broken. I can only wish to work on such "broken" software.
To your last point, the javascript ecosystem can have a lot of users and be "broken" at the same time. I think that is a large reason why people hop around to new libraries so much.
"Well what I have now sucks, maybe this new thing will work better. (2 days pass) Nope! What else do you have for me this week?"
It's unsurprising that using a technology for something it was never meant for is problematic.
That said, it's not going anywhere anytime soon. "Because it makes lives easier for developers" is not a valid reason for most end users to change their habits.
Personally, I'm banking on better tooling. Most single page webapps today are just more complicated versions of fancy UX on top of an excel spreadsheet. So why are there no graphical design tools that let you visually set up the application, visually see where the data comes from and where it goes and then spits out html, css and react code? The state of the art in code generation has come a long way since dreamweaver.
All these gol-darn modern frameworks just to do something simple! Just use jquery!
Jquery is a framework. When jquery was all there was, people weren't building the kinds of things they're building now.
Well, glad I didn't have to waste my time.
> From what I can tell the background of React is: Facebook couldn’t create a notification indicator on Facebook.com, so they create this over engineered dump pile to solve that problem...That’s right. All you guys using React like it’s the only way to solve every problem ever are using it because Facebook couldn’t build a fucking notification icon.
Oh wait. This is not satire? Oops.
Ember.js, for example, has all kinds of nice buffering features, so you aren't making multiple un-needed ajax calls back to your server.
You will also end up needing to re-invent the wheel if you make anything complex.