13 ms·

Web Programming Is Getting Unnecessarily Complicated

J_Darnley 10y ago
Tell me about it, or don't, it's up to you. js;dr
DougN7 10y ago
I wonder how many are like me (old school? Just old??) and eschew platforms and libraries and roll my own most of the time, because most of the time, the needs are simple, and it's quicker to pound something out rather than learn and use Yet Another Framework. Though using jquery is nice sometimes...
- johnloeber 10y ago
  That's the approach I took to hand-rolling my personal website. All I care about is delivering my content reasonably well -- the elegance or modernity of the underlying engineering seems irrelevant. (Not to mention that this minimizes website bloat...)
- pavlov 10y ago
  I do that. Web dev is not my main focus, but I have to deal with it all the time. I try to attack the problems with an initial prototype that's a combination of plain HTML+JS and Node.js. Instead of a database, I tend to reuse a simple Javascript class I wrote a couple of years back that provides a minimalist layer of persistence for collections using an append-only file. (It's really just a single file I copy to any new projects when it's time to store something.) Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it. So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity. (I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
  - msane 10y ago
    I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It also has a bad zealot problem, where Facebook has cleverly brought a lot of people to it who haven't seen anything else and are convinced it is the bee's knees. > The library is very useful for (?) UI problems... Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it". Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines. > ...toolchain fetishism which tends to cloud React's fundamental simplicity This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
    - microcolonel 10y ago
      I frankly don't see how you could come to the conclusion that Angular 2 components are simpler than React components. I mean, in React, a component can be as simple as const MyComponent = () => <span> some markup nonsense </span>;
      - msane 10y ago
        Yup that's the argument mentioned: React is "simpler", "anyone can see"... Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about. myMod.component('Foo', { template: '<h1>{{$and.better.templating}} {{see()}}</h1>', controller: function() { var and = {this_one: 'does_stuff'}; } });
        thegayngler 10y ago
        This is not easier to reason about than returning jsx IMO... It's only 1 of the ways to build an angular 2 component. The website tutorial is using decorator syntax. Typescript Angular 2 documentation. What's wrong with just learning JavaScript and less Angular specific syntax and tooling. Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems. React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
- fenomas 10y ago
  > eschew platforms and libraries and roll my own most of the time That's what nearly everybody does, when they're one person hacking on a one-off project. I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
  - pavlov 10y ago
    Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles. There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
    - buckbova 10y ago
      I picked up Angular quickly, insisted everyone in my group follow this style guide. https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide We didn't need an expert.
      - jasonm23 10y ago
        Seems you were lucky that the expert you didn't need had written up a style guide.
        buckbova 10y ago
        Definitely. We live in wonderful times.
      - thegayngler 10y ago
        I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake. I don't want to be hunting all over my code base just to figure out what is happening in a controller or component. JPs styleguide is awesome!
- hajile 10y ago
  It's not so much a change in technology as it is a shift in focus. If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade. Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives. If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
  - blub 10y ago
    Web app with complex data = website that can be done very well with html, css and a server-side language. It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated". Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
    - onion2k 10y ago
      Web app with complex data = website that can be done very well with html, css and a server-side language. Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb. My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage. Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
- notliketherest 10y ago
  wow this attitude is so sad! React + Redux - changed my whole outlook on web development and it's actually a joy again. Take a little bit of time, read, learn, figure out a simple webpack script, and you're gonna love life.
- kalleboo 10y ago
  Most of the web stuff I have to work on is developed once, and then maintained rarely (once a year or so). It's not the kind of project that has continuous development. So whenever I've used a framework or SDK, when it comes time to add a small feature or tweak, I spend more time bringing the project up to date with the latest version of the framework or SDK than I do implementing the feature. Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
  - polishninja 10y ago
    I've run into this issue multiple times as well.
- blub 10y ago
  I think there's a lot of social pressure from rockstar web developers to build and use JS libraries and frameworks. Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses. So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
  - jasonthevillain 10y ago
    > And excuses about how today's customers expect an app-like experience Yes. If anyone has evidence of this I'd love to see it.
- pbreit 10y ago
  I'm still sort of a newbie but I have found it much much easier for me to quickly build my projects on the very very easy to use Web2py Python framework. The things I like are: defining my DB structure in simple code, no routing (routing is implied by file & function names), Python, HTML views with simple embedded code (including full Python if need/want).
kiba 10y ago
Because people are trying to cram down 10 different JS libraries down the throat of a static page?
draw_down 10y ago
I mean, the entire name of the game is unnecessary complication. We took a document platform and mangled it into an app platform... kinda.
- copperx 10y ago
  We need to remind ourselves frequently that the web is a terrible platform. Yes, TCP/IP changed the world, but the web is an embarrassment to our field. It could be so much more.
  - gkya 10y ago
    Web is good. It's how we use it. If web was sex, todays web dev is basically gang rape.
  - collyw 10y ago
    It is beautifully cross platform. A claim that Java made but never lived up to.
formula1 10y ago
Well yes and no. Javascript problems are what php used to solve before. Its actually necessarilly complicated if you view it from what javascript is attempting to replace. On top of replacement, theres another question "is the common road the best road?". Something as simple as a html5 video tag can be replicated through a canvas, html5 audio and some ui elements. And as things get more complicated, are we better off pretending complexity is the enemy? The reality is that these are problems all languages have to deal with. The reason the web is getting the most is because its the most widely consumed abd provided. Why be involved in an ecosystem dominated by coorperate entities that would only pay you just enough so you wont leave when you can be in an environment where insanity is an acceptable road to sanity. Why the hell does coffee script exist? It doesnt matter.
sp527 10y ago
Clientside code execution makes sense. Every last thing that can be offloaded to the client should be. The tooling around this concept may be insufficient or difficult to use, but the underlying premise is undeniably sound.
- jasonthevillain 10y ago
  Not necessarily. The client device may be old, underpowered, slow, and running out of battery. Which isn't to say thick clients are always a bad idea, but they're not the One True Answer™.
  - sp527 10y ago
    Hah I rushed that answer but yes totally agree. When I'm dev'ing for web, I always monitor perf against a crappy old Android phone. Similarly, Chrome devtools makes it easy to simulate a bad network connection. I try to make sure it's tolerable. Also worth noting that analytics makes it easy to determine what device/OS the majority of your visitors are using. Anyone building an app would be wise to pay close attention to this to guide dev efforts.
cm127 10y ago
Ironically, I find that tree format unnecessarily complicated.
rajington 10y ago
"Cooking is getting unnecessarily complicated." - Caveman Compare food nowadays to centuries ago, I'm glad things got unnecessarily complicated.
- copperx 10y ago
  Food production is complicated because of scale. But food itself hasn't changed much in centuries. The only real difference is that all the world's spices are available to common folk in Nowhere, TX.
  - aaronblohowiak 10y ago
    Refrigeration
- personsunknown 10y ago
  Fine cooking is a combination of simple things. You meld together a sequence of simple tasks that result in a complex recipe, but we still do the basics of cooking that our "caveman" ancestors did. When the simple things become unnecessarily complex, it prevents us from creating a good recipe. We get so caught up in the unnecessarily complex details that we lose site of the goal.
  - douche 10y ago
    >When the simple things become unnecessarily complex that's when the recipe shows up on Pinterest...
    - blub 10y ago
      No that's when you do molecular cuisine and need two bags of rice to make a simple 2cm x 2cm cookie.
- nol13 10y ago
  Not me I'm on paleo diet.
angryteabag 10y ago
As a novice developer, coming from Java, I was taken aback by how forceful and messy JS's async programming style is (I started with node.js then moved to the browser). Callbacks, promises, generators are all there to essentially make async code sync, which seems to make the code hard to follow, difficult to scale, modularise and debug. I think JS took this approach because of the limitation of older browsers, which were unable to use threading, so as to not block IO they forced concurrency using queues requiring async style code. We must have just stuck with it because it's just been around for long enough and it would be hard to get everyone to change. it's 2016 and I like being able to use the return values of my methods without sweating. PLEASE, for the love of god, replace JS with something with the same cushy syntax but makes sense. Then again, I could just be bad at programming and not know what I am talking about - I sincerely hope that is the case.
- douche 10y ago
  This kind of hits one of the problems with JS on the head. There are too many different ways to do things, at all levels of abstraction, because it was such a limited, dumpster-fire of a language for so long, implemented in so many mutually incompatible ways by every different version of every browser, and so to do anything much more complicated than wiring up some basic callbacks on a page, you had to roll big chunks of infrastructure that better designed and more mature languages built in. So you end up with a half-dozen different patterns for object-oriented programming, another half dozen patterns for making async code less awful, three or four different patters for defining modules, etc, ad nauseum. </rant>
- chug 10y ago
  > Callbacks, promises, generators are all there to essentially make async code sync I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync. Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000? The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient. I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around. There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS. In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node.
cttet 10y ago
I like this website to layout an argument nicely. But in the case Web Programming is not well-defined, the argument can just be people doing different things assuming others are doing the same.
- douche 10y ago
  I wonder how insane StackOverflow would look laid out with this kind of a presentation scheme...
danso 10y ago
Web programming is reaching not only far more people, but far more combinations of people and devices, in far more scenarios -- think of how many more ways you can do computing that don't involve sitting in front of a desktop, which for most non-technical people was a relative rarity in day to day life. So web programming should be more complicated because the world we now reach is far more complicated. But I don't feel like complexity has grown nearly as much as potential audience. And when things do get frustrating, such as trying to do a heavy client-side app, I just have to look at the PHP Reddit/stack overflow groups to get a reminder of how truly fucking annoying and confusing it was to build a full stack app a decade ago.
nevster 10y ago
I'm up-voting this purely due to finding out about arguman. I had an idea for a website exactly like this about 6 years ago. Kudos to the people who actually implemented it.
- dudouble 10y ago
  Me too.
  - AstralStorm 10y ago
    Sadly, it exemplified the problems due to not working well on small screens or with reflow reader modes.
  - cttet 10y ago
    Me too...
Tiquor 10y ago
Boo hoo. It's not that bad. Knuckle down and learn some shit. Crikey, some of us learned this stuff before a crowd sourced 90,000 word wiki and versioned online code repository was commonplace for a 200 line library. AND get off my lawn!!
WalterSear 10y ago
I, too, miss the days when web development was as simple as opening a file in notepad.exe and refreshing a browser. I made some boilerplate to solve this problem. If you are familiar with react, it shouldn take a few minutes of `git clone && npm i` to get started. https://github.com/Jon-Biz/simple-static-react https://github.com/Jon-Biz/simple-static-react There are a few version up there: one has a router, one has a firebase backend, one has Virtual Reality bindings. They all have the same purpose: to get out of your way as fast as possible.
- vectorpush 10y ago
  Web development is still that simple if you want it to be. Nothing is stopping you from writing for the web like it's 1991 if that's all you feel is necessary for your site.
  - WalterSear 10y ago
    While I agree that a genuinely static site should be written as such, I'm not writing websites that were possible in 1991, and I don't see why I should have to, to get simplicity and productivity: we've come a long way since then. So, I did a little bit of work to simplify my set up(s) and then to make it useful to others.
    - vectorpush 10y ago
      I'm not making a normative claim, my only point was that the same technology that worked 20 years ago still works today and it's the developer's fault if they don't like the tools they've chosen to use.
      - WalterSear 10y ago
        Well sure, but while I agree that the length and breadth of the toolchain has become stupidly long, the demands of today aren't the demands of yesterday. Take my VR boilerplate, for an extreme example: what are you supposed to use instead, VRML? :)
aardvark291 10y ago
"getting"?
gkya 10y ago
For publishers of content plain html and some little css would get you a result that's readable, and responsive (I think a better word for this is adaptive), if the authors are willing to give up their prescriptivisism on the rendering of their content. Compliant use of html and css almost always results in a page which the browser will know to display the best way with regards to the medium. But once one's determined to impose a certain layout no matter what, he takes on the browsers duty, and actually has to work towards implementing an abstraction layer that takes care of the incompatibilities of all different web browsers out there. Now there are libraries for this, so he fetches and uses them to unnecessarily impose his style. Eventually this is a needless burden on both him and the user, as while the megabytes pile up, load speed and performance decrease and Internet bills increase in price. As things skip and grow and shrink on the screen, the UX becomes cumbersome too. But if the primitives of html and css are used, all these issues are irrelevant. Another factor that complicates web page development is ads. They bring a huge pile of Javascript with them, but they go ignored most of the time and usually are a burden to the user. Ad providers, instead of publishing ads that would indeed get clicked intentionally (like the Deck network), bribe the publishers paying for user actions that aren't actual impressions. Thus they also create exaggerated statistics which they use to lure low quality ads which get the most clicks from accidental behaviour, leading to worse and worse ads that do whatever to catch attention but be actually interesting. Lastly, it is a fact that coding Javascript is more fun than writing a document. For the web developer, rendering innyeractive graphics with Javascript is certainly more fun than making them with R or gnuplot and insert into the page with an img tag and providing data and code used to generate them.
pklausler 10y ago
When it becomes easier for a site to write native iOS and Android apps for clients than it is to write a pretty JS front-end that works on all browsers, it's going to be bye-bye web as we know it.
- prawn 10y ago
  Except for the fact that installing apps is an unnecessarily annoying process, enough to mean that the majority of people very rarely install anything new on their devices.
  - rimantas 10y ago
    If single tap is unnecessarily annoying, then web is already dead because opening the web page is even more complicated.
    - prawn 10y ago
      Tap link, opens App Store, tap to install, wants me to login but I can't switch to 1Password without cancelling and starting again, enter password, agree to something about TouchID, T&Cs have changed so have to acknowledge them yet again. App installs to earliest screen that has a vacancy, so have to go through and find it. The process can be quicker or longer than that.
- rimantas 10y ago
  It was esier since the day 1.
thoman23 10y ago
It's funny how everyone seems to hate "big frameworks" while at the same time complaining about how "everyone uses them". It's sort of like the Yogi Berra line: "Nobody goes there anymore. It's too crowded." I for one will go against the flow (or am I with the flow?) and say that what I see coming out of Angular 2 looks FANTASTIC. Many of the things I love as a Scala developer are finally becoming mainstream on the client side. Add in the promise of NativeScript (mobile apps) and Electron (desktop apps) and this is an incredible time to be a web developer.
- thegayngler 10y ago
  Tbqh what is coming out of Angular 2 is React with a higher learning curve, more Angular specific syntax and not much in terms of a larger benefit. React keeps things simple and easy to reason about. I don't feel like I should need or be using decorator like syntax at all to create a component. I like looking at one file and knowing exactly what that one file is doing but that's just me.
careersuicide 10y ago
This arguman thing is really cool! It's such a neat idea in fact, that I'm willing to overlook the horizontal scrolling. That's saying a lot! With that out of the way... I'm firmly in the "but" camp here. I've been doing web programming for 17 years now. I remember the bad old days. Things were simple if all you wanted was HTML and images (CSS was still pretty iffy). But the moment you needed more than a static page? The complexity of getting up and running ballooned really quickly. And worst of all there were so few resources to really learn from. And it was expensive. Granted I was a teenager back then so anything more than a few dollars a month was pricey to me, but if you compare the kinds of hosting offerings of two decades ago to something like Digital Ocean or AWS today then the amount of possibilities is staggering (no more shared environment!) and for prices that are almost too cheap to believe. My recollection of getting anything up and running that used a database back then was that it was not for the faint of heart. Compare that to today and the process of getting everything set up and connected with Rails, Djano, Express, etc. Yes there's more stuff you "just have to know" in terms of code you write and yes you have a box you have to stay within because of the framework but I'll take that any day over gluing together some Perl scripts and hoping you've got CGI configured correctly. Maybe I'm conflating two separate things here: actual programming and operations. But I strongly contend that with web programming you can't disentangle those two things in any practical way. You will always be bound to the context of your environment. Anything that makes getting a sane environment easier leaves much more time to focus on the problem you actually care about. And it's not like you have to use all of the shiny new toys if you want to keep your code simple.
- gkya 10y ago
  The server code has way less problems than the UI part of websites (i.e. web pages). The complexity of putting up a webpage has made a very fast 0-60, where it now may involve several package managers, JS libraries, to-CSS compilers, multiple web browsers (multiple OS' if you want all of them), minifiers, uglifiers, build programs and whatnot. And most web pages from popular online publishers (news portals like the New York Times, blogs like the Huffington Post, etc.) the ratio of content to CSS, JS, and HTML tags goes towards 1/1000 and above. Most of the time features of browser are reimplemented (history, page loading, scrolling...) and standard behaviours hijacked (most often scrolling, clicks). Every website designs and imposes it's own UI paradigm so that clicking around becomes a frightening and challenging thing, as telling what is a link, what is a button, what is a drop-down, etc. is hard, as either these are heavily styled to the point of being unrecognisable or they are reimplemented in JS and the behaviour is unpredictable. This hurts especially when doing critical things like money transactions, various registrations that have become online recently, various rendez-vous, etc. Together with this trends, HTML, CSS, and JS get more and more complex in the specification level, which together with cancrous tooling, make entry to web development (i.e. writing webpages or writing programs that write webpages) harder and harder.
Falkon1313 10y ago
In my early days of programming, things began with realizing that I could use this wonderfully powerful system to solve problems (almost any problem you could model!) and create things (almost anything you could want to simulate!). I just had to figure out how to model the domain problem logically in a useful way, or what aspects of something to simulate, and how to allow the user to interact with it. That soon changed. In learning about programming, one can't help but to come across the writings of those preaching the gospel of the holy virtues of 'reusable code'. Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains! So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other. Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we're using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won't perform so horrendously that customers immediately give up on it. We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less). We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data. We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn't even designed with the domain in mind. As a profession, we've gone way too overboard trying to do everything with reusable code. This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system). And it's kind of amusing that we're now adding layers of complexity to manage the layers of complexity. I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things. For that we need a new doctrine of vertical development that doesn't just religiously say "Throw another layer of indirection and generic abstraction on it! Yay reusable code!" as a sacred solution for everything. Sure, code reuse can be good, but let's be sensible about it, not kid-in-a-candy-store crazy.
- EGreg 10y ago
  I started out doing that. And inevitably I'd wind up refactoring multiple similar projects into reusable code and conventions. Over many years I arrived at this: http://qbix.com/platform http://qbix.com/platform Now I can assemble a website that works everywhere and has best practices, by expressing exactly what I want in high level code. When modeling a new app or talking to our developers about architecture, we can use a common language of users, communities, streams, access, realtime pushes and offline notifications etc. People know what I mean when I say "the Patients/account streams should be published by the community and have Patients/photo stream templates for the admin role, related to Patients/gallery category stream published by the logged-in user." Everything is namespaced, reusable, interoperable and works on every device. It took a long time to make the system but now we can assemble apps like out of building blocks, and have anyone work on anything and know what the conventions are. So yeah, it's paid off!!
deleted 10y ago
[deleted]
Fifer82 10y ago
Edinburgh Scotland: Seeking Junior Developer 19k. Must know all the CSS preprocessors, all CMS's, all modern frameworks, all of software engineering, all of the server side in all languages.... Ideally has experience of everything. Must have worked Agile. Needless to say, 7 years into my actual Web Programming career and I am resigned to being stuck in a bad role. I don't have the confidence to apply to anything since your expected to be an expert in what they announce tomorrow in the next conference (and you had to do it in your own time) and if I do, the pay is garbage. I personally blame Recruitment Agencies for not having a clue what is being asked for, setting a false market rate (maxium commission = race to the bottom), and making the barrier to entry or even sell yourself impossible. In short, I hope this year to re-boot my career outside of computing as pretty much everyone I know makes more money than I do.
- deleted 10y ago
  [deleted]
- kiksy 10y ago
  I don't have much experience with the job market north of the border, but I'd say your situation would be atypical. I'm outside of London and have seen what you've described but the reality is that there is a shortage of people with the skills you've described in that theoretical role. I'd advise you line up 4-5 interviews and just go and see how they work out. With 7 years experience I'd expect you to be able to walk into a lot of positions without fuss which pay much much more than £19k.
  - Fifer82 10y ago
    Thank's for taking the time to reply Kiksy. I appreciate it as I am a lone developer and don't really have any real career advice. I just know that I never seem to match my experience to any roles and it has been a while.
- Alex6534 10y ago
  Also in Edinburgh, part time an on about £10k. Mixture of front end dev, Drupal 7, Ios and Android development. Mind me asking where you work? I'm on my ast semester of uni and 3-4 years experience so isn't too bad, but the recruitment spam is crazy.
jaequery 10y ago
First thing that popped up in my head as I read this, React/Redux. :)
- quantumhobbit 10y ago
  Meh. React + the twenty other things you need to add on to it is bad, but somehow no worse than angular is by itself.
  - jaequery 10y ago
    Yes I reckon this thread is pointing at the whole client side frameworks landscape right now
  - deleted 10y ago
    [deleted]
velmu 10y ago
I think maybe web technologies are now everywhere and where it once took a systems programmer to do certain types of things, now you're expected to do that because "JavaScript is everywhere". The language does not make the difficult problems easy to solve. More: http://medium.com/@velmu/on-ubiquitous-javascript-and-the-unreasonable-expectations-developers-can-set-themselves-f6994c07acd3 http://medium.com/@velmu/on-ubiquitous-javascript-and-the-un...
zem 10y ago
i had very high hopes for opa [http://opalang.org/]; http://opalang.org/]; i'm still sad it didn't catch on instead of node
nikdaheratik 10y ago
I think there are many things pushing towards more complexity, and not much of it is "bored developers pushing things to polish resumes". 1. It takes longer to teach someone even "simple" web dev than it does to leverage the programming talents of experienced devs. This means businesses are better off making tools that allow a small group of devs to create many simple websites or a few really complex websites than just keeping it simple. Even a small dev company can produce output that matches what used to only be possible with the resources of a much larger software company. 2. As they mentioned, the path web dev is going is towards a device independent software dev environment instead of simply serving up content or a few simple tools. This is across the board from internal IT, to small B2B, to large B2C resources. Alot of my personal programming time is adjusting the generic B2B platform to meet the needs of a specific client we have that doesn't quite fit the original project. It's frustrating, but a large source of complexity and not "unnecessary" since it pays the bills. 3. The number of devices that have to be supported by a platform is also greatly increasing, and it makes the code itself, especially on the js side, much more complex in response. I'm continually thinking "why do you want to squish our site down to your piddly little phone", but that's the primary way alot of users have access, and if you don't support it, you'll lose out to competitors that do.
ctulek 10y ago
I am not sure if it is getting complicated in terms of libraries and frameworks. We had prototype vs jquery wars, or gwt, dojo or yui discussions. I bet the problem is Github! I mean, we are the victim of their success in solving one of our bottlenecks: collaboration. Now it is not only easier to start a project but equally easier to get followers, adapters, and contributors.

Tell me about it, or don't, it's up to you. js;dr

I wonder how many are like me (old school? Just old??) and eschew platforms and libraries and roll my own most of the time, because most of the time, the needs are simple, and it's quicker to pound something out rather than learn and use Yet Another Framework. Though using jquery is nice sometimes...

johnloeber 10y ago
That's the approach I took to hand-rolling my personal website. All I care about is delivering my content reasonably well -- the elegance or modernity of the underlying engineering seems irrelevant. (Not to mention that this minimizes website bloat...)
pavlov 10y ago
I do that. Web dev is not my main focus, but I have to deal with it all the time. I try to attack the problems with an initial prototype that's a combination of plain HTML+JS and Node.js. Instead of a database, I tend to reuse a simple Javascript class I wrote a couple of years back that provides a minimalist layer of persistence for collections using an append-only file. (It's really just a single file I copy to any new projects when it's time to store something.) Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it. So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity. (I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
- msane 10y ago
  I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It also has a bad zealot problem, where Facebook has cleverly brought a lot of people to it who haven't seen anything else and are convinced it is the bee's knees. > The library is very useful for (?) UI problems... Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it". Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines. > ...toolchain fetishism which tends to cloud React's fundamental simplicity This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
  - microcolonel 10y ago
    I frankly don't see how you could come to the conclusion that Angular 2 components are simpler than React components. I mean, in React, a component can be as simple as const MyComponent = () => <span> some markup nonsense </span>;
    - msane 10y ago
      Yup that's the argument mentioned: React is "simpler", "anyone can see"... Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about. myMod.component('Foo', { template: '<h1>{{$and.better.templating}} {{see()}}</h1>', controller: function() { var and = {this_one: 'does_stuff'}; } });
      - thegayngler 10y ago
        This is not easier to reason about than returning jsx IMO... It's only 1 of the ways to build an angular 2 component. The website tutorial is using decorator syntax. Typescript Angular 2 documentation. What's wrong with just learning JavaScript and less Angular specific syntax and tooling. Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems. React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
fenomas 10y ago
> eschew platforms and libraries and roll my own most of the time That's what nearly everybody does, when they're one person hacking on a one-off project. I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
- pavlov 10y ago
  Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles. There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
  - buckbova 10y ago
    I picked up Angular quickly, insisted everyone in my group follow this style guide. https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide We didn't need an expert.
    - jasonm23 10y ago
      Seems you were lucky that the expert you didn't need had written up a style guide.
      - buckbova 10y ago
        Definitely. We live in wonderful times.
    - thegayngler 10y ago
      I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake. I don't want to be hunting all over my code base just to figure out what is happening in a controller or component. JPs styleguide is awesome!
hajile 10y ago
It's not so much a change in technology as it is a shift in focus. If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade. Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives. If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
- blub 10y ago
  Web app with complex data = website that can be done very well with html, css and a server-side language. It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated". Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
  - onion2k 10y ago
    Web app with complex data = website that can be done very well with html, css and a server-side language. Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb. My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage. Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
notliketherest 10y ago
wow this attitude is so sad! React + Redux - changed my whole outlook on web development and it's actually a joy again. Take a little bit of time, read, learn, figure out a simple webpack script, and you're gonna love life.
kalleboo 10y ago
Most of the web stuff I have to work on is developed once, and then maintained rarely (once a year or so). It's not the kind of project that has continuous development. So whenever I've used a framework or SDK, when it comes time to add a small feature or tweak, I spend more time bringing the project up to date with the latest version of the framework or SDK than I do implementing the feature. Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
- polishninja 10y ago
  I've run into this issue multiple times as well.
blub 10y ago
I think there's a lot of social pressure from rockstar web developers to build and use JS libraries and frameworks. Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses. So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
- jasonthevillain 10y ago
  > And excuses about how today's customers expect an app-like experience Yes. If anyone has evidence of this I'd love to see it.
pbreit 10y ago
I'm still sort of a newbie but I have found it much much easier for me to quickly build my projects on the very very easy to use Web2py Python framework. The things I like are: defining my DB structure in simple code, no routing (routing is implied by file & function names), Python, HTML views with simple embedded code (including full Python if need/want).

kiba 10y ago

Because people are trying to cram down 10 different JS libraries down the throat of a static page?

draw_down 10y ago

I mean, the entire name of the game is unnecessary complication. We took a document platform and mangled it into an app platform... kinda.

copperx 10y ago
We need to remind ourselves frequently that the web is a terrible platform. Yes, TCP/IP changed the world, but the web is an embarrassment to our field. It could be so much more.
- gkya 10y ago
  Web is good. It's how we use it. If web was sex, todays web dev is basically gang rape.
- collyw 10y ago
  It is beautifully cross platform. A claim that Java made but never lived up to.

formula1 10y ago

Well yes and no. Javascript problems are what php used to solve before. Its actually necessarilly complicated if you view it from what javascript is attempting to replace. On top of replacement, theres another question "is the common road the best road?". Something as simple as a html5 video tag can be replicated through a canvas, html5 audio and some ui elements. And as things get more complicated, are we better off pretending complexity is the enemy? The reality is that these are problems all languages have to deal with. The reason the web is getting the most is because its the most widely consumed abd provided. Why be involved in an ecosystem dominated by coorperate entities that would only pay you just enough so you wont leave when you can be in an environment where insanity is an acceptable road to sanity. Why the hell does coffee script exist? It doesnt matter.

sp527 10y ago

Clientside code execution makes sense. Every last thing that can be offloaded to the client should be. The tooling around this concept may be insufficient or difficult to use, but the underlying premise is undeniably sound.

jasonthevillain 10y ago
Not necessarily. The client device may be old, underpowered, slow, and running out of battery. Which isn't to say thick clients are always a bad idea, but they're not the One True Answer™.
- sp527 10y ago
  Hah I rushed that answer but yes totally agree. When I'm dev'ing for web, I always monitor perf against a crappy old Android phone. Similarly, Chrome devtools makes it easy to simulate a bad network connection. I try to make sure it's tolerable. Also worth noting that analytics makes it easy to determine what device/OS the majority of your visitors are using. Anyone building an app would be wise to pay close attention to this to guide dev efforts.

cm127 10y ago

Ironically, I find that tree format unnecessarily complicated.

rajington 10y ago

"Cooking is getting unnecessarily complicated." - Caveman Compare food nowadays to centuries ago, I'm glad things got unnecessarily complicated.

copperx 10y ago
Food production is complicated because of scale. But food itself hasn't changed much in centuries. The only real difference is that all the world's spices are available to common folk in Nowhere, TX.
- aaronblohowiak 10y ago
  Refrigeration
personsunknown 10y ago
Fine cooking is a combination of simple things. You meld together a sequence of simple tasks that result in a complex recipe, but we still do the basics of cooking that our "caveman" ancestors did. When the simple things become unnecessarily complex, it prevents us from creating a good recipe. We get so caught up in the unnecessarily complex details that we lose site of the goal.
- douche 10y ago
  >When the simple things become unnecessarily complex that's when the recipe shows up on Pinterest...
  - blub 10y ago
    No that's when you do molecular cuisine and need two bags of rice to make a simple 2cm x 2cm cookie.
nol13 10y ago
Not me I'm on paleo diet.

angryteabag 10y ago

As a novice developer, coming from Java, I was taken aback by how forceful and messy JS's async programming style is (I started with node.js then moved to the browser). Callbacks, promises, generators are all there to essentially make async code sync, which seems to make the code hard to follow, difficult to scale, modularise and debug. I think JS took this approach because of the limitation of older browsers, which were unable to use threading, so as to not block IO they forced concurrency using queues requiring async style code. We must have just stuck with it because it's just been around for long enough and it would be hard to get everyone to change. it's 2016 and I like being able to use the return values of my methods without sweating. PLEASE, for the love of god, replace JS with something with the same cushy syntax but makes sense. Then again, I could just be bad at programming and not know what I am talking about - I sincerely hope that is the case.

douche 10y ago
This kind of hits one of the problems with JS on the head. There are too many different ways to do things, at all levels of abstraction, because it was such a limited, dumpster-fire of a language for so long, implemented in so many mutually incompatible ways by every different version of every browser, and so to do anything much more complicated than wiring up some basic callbacks on a page, you had to roll big chunks of infrastructure that better designed and more mature languages built in. So you end up with a half-dozen different patterns for object-oriented programming, another half dozen patterns for making async code less awful, three or four different patters for defining modules, etc, ad nauseum. </rant>
chug 10y ago
> Callbacks, promises, generators are all there to essentially make async code sync I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync. Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000? The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient. I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around. There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS. In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node.

cttet 10y ago

I like this website to layout an argument nicely. But in the case Web Programming is not well-defined, the argument can just be people doing different things assuming others are doing the same.

douche 10y ago
I wonder how insane StackOverflow would look laid out with this kind of a presentation scheme...

danso 10y ago

Web programming is reaching not only far more people, but far more combinations of people and devices, in far more scenarios -- think of how many more ways you can do computing that don't involve sitting in front of a desktop, which for most non-technical people was a relative rarity in day to day life. So web programming should be more complicated because the world we now reach is far more complicated. But I don't feel like complexity has grown nearly as much as potential audience. And when things do get frustrating, such as trying to do a heavy client-side app, I just have to look at the PHP Reddit/stack overflow groups to get a reminder of how truly fucking annoying and confusing it was to build a full stack app a decade ago.

nevster 10y ago

I'm up-voting this purely due to finding out about arguman. I had an idea for a website exactly like this about 6 years ago. Kudos to the people who actually implemented it.

dudouble 10y ago
Me too.
- AstralStorm 10y ago
  Sadly, it exemplified the problems due to not working well on small screens or with reflow reader modes.
- cttet 10y ago
  Me too...

Tiquor 10y ago

Boo hoo. It's not that bad. Knuckle down and learn some shit. Crikey, some of us learned this stuff before a crowd sourced 90,000 word wiki and versioned online code repository was commonplace for a 200 line library. AND get off my lawn!!

WalterSear 10y ago

I, too, miss the days when web development was as simple as opening a file in notepad.exe and refreshing a browser. I made some boilerplate to solve this problem. If you are familiar with react, it shouldn take a few minutes of `git clone && npm i` to get started. https://github.com/Jon-Biz/simple-static-react https://github.com/Jon-Biz/simple-static-react There are a few version up there: one has a router, one has a firebase backend, one has Virtual Reality bindings. They all have the same purpose: to get out of your way as fast as possible.

vectorpush 10y ago
Web development is still that simple if you want it to be. Nothing is stopping you from writing for the web like it's 1991 if that's all you feel is necessary for your site.
- WalterSear 10y ago
  While I agree that a genuinely static site should be written as such, I'm not writing websites that were possible in 1991, and I don't see why I should have to, to get simplicity and productivity: we've come a long way since then. So, I did a little bit of work to simplify my set up(s) and then to make it useful to others.
  - vectorpush 10y ago
    I'm not making a normative claim, my only point was that the same technology that worked 20 years ago still works today and it's the developer's fault if they don't like the tools they've chosen to use.
    - WalterSear 10y ago
      Well sure, but while I agree that the length and breadth of the toolchain has become stupidly long, the demands of today aren't the demands of yesterday. Take my VR boilerplate, for an extreme example: what are you supposed to use instead, VRML? :)

aardvark291 10y ago

"getting"?

gkya 10y ago

For publishers of content plain html and some little css would get you a result that's readable, and responsive (I think a better word for this is adaptive), if the authors are willing to give up their prescriptivisism on the rendering of their content. Compliant use of html and css almost always results in a page which the browser will know to display the best way with regards to the medium. But once one's determined to impose a certain layout no matter what, he takes on the browsers duty, and actually has to work towards implementing an abstraction layer that takes care of the incompatibilities of all different web browsers out there. Now there are libraries for this, so he fetches and uses them to unnecessarily impose his style. Eventually this is a needless burden on both him and the user, as while the megabytes pile up, load speed and performance decrease and Internet bills increase in price. As things skip and grow and shrink on the screen, the UX becomes cumbersome too. But if the primitives of html and css are used, all these issues are irrelevant. Another factor that complicates web page development is ads. They bring a huge pile of Javascript with them, but they go ignored most of the time and usually are a burden to the user. Ad providers, instead of publishing ads that would indeed get clicked intentionally (like the Deck network), bribe the publishers paying for user actions that aren't actual impressions. Thus they also create exaggerated statistics which they use to lure low quality ads which get the most clicks from accidental behaviour, leading to worse and worse ads that do whatever to catch attention but be actually interesting. Lastly, it is a fact that coding Javascript is more fun than writing a document. For the web developer, rendering innyeractive graphics with Javascript is certainly more fun than making them with R or gnuplot and insert into the page with an img tag and providing data and code used to generate them.

pklausler 10y ago

When it becomes easier for a site to write native iOS and Android apps for clients than it is to write a pretty JS front-end that works on all browsers, it's going to be bye-bye web as we know it.

prawn 10y ago
Except for the fact that installing apps is an unnecessarily annoying process, enough to mean that the majority of people very rarely install anything new on their devices.
- rimantas 10y ago
  If single tap is unnecessarily annoying, then web is already dead because opening the web page is even more complicated.
  - prawn 10y ago
    Tap link, opens App Store, tap to install, wants me to login but I can't switch to 1Password without cancelling and starting again, enter password, agree to something about TouchID, T&Cs have changed so have to acknowledge them yet again. App installs to earliest screen that has a vacancy, so have to go through and find it. The process can be quicker or longer than that.
rimantas 10y ago
It was esier since the day 1.

thoman23 10y ago

It's funny how everyone seems to hate "big frameworks" while at the same time complaining about how "everyone uses them". It's sort of like the Yogi Berra line: "Nobody goes there anymore. It's too crowded." I for one will go against the flow (or am I with the flow?) and say that what I see coming out of Angular 2 looks FANTASTIC. Many of the things I love as a Scala developer are finally becoming mainstream on the client side. Add in the promise of NativeScript (mobile apps) and Electron (desktop apps) and this is an incredible time to be a web developer.

thegayngler 10y ago
Tbqh what is coming out of Angular 2 is React with a higher learning curve, more Angular specific syntax and not much in terms of a larger benefit. React keeps things simple and easy to reason about. I don't feel like I should need or be using decorator like syntax at all to create a component. I like looking at one file and knowing exactly what that one file is doing but that's just me.

careersuicide 10y ago

This arguman thing is really cool! It's such a neat idea in fact, that I'm willing to overlook the horizontal scrolling. That's saying a lot! With that out of the way... I'm firmly in the "but" camp here. I've been doing web programming for 17 years now. I remember the bad old days. Things were simple if all you wanted was HTML and images (CSS was still pretty iffy). But the moment you needed more than a static page? The complexity of getting up and running ballooned really quickly. And worst of all there were so few resources to really learn from. And it was expensive. Granted I was a teenager back then so anything more than a few dollars a month was pricey to me, but if you compare the kinds of hosting offerings of two decades ago to something like Digital Ocean or AWS today then the amount of possibilities is staggering (no more shared environment!) and for prices that are almost too cheap to believe. My recollection of getting anything up and running that used a database back then was that it was not for the faint of heart. Compare that to today and the process of getting everything set up and connected with Rails, Djano, Express, etc. Yes there's more stuff you "just have to know" in terms of code you write and yes you have a box you have to stay within because of the framework but I'll take that any day over gluing together some Perl scripts and hoping you've got CGI configured correctly. Maybe I'm conflating two separate things here: actual programming and operations. But I strongly contend that with web programming you can't disentangle those two things in any practical way. You will always be bound to the context of your environment. Anything that makes getting a sane environment easier leaves much more time to focus on the problem you actually care about. And it's not like you have to use all of the shiny new toys if you want to keep your code simple.

gkya 10y ago
The server code has way less problems than the UI part of websites (i.e. web pages). The complexity of putting up a webpage has made a very fast 0-60, where it now may involve several package managers, JS libraries, to-CSS compilers, multiple web browsers (multiple OS' if you want all of them), minifiers, uglifiers, build programs and whatnot. And most web pages from popular online publishers (news portals like the New York Times, blogs like the Huffington Post, etc.) the ratio of content to CSS, JS, and HTML tags goes towards 1/1000 and above. Most of the time features of browser are reimplemented (history, page loading, scrolling...) and standard behaviours hijacked (most often scrolling, clicks). Every website designs and imposes it's own UI paradigm so that clicking around becomes a frightening and challenging thing, as telling what is a link, what is a button, what is a drop-down, etc. is hard, as either these are heavily styled to the point of being unrecognisable or they are reimplemented in JS and the behaviour is unpredictable. This hurts especially when doing critical things like money transactions, various registrations that have become online recently, various rendez-vous, etc. Together with this trends, HTML, CSS, and JS get more and more complex in the specification level, which together with cancrous tooling, make entry to web development (i.e. writing webpages or writing programs that write webpages) harder and harder.

Falkon1313 10y ago

In my early days of programming, things began with realizing that I could use this wonderfully powerful system to solve problems (almost any problem you could model!) and create things (almost anything you could want to simulate!). I just had to figure out how to model the domain problem logically in a useful way, or what aspects of something to simulate, and how to allow the user to interact with it. That soon changed. In learning about programming, one can't help but to come across the writings of those preaching the gospel of the holy virtues of 'reusable code'. Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains! So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other. Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we're using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won't perform so horrendously that customers immediately give up on it. We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less). We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data. We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn't even designed with the domain in mind. As a profession, we've gone way too overboard trying to do everything with reusable code. This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system). And it's kind of amusing that we're now adding layers of complexity to manage the layers of complexity. I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things. For that we need a new doctrine of vertical development that doesn't just religiously say "Throw another layer of indirection and generic abstraction on it! Yay reusable code!" as a sacred solution for everything. Sure, code reuse can be good, but let's be sensible about it, not kid-in-a-candy-store crazy.

EGreg 10y ago
I started out doing that. And inevitably I'd wind up refactoring multiple similar projects into reusable code and conventions. Over many years I arrived at this: http://qbix.com/platform http://qbix.com/platform Now I can assemble a website that works everywhere and has best practices, by expressing exactly what I want in high level code. When modeling a new app or talking to our developers about architecture, we can use a common language of users, communities, streams, access, realtime pushes and offline notifications etc. People know what I mean when I say "the Patients/account streams should be published by the community and have Patients/photo stream templates for the admin role, related to Patients/gallery category stream published by the logged-in user." Everything is namespaced, reusable, interoperable and works on every device. It took a long time to make the system but now we can assemble apps like out of building blocks, and have anyone work on anything and know what the conventions are. So yeah, it's paid off!!

deleted 10y ago

[deleted]

Fifer82 10y ago

Edinburgh Scotland: Seeking Junior Developer 19k. Must know all the CSS preprocessors, all CMS's, all modern frameworks, all of software engineering, all of the server side in all languages.... Ideally has experience of everything. Must have worked Agile. Needless to say, 7 years into my actual Web Programming career and I am resigned to being stuck in a bad role. I don't have the confidence to apply to anything since your expected to be an expert in what they announce tomorrow in the next conference (and you had to do it in your own time) and if I do, the pay is garbage. I personally blame Recruitment Agencies for not having a clue what is being asked for, setting a false market rate (maxium commission = race to the bottom), and making the barrier to entry or even sell yourself impossible. In short, I hope this year to re-boot my career outside of computing as pretty much everyone I know makes more money than I do.

deleted 10y ago
[deleted]
kiksy 10y ago
I don't have much experience with the job market north of the border, but I'd say your situation would be atypical. I'm outside of London and have seen what you've described but the reality is that there is a shortage of people with the skills you've described in that theoretical role. I'd advise you line up 4-5 interviews and just go and see how they work out. With 7 years experience I'd expect you to be able to walk into a lot of positions without fuss which pay much much more than £19k.
- Fifer82 10y ago
  Thank's for taking the time to reply Kiksy. I appreciate it as I am a lone developer and don't really have any real career advice. I just know that I never seem to match my experience to any roles and it has been a while.
Alex6534 10y ago
Also in Edinburgh, part time an on about £10k. Mixture of front end dev, Drupal 7, Ios and Android development. Mind me asking where you work? I'm on my ast semester of uni and 3-4 years experience so isn't too bad, but the recruitment spam is crazy.

jaequery 10y ago

First thing that popped up in my head as I read this, React/Redux. :)

quantumhobbit 10y ago
Meh. React + the twenty other things you need to add on to it is bad, but somehow no worse than angular is by itself.
- jaequery 10y ago
  Yes I reckon this thread is pointing at the whole client side frameworks landscape right now
- deleted 10y ago
  [deleted]

velmu 10y ago

I think maybe web technologies are now everywhere and where it once took a systems programmer to do certain types of things, now you're expected to do that because "JavaScript is everywhere". The language does not make the difficult problems easy to solve. More: http://medium.com/@velmu/on-ubiquitous-javascript-and-the-unreasonable-expectations-developers-can-set-themselves-f6994c07acd3 http://medium.com/@velmu/on-ubiquitous-javascript-and-the-un...

zem 10y ago

i had very high hopes for opa [http://opalang.org/]; http://opalang.org/]; i'm still sad it didn't catch on instead of node

nikdaheratik 10y ago

I think there are many things pushing towards more complexity, and not much of it is "bored developers pushing things to polish resumes". 1. It takes longer to teach someone even "simple" web dev than it does to leverage the programming talents of experienced devs. This means businesses are better off making tools that allow a small group of devs to create many simple websites or a few really complex websites than just keeping it simple. Even a small dev company can produce output that matches what used to only be possible with the resources of a much larger software company. 2. As they mentioned, the path web dev is going is towards a device independent software dev environment instead of simply serving up content or a few simple tools. This is across the board from internal IT, to small B2B, to large B2C resources. Alot of my personal programming time is adjusting the generic B2B platform to meet the needs of a specific client we have that doesn't quite fit the original project. It's frustrating, but a large source of complexity and not "unnecessary" since it pays the bills. 3. The number of devices that have to be supported by a platform is also greatly increasing, and it makes the code itself, especially on the js side, much more complex in response. I'm continually thinking "why do you want to squish our site down to your piddly little phone", but that's the primary way alot of users have access, and if you don't support it, you'll lose out to competitors that do.

ctulek 10y ago

I am not sure if it is getting complicated in terms of libraries and frameworks. We had prototype vs jquery wars, or gwt, dojo or yui discussions. I bet the problem is Github! I mean, we are the victim of their success in solving one of our bottlenecks: collaboration. Now it is not only easier to start a project but equally easier to get followers, adapters, and contributors.