72 ms·

Why is modern web development so complicated?

• heyoni 7y ago
  I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.
  • slx26 7y ago
    Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!
    • dpau 7y ago
      For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)
    • EpicEng 7y ago
      For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening. Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why. Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
      • xrd 7y ago
        And the documentation is written by fanboys who are marketing it more than they are documenting it.
        • EpicEng 7y ago
          Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.
    • heyoni 7y ago
      And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\
    • Dig1t 7y ago
      To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.
      • rhn_mk1 7y ago
        With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?). Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
    • jdashg 7y ago
      Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.
    • gerbilly 7y ago
      It's the difference between a difficult problem, and a complex one. I think most of us here would find complexity more interesting. Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
    • muzani 7y ago
      I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.
  • hajile 7y ago
    Flexbox? That's way easier than float design and both of those are way easier than designing everything with tables.
    • heyoni 7y ago
      I know...and I kind of got the gist of it except I had a lot of trouble developing an intuition for it by trying to understand the history, other methods and just basically copying source code from existing websites...it's just my process for learning new things and it quickly gets overwhelming with front-end development...
      • afarrell 7y ago
        Repeatedly playing https://flexboxfroggy.com/ https://flexboxfroggy.com/ is better for developing intuition.
        • heyoni 7y ago
          I absolutely need to get back into front-end so thanks for that!
        • scns 7y ago
          https://mastery.games https://mastery.games is fun too
      • benbristow 7y ago
        I see what you mean. I've been using flexbox for a while now and still get muddled up if align- or justify- is vertical or horizontal Thankfully with modern browsers nowadays you can open up their dev tools and use them as a 'scratchpad' to play about with CSS.
      • wlesieutre 7y ago
        I like this guide for flexbox: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Breaks it down into simple pieces and explains with clear diagrams.
  • taf2 7y ago
    Really? I mean sure maybe the solution to your race condition is a thread safe queue... but if that’s not it then I definitely think fixing an issue with css is way easier... also The DOM api is finite and pretty well documented... MDN has done a pretty good job. Maybe something with WebRTC is trickier?
  • jancsika 7y ago
    I'll take flexbox then. And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.
  • dexwiz 7y ago
    I don't know, but I would rather weld steel together in a sky scraper than figure out how to hang cabinets or even understand all the different types of crown molding. I always think the backend versus front end statements are hilarious when cast to other activites. They always carry a tone of derision while completely missing the point that they are different problem spaces and skill sets.
    • saidajigumi 7y ago
      Also, {french cleats,flexbox} are awesome for {hanging stuff, sane and responsive page layout} and really pretty simple. [1] https://en.wikipedia.org/wiki/French_cleat https://en.wikipedia.org/wiki/French_cleat
  • baddox 7y ago
    Might that be simply because you are more interested in the one thing than the other? I can't come up with any objective measure of complexity that could show flexbox as being more complex than multithreading.
    • heyoni 7y ago
      A large part is definitely because I get overwhelmed and have trouble ignoring the "magic" that the article talks about.
  • jwilliams 7y ago
    Actually agree -- but with some nuance. I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal... Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."
  • reroute1 7y ago
    To be fair you can have most of this on the front end also
  • robocat 7y ago
    > rather fix a race condition on a multithreaded application You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks). Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout(). Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(
  • arithma 7y ago
    Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism. The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated. I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up. Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack. I would not dread doing frontend development, if allowed to do things correctly.
  • austincheney 7y ago
    The DOM is stupid easy. Start with this: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml
• moocowtruck 7y ago
  nice article; I don't really find it that complicated, only extremely useful.. In fact without it i would be quite the sad panda especially as I'm still required to support IE11 for foreseeable future in many large apps. But ya, if you don't need it don't use it. I'm sure as heck glad all the tooling I have now exists though!
• jandrese 7y ago
  The downside of using a code converter is that when something does break, the browser is going to show you the generated code and you have to map that back into your original code. If the generated code is ugly (hint: it's always ugly) then this can be a real problem. The generators can also do things in really dumb ways that make it slow or resource intensive and you'll have no clue why your elegant solution is running like a dog unless you go through and read the horrible generated code to see what it is actually doing.
  • the-pigeon 7y ago
    Source maps help a ton with this. Have never had an issue figuring out where the heck an exception came from when I've had source maps setup correctly.
  • alkonaut 7y ago
    So that's one source of complexity/difficulty: our "debugger" is a bloody web browser. And there may be transpilers between what we write and what the debugger sees as the source.
• justicezyx 7y ago
  AFAIK, any modern development is so complicated. Setup a web server: * VM from Cloud provider * Installing a bunch of staff * Throwing in a k8s cluster * Service mesh * Yaml files * Various network configuration * DNS * Firewall * Security etc.
  • paavohtl 7y ago
    Alternatively: provision a Heroku dyno, add a single-line Procfile, git push heroku and you're done.
    • justicezyx 7y ago
      Let's not pretend that Heroku is that popular to swing the main stream steup.
• johnwheeler 7y ago
  My thought is it has to be a product of the language. Javascript can be used imperatively, declaratively, procedurally, and functionally, so it is. That coupled with the fact that it’s probably the most widely distributed interpreter so lots of people use it and ideas come out at a rapid clip. Then there are the vendor differences...
• amiga-workbench 7y ago
  Because web developers have massive a chip on their shoulder about not being """real""" developers. So now we have meme frameworks and transpilers and hysterical build toolchains all for a platform for sharing documents.
  • redleggedfrog 7y ago
    Sad that you're voted down. I'm a developer and I agree with the sentiment. Web browsers are being used as a run time.
    • amiga-workbench 7y ago
      It's completely maddening because the domain has an incredible amount of complexity before you go inventing more to pile on.
    • hahamrfunnyguy 7y ago
      And we've been using them that way for a long time. The reason is it's so simple to deploy an app, no more developing cross-platform apps for Windows, OS X and Linux along with installers for them. I remember working on simple apps where the installation and deployment took longer than developing the app itself! HTML/JavaScript isn't the best way to develop an app, but it's good enough and you can develop very good apps with it.
    • ng12 7y ago
      > Web browsers are being used as a run time. Yes, because that's valuable to the business. My department makes money doing what we do, I'm making my life easier using an SPA framework.
  • the-pigeon 7y ago
    I've been working as a full stack web developer for the last 15 years during this transformation and this couldn't be further from the truth. No full stack developer feels they aren't a real developer. But I think more than anything the full stack's have been the drive of a lot of this complications because all these complications make everything way easier for us. Web development today is easy (compared to 15 years ago) once you know this toolchain. And for professionals, tools that take a long time to learn but increase productivity tremendously are much better than tools that are easy to learn but slow to use. Of course we'll figure out how to simplify this toolchain over time. But things have been improving across the board for professionals. It is unfortunate that the barrier to entry seems to be raising even higher. But a trade-off we seem to be fine making.
• s_y_n_t_a_x 7y ago
  Because we're no longer making websites, we're making apps. Sure if you just need a simple website, make it from scratch, but good luck maintaining a full blown app using jQuery. It's not just web development that is hard. You can't honestly say any toolchain on the desktop side is any easier. That said, web development is getting easier now that the dust is settling and only a few major frameworks are used. Get started with create-react-app. React is the industry standard, use it. 1) Install NodeJS 2) npx create-react-app demo
  • swiley 7y ago
    You can’t get simpler than Python and tkinter (or just strait TCL/tk.) Packaging these without depending on preinstalled software is hard (you probably shouldn’t even bother trying on Linux, everyone there expects installing weird stuff to involve using either git or a container anyway.) As far as I can tell the main reason people don’t use it is that it can’t make iPhone apps.
    • nsfmc 7y ago
      great, now you have a native client but now your customers will expect that it works offline, so now you're building a sync system for your app. additionally, if your app has any design/layout issues, now you need to hire for people that can do visual layout using tcl/tk. If your app consumes rich text, you're in for a real treat as you are now on the hook for figuring out how to manage that as well (in addition to serialization, you also need it to likely be emitted into some web friendly format anyway. if your app consumes some feed (say new-user facing features or whatever), you need to find some meta-format that your app can use to layout that content (or i mean, i guess you can use a webview, but then...) if your customers are enterprise-ey, you are now dealing with some overzealous IT dept that is skeptical of your application running with user permissions. if you're trying to push a fix/update to your users, you now need to build infra around deploying new apps as well as customer support determining if users are somehow running old versions when they report a bug. the web is a total "mo money, mo problems" situation, but i think people dismiss how many problems the web solves for your developers on a day to day basis: easy to push updates, simple to whitelist your app's domain on some restricted network, easy add dynamic content/layout to portions of your app with stored content, (less sync resolution issues because your app probably requires network to operate) etc. Native apps have their own issues, they're great, don't get me wrong, but people demand a lot from basic apps of any stripe these days, and as those requirements increase, so does the amount of complexity that developers need to manage at all stages of the pipeline.
• tschellenbach 7y ago
  It's complicated because the bar in terms of user experience went up (or so they say) and now everyone wants a SPA. Because of this you now have a generation of devs that only knows how to build SPA. I'm actually thinking to move some stuff from Django to Gatsby/React setup just because everyone knows React, and a lot of our new devs don't know Django/Python.
  • eswat 7y ago
    I think we’ve done a great job of convincing each other within our tech bubble than everyone wants a SPA. Not sure the general public cares for our enthusiasm though.
    • projectileboy 7y ago
      This, this, this. Users didn’t ask for magazine websites - which should be serving up, y’know, images and text - to sit and spin on my phone while all the Javascript libraries load. Users didn’t ask for these things; we as a community just decided to foist it on them.
      • TurningCanadian 7y ago
        A lot of the slowest stuff on websites are trackers that are being foist on developers to foist on the users (if the developers even have control over the trackers, like with GTM)
        • buboard 7y ago
          so you say, but i get the same when using ad blockers or visit sites without ads.
    • ayushgp 7y ago
      Everyone(well almost) wants a SPA or at the very least non reloading pages. No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.
• skrowl 7y ago
  I'll tell you why it's so complicated, but first let me update my 8,000 node_modules for my single page Hello World app
  • ng12 7y ago
    This is such a lame meme. A community built an entire distributable developer toolchain from the ground up, in a completely modular fashion, and then get lambasted for it existing on disk. Or maybe non-JS developers are just upset that they had to wait for Docker to be invented to do it themselves.
• maximp 7y ago
  This is a wonderful and helpful article. A similar post that's really helped me is "What's in a Production Web Application?" by Stephen Mann: https://stephenmann.io/post/whats-in-a-production-web-application/ https://stephenmann.io/post/whats-in-a-production-web-applic... The insane number of tools and processes was the motivator behind Hackterms (https://www.hackterms.com https://www.hackterms.com) - the Urban Dictionary for programming terms, and a sort or modern Jargon File. We're now at ~1200 definitions and I reference it regularly.
  • niccl 7y ago
    Very timely. As a backend dev I'd not come across the 'SPA' acronym used in the comments here. I wasn't even going to bother searching for it because swirly water in tubs. Now I know.
• gedy 7y ago
  Because web development usually means a stateful user interface these days, and most people are not very good at that (independent of language).
• marknadal 7y ago
  It is corporate politics. Modern web development is not about making things more efficient or easier to do. It is about proving you have a job title or knowledge that makes you more hire-able, raise-worthy, title-superior than Junior Devs. Web dev is actually easy if you want it to be, avoid the hype and use simple tools that work out of the box.
• Double_a_92 7y ago
  Because building and deployment are not straight forward. 10 years ago you could have some PHP script, some HTML templating... Upload the whole thing via FTP onto some LAMP hoster, and you could show it to people. And the hoster even had an MySQL database preinstalled if you needed it.
• earnubs 7y ago
  I would argue that web development is less complicated than it used to be for the same quality of output. We now have source maps, debuggers, bundlers, more powerful languages, apis and a narrow range of browsers to hit with all that. So now you can be more expressive, target more browsers easily, have greatly simplified script loading and module management, much, much better debugging tools, with less effort. The tools make it easier for you to be a good developer. Good web development was never easy.
• reaperducer 7y ago
  It doesn't have to be complicated, if you get support from above. A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage. It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on. The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns. Not buying into the framework-of-the-day hype just landed me job security for the next two years.
  • bob1029 7y ago
    Damn, you broke into my top-secret consulting role ;) I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
    • popotamonga 7y ago
      I'm making top dollar remaking failed garbage react native apps to real native native. Clients love it
      • buzzerbetrayed 7y ago
        Out of curiosity, how do you support both iOS and Android with this approach?
        • bgdkbtv 7y ago
          With LOTS of money ;)
        • asark 7y ago
          Secretly leave the Android one React Native since it does a decent job of papering over Android's worst rough spots, despite how often React Native breaks and how LOLWTF its ecosystem and release management is?
• tempsy 7y ago
  I'm not sure if it's that complicated. I feel like you can do so much more with less these days. For personal projects, React on Rails (+ Redux) has been a very productive setup. Once you get over the learning hump of how to set up a project it's basically the same thing over and over again.
• mark_and_sweep 7y ago
  I think the default should be: Don't use any JavaScript if you don't have to. And if you have to, use it responsibly. Recommended reading: - "Responsible JavaScript: Part I" by Jeremy Wagner (https://alistapart.com/article/responsible-javascript-part-1/ https://alistapart.com/article/responsible-javascript-part-1...) - "A JavaScript-Free Frontend" by Matt Reyer (https://dev.to/winduptoy/a-javascript-free-frontend-2d3e https://dev.to/winduptoy/a-javascript-free-frontend-2d3e) Disclaimer: I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.
  • efficax 7y ago
    javascript rules, and you can't build truly interactive sites without it (try to build a refine-as-you-type search bar with just html and css). Here's my hot take: JS is good and has made the web better.
    • mark_and_sweep 7y ago
      Here's my hot take: Instead of waiting 20s for your truly interactive site with refine-as-you-type search bar to load, which, when finally loaded, will lag so much on my mobile connection that it is just plain annoying, I will use your competitor's site which loads within 1s and has a plain old <input> field for search. Not every site needs to be truly interactive. Not every site needs JS. Unless you're building a 3G+ or desktop-only web experience, use it responsibly.
      • realmod 7y ago
        And everytime I want to change anything at all or see updated data, I'll have to reload the page. JS has objectively made the web better.
    • progval 7y ago
      > javascript rules, and you can't build truly interactive sites without it But does the website you're building need to be interactive? Usually not, unless it's a webapp. (Maybe for form validation but that's pretty much it.)
• dnprock 7y ago
  Modern web development is so complicated because we fantasize that a nodejs frontend and backend will make everything better. It's like my product is better because it has more integration. I still stick with Ruby on Rails stack. It has a bunch of good practices and patterns built up over the years. On the good side, I set up a static Jekyll site using Github Pages. It comes with SSL from letsencrypt. I got to run my website for free without much setup. I assume I don't have to worry about scaling it either. No server, no nginx, no SSL config. It's amazing!
• neya 7y ago
  Because, Webpages have become complicated. Suddenly, you have all this interactivity going on, which you didn't have a decade ago. We went from a series of simple hyperlinked inter-connected webpages to all these popups shoving onto our face, useless fake computer bots pretending to be tech-support and finally big co. tracking every single click, every pixel of your mouse movement. The web has come a long way to support all these. One of my clients was an airline. He asked if we could track the usage stats of his in-flight entertainment system (just stats, no PII). I thought about it and said yes. Even I was amazed I said because a decade ago it wouldn't be possible. I got it done with service workers (because flight wi-fi isn't a 100% always on connection). It was a boon for me because I made a lot of money on that project and I needed the money. It's also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not. I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.
  • GenerocUsername 7y ago
    I'm a 'framework oriented' web developer, and I also love barebones webpages. As a developer, I can say that it is designers and product owners who push for the needless jazz in many many cases.
  • deleted 7y ago
    [deleted]
  • buboard 7y ago
    > I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content. You mean like HN? You 're not missing it. The old web never left. It's still here to catch all the misguided cloud walkers when they fall.
    • vegiraghav 7y ago
      My thought exactly.The web is now a place to sell. That means you will have variations for all sorts of people.
• ProAm 7y ago
  It's not the tools, it's the 'Full Stack' title. If you want to be a 10x employee, be a full stack architect you need to know all of it. You simply cannot be a monolithic craftsman, who wields only a few tools well. Because if you do that, in 10 years you'll be left in the dust complaining about ageism vs knowing new tooling I'm not advocating this is a good thing, but its the environment we have fostered for ourselves and now we don't like it.
• dandersh 7y ago
  In 2012 you were building sites and even applications with a stagnant language (JavaScript) that lacked any module/bundling support while having to support multiple browsers with differing standards. Routing, state management, dependency resolution, etc. were handled on an ad hoc basis if at all. The current complexity is a result of addressing these issues and doing so at a rapid pace.
  • hootbootscoot 7y ago
    trying to shoehorn a synchronous model onto an asynchronous state machine, are we?
• bitwize 7y ago
  Because a Web developer had $PROBLEMS problems, and he thought, "I know! I'll add an abstraction layer!" Now he, and the world, had $PROBLEMS + 1 problems. Repeat ad nauseam since the mid 90s. Also, an application software vendor had A(m,n) problems and thought "What we need is to make the Web into a universal platform capable of supporting any application." Now they, and the world, had A(m+1, n+1) problems.
• ummonk 7y ago
  It isn’t. With modern frameworks (e.g. React + Typescript + some CSS framework), it is surprisingly straightforward to build the front ends for highly complex applications.
  • faissaloo 7y ago
    Sure but the question is whether most of those complex applications need so much complexity.
  • moksly 7y ago
    This is probably a popular opinion on HN, but I actually agree. I’ve made things with PHP back when PHP was cool, and then when it wasn’t. I’ve build things with ASP classic, I’ve made my own ASP extensions, then moved to webforms then to mvc and now to core. I’ve made things with JSP and still have nightmares about beans. On top of all that I’ve used the JavaScript necessary to make it actual functional. It’s true that you can create a MVVM app feeling with a MVC framework and a little Ajax, but really, I’ve never been more productive than I have with react. I don’t think it’s really that much more complicated, but I do think 99% of the learning resources are outright terrible, and that was certainly a hurdle I had to overcome. Which is hard, because learning new things while you have a full time job is already hard.
  • justinmeiners 7y ago
    What does your react setup look like? Do you use webpack? Just babel? What about grunt/gulp? How often do these things change? If you left your project for 12 months, would it still work?
    • ng12 7y ago
      Yes, no, no, very rarely, absolutely. It's really not that complicated.
    • ummonk 7y ago
      Usually typescript, with webpack to reduce bundle size in production. As with desktop programming, you have a variety of build systems to choose from, and as long as you use something reasonably same it is fine.
• Rothnargoth 7y ago
  In summary, the OP concluded frontend design has gotten easier though abstracting browser compatibility (i.e. compiled javascript frameworks). The software stack is a natural phenomenon that adds to web design's complexity. Ever changing and never complacent, it continues to shape new features that weren't conceivable in the past.
• goatinaboat 7y ago
  Webdevs tend to suffer from an inferiority complex, that they are not considered “real” developers by the rest of the community. So they have responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys, who simply don’t care, until they try to use the dumpster fire that is any modern website, that is. Then it has the opposite of the intended effect! Someone else mentioned SPAs. I 100% guarantee that no user in the world ever wished for their “back” button not to work as they expected. Calling themselves “full stack engineers” is another symptom of this.
  • jjbiotech 7y ago
    Mangling back button functionality isn't inherent of SPAs.
    • nfgu 7y ago
      Funny thing: in the last couple years I've seen way more back buttons broken because of backend idiossincrasias than anything else. It is super common to see "Don't use your back button" messages after placing orders on e-commerce websites. On the other hand, most frontend developers writing SPAs just use react-router or something like that (instead of reinventing the wheel) and it just works.
    • ehutch79 7y ago
      It's not.... Yet there was a post about how specifically to do that on dev.to because their users couldn't tell their modal was a modal, and the solution they came up with was to hijack the back button.
  • renke1 7y ago
    Who is considered a "real" developer these days?
    • goatinaboat 7y ago
      Developers who don’t care if anyone thinks they’re real developers, I guess!
• president 7y ago
  As someone who hasn't done much web development in the last 10 years, it is mind-boggling how much you need to know in order to be a full-stack engineer these days. I tried to start a project a few months ago and just trying to decide on a technology was difficult. Npm, Gulp, Grunt, Webpack, React vs Vue vs Angular...I don't even know what half of these tools even do, why they're needed, not to mention the learning curve to get up to speed.
  • non-entity 7y ago
    I got really jaded along with a few other things and let my skills stagnate for a few years and now I'm looking at jobs and I'm unqualified for all the half decent ones. I'm personally trying to switch out of development, but I kinda wish I had made an effort to at least understand some of the new(ish) stucc
    • president 7y ago
      I feel your pain. This is one of the few industries that doesn't value experience. Unless you're spending all your time learning new technologies, it's really easy to become irrelevant.
  • sadlion 7y ago
    Try a minimal set up with create react app with typescript and react testing library. Go through the react and typescript docs. Try Formik for easier forms next. Axios for HTTP requests. You can then venture into client side routing with React Router and finally may be Redux for complex state management.
  • neop1x 7y ago
    And there are like 20+ popular javascript (or Typescript, CoffeeScript, Dart) frontend frameworks to choose from (Vuejs, React, Angular, ...) several "native" solutions if you also want Mobile apps (NativeScript, ReactNative or even Flutter if HTML is not looking good enough) and there are like 10+ languages to choose for the backend development. And don't forget proper state management (Redux, RxJS, NgRx or Vuex). So if you plan to make a simple admin webpage you can either quickly write 50-line code in PHP or Python or some other lang. Or you can spend months learning TypeScript, webdev tools, js frameworks, Golang (+dependency management), java (+maven, gradle or some other tools from hell) and spend half a year on it. I have spent so much time learnig all that frontend and backend sh*t to find out "yeah it's nice and interactive but next time I should use HTML+CSS+AJAX)". Webapps are for teams of people. Frontend team and backend team. You need like 10 people to make modern SPAs roperly, also with all the proper CSP, headers and caching settings.
• vcanales 7y ago
  These "i hate debugging wandering pixels" and "i don't want to figure out why my css doesn't work" opinions sounds like they come from people who aren't really front end developers; like they come from the kind of dev who would sit and complain about the frontend devs on their company, thinking that they're a lower class of people. I've been working on the server- and client-side of the web for about 10 years now, and I can't recall running into these "wandering pixel" issues they talk about in the past ~4 years. Frontend development is not just about building a cute website for grandma anymore, and that's why it's complicated. We're passing more responsibilities to the browser, and we have to care about performance when doing work there, and that's why it's complicated. Writing performant software for an unknown machine is hard, and that's why it's complicated.
  • sedeki 7y ago
    I believe I am one of the devs that complain a lot about frontend devs, generally speaking... Don’t get me wrong — being a skilled developer (in the traditional sense) with significant competence in frontend development is extremely attractive. But this profile is actually quite uncommon imo. I have to ask, do you really think the problem with frontend development is about performance? That FE is hard because of the code is executed on unknown machines? This does not resonate with my experience.
    • vcanales 7y ago
      Neither are the 'problem' with frontend development, but the reason why it has become a harder thing to do; that, IMO, is not necessarily a problem or a bad thing. FED is now about solving harder, 'more real' problems, and performance is one of those problems. Writing performant code for -potentially- old machines, mobile devices of various kinds and in the end different browsers, requires a different level of expertise. This is why I'm a bit triggered by the 'wandering pixels' and 'cant do css' comments, and I do apologize for getting a bit intense.
    • deleted 7y ago
      [deleted]
  • alkonaut 7y ago
• jonplackett 7y ago
  Why has no-one made a tool that worked like Flash. I get that the flash plugin sucked and was a battery hog. But the development environment was quite decent. I'd love to be able to make HTML5 content in the same kind of way.
  • cannedslime 7y ago
    The problem with that, is that flash even as an IDE was not really suited our new responsive web. Its not really good for content or development of anything other than games, animations and ads.
    • Jach 7y ago
      Did you ever develop with Flex? MXML and CSS + ActionScript was a great way to design webapps, and if phones actually ran flash, apps and components could be just as responsive as anything modern. The closest JS ever got to it was Angular 1, but then the Angular folks changed course and whatever version it's at now is very different. My current favorite is the ClojureScript ecosystem, but it's even more different than either still, and really only suited for apps. For a plain old website composed of several pages, mostly static content, it's hard to beat plain old HTML with maybe a light sprinkle of JS for a couple things.
      • cannedslime 7y ago
        Actually I must admit that I never really gave flex a chance. Don't get me wrong, I miss the flash days as well, its actually kind of sad that open source player / recompiler projects never really got anywhere.
• jjcm 7y ago
  Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly. Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that. What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies. While it will never be as easy as it was back in the mosaic days, web dev is simplifying.
  • tyingq 7y ago
    "What's more impressive is that things are getting less complicated." Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.
    • TurningCanadian 7y ago
      The statefulness of jQuery is a massive cognitive load.
      • tyingq 7y ago
        Perhaps for an SPA, though lots of what I see React used for doesn't need to be, or isn't, an SPA.
      • The_rationalist 7y ago
• hacker_9 7y ago
  Modern Javascript is complicated*. Elm Lang on the other hand is great for web dev.
• te_chris 7y ago
  I recommend looking at Phoenix LiveView. It’s still early, but it’s a revelation in terms of eliminating pointless, complex JS.
  • itronitron 7y ago
    I like this, and it looks like a good fit for a lot of dashboard / data vis applications.
• rb808 7y ago
  Damn I miss Visual Basic.
• arendtio 7y ago
  I think the structure of that post is a fitting portrayal of the structure of modern frontend development... And no, I am not one of those JavaScript naysayers. In fact, I started building my first Progressive Web App three years ago. But what I feel quite frustrated about, is the pace at which tools become obsolete. It seems that you can be happy if you have two projects which actually use the same set of tools. And every time you want to fix a bug in some project which you didn't touch for a few months, you run into some kind of trouble while updating the dependencies. Just today, I spent an hour getting a project to build again, which I built two years ago. I just hope that in the near future the community will settle on a common set of tools which will become stable and stay for a decade or so.
• wintorez 7y ago
  Good, let's keep it that way!
• B4TMAN 7y ago
  I have been trying to learn web dev on my own for a while and I just can't make it past CSS. I don't get it. How do I even organise it? I get JS as I have done significant C/C++?java/Python. But it still seems a little too evovled on its own. I always end up creating the backend APIs and never the UI.
• loblollyboy 7y ago
  django, heroku, bootstrap and javascript libraries (but not frameworks) easy
• ht85 7y ago
  Does all the hate have to do with sexiness? To many people, backend and infrastructure work is sexy. They would happily get their hands dirty and spend insane amounts of time debugging mind-boggling issues as long as they happen server-side. Frontend work on the other hand is not, it seems. Maybe that's because the biggest problem of high quality frontend development is to figure out how to deal with users (who most deveopers seem to abhor), and how to navigate the, say... complicated circumstances that are browsers. Maybe building something that has to work in an environment you can't control is just a little too stressful for most devs? Personally I really don't care. I love doing great architectural work, but in the end I'm all about expertise and I don't discriminate. If I have to step-debug inside webpack plugins or understand Safari CORS handling quirks, so be it. I'm a software engineer, but to me sexiness is in relentlessly looking for an edge, happy customers and signed contracts.
• commandlinefan 7y ago
  > Why is modern web development so complicated? All the tools that are meant to simplify it.
• skc 7y ago
  It's becoming so complicated that I'm struggling to come up with ideas for how to get my 13 year old nephew interested in web development. When he was born I used to dream of having him look at a button on a web page and him asking me "what actually happens when I click that button" I shudder to think where I would even begin to answer that today.
  • wasdfff 7y ago
    The fundamentals haven't changed. You can teach basic html in an afternoon, eventually making a static site or something in a few weeks. Thats how every web dev today learned to web dev.
  • porsager 7y ago
    Exactly this was one of the reasons why I built https://flems.io https://flems.io. Flems is basically just a scratchpad that begins with 3 files — .html, .css and .js. All the current state is stored in the URL, so sharing is simply done by sending the URL to someone else - true serverless ;) Here's a simple sample you can start out on with your nephew. https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMYaA2qAHYCGuEamO+RIsA9nYn6wA8AIwCu8eLwAEZJAF4AOiHhYIAIXGS6SgHwK6UqQGEoZWAGspzfYID0Yibx2dIMBGV5V0AJlQBOEABfQnomFnQMACsqYh4+CAF0FXVNXgxeWFMLKTkpAAoAShydKWB9Q2SNRzoMMHgATxgMeAAnBjowEm4W3BypAHIwWAYYPP6pAGopAFkGFQxcBgAPPIBGQnzZ+ba6JG5cQqkAKilVgAYCoqn+gv79QM4eXAAHCggW1mEGYWgXaDh4B4OqxVqgAOwAFiCIRAjGYrAwsDAMS4vH48E+3CQ9VK5SkSDIYGeUAY9VQUhIMCWAG48SMyABzOgAWjIiFwYHJsASiBatIMUkiojqZBI9WZcXRXJ5735hlUjJw5POZwAblh7vp9ABiSqpAxlAVfCwMlrcUS7clYbjwV50cxyqQ8KDdckAdywbIgjuE3SQ73JdF43vufzcgM8INBqyCAF1AkA https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY... nb. You don't need to jump in with any of the frameworks used by companies targeting millions of users. The basics are still there...
• dwheeler 7y ago
  Client-side JavaScript is sometimes a good idea, but it's absurd to think that all sites require it, and I think it's grossly overused. Most sites are mostly-static content. If your site is static, HTML and CSS are all you should be using. If it's mostly static, server-side implementations or minor JavaScript sprinklings on HTML and CSS are often simpler, cheaper, and much more maintainable. Server-side implementations tend to be much easier to use, and work just as well when your users disable JavaScript because they want more security and privacy. Accessibility is possible with client-side JavaScript, but it's far cheaper & easier without it. Some sites can't be implemented server-side (or are sensible to do completely disconnected), and then you really do need the interactivity of full-on client-side JavaScript. In my experience, requiring full-on client-side JavaScript tends to be more complex and time-consuming to implement, and often tends to have serious loading time lag (with careful design it can be addressed, but often it never seems to get addressed). Everything is a trade-off. The usual cause of excessive complexity is engineering based on the latest fad, instead of what is actually the best choice.
• smashthepants 7y ago
  Where's your newsletter signup so I can be notified when part 2 is released?
• chrshawkes 7y ago
  Simply put, the web and all it's related technologies move at a much more rapid pace than Java, C++, .NET etc. We can complain about it all we want but if you drop out of this for a few years, good luck. I know tons of senior dev's who have no idea what modern tools to use. They don't understand modules, loaders, config files. Trust me on this, the front-end guys like myself, hate the backend guys that come along and criticize everything they know nothing about. They also get in the way as they bumble and stumble over concepts UI guys already know. There is a huge distinction these days with backend and frontend web development. Each should avoid criticizing the other.
  • meesterdude 7y ago
    us backend guys come from a time when buttons worked when you clicked on them. It's a concept we are adamant to share with you new front-end folks :)
• Yaa101 7y ago
  Simple answer: Because the stupid hipsters try to change a simple concept of a state machine into MVC hell. More complicated answer: The weak side of the open source world is that it attracts a lot of developers with big egos who think that their fancy solution to a situation without problems is the best one. And they all compete with their too big egos and complicate our open source world. Real answer: too much memory, this causes people to come up with too complex systems as there is hardly a limit to their dreams, real inspiration comes from dealing with limits. That is why programs from yesteryear are often so good when looking at what they do within their constraints.
• fiss 7y ago
  This sentence explains the issue in modern web development: "Browsers are only capable of executing JavaScript, so when there are limitations in the JavaScript language, it’s not like you can just use a different language; you have to work with what you have." Yes, you can use a different language. You can use a back-end language and let the server do what it does best. PHP, Ruby .Net, Python (and more) are still very much alive and relevant. I understand what the writer meant to say with the sentence, and the specific limitations to JS. But the real issues are in a notion that JavaScript is the one language to rule them all. That is very misguided view (IMHO) that took over the web.
• chiefalchemist 7y ago
  I'm not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs/engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I'm using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed. Nah. Nobody cares. I think that bears repeating...Nobody cares. My mum has __never__ said to me "I love React" or "Isn't Bootstrap the best." But she __has__ complained to me about a site/app being buggy, confusing, difficult, etc. I've said the same to myself too many times to count. I think we all have. A couple months ago, I read an article about (frontend) tools and how important X, Y and/or Z are. The author's product had a repo on GH. There were 700+ issues. All I could think was, "Apparently those tools have given his team a false sense of security. Looks like they've bitten over more than they can chew." I filed the article under: Just because you can, doesn't mean you should. Years ago, I remember reading an answer on Quora (when Quora still mattered) that included: "A fool with a tool is still a fool." I don't think I'll even forget that line. It's so true. I'm not against tools. I'm just not in favor of those who claim tool X, Y or Z is a panacea.
  • wasdfff 7y ago
    You see that everywhere. In my field unless a dedicated statistican was a coauthor, chances are they picked the wrong test to use for significance. And if you look through their past papers you might find that they only use that one test that they always run, despite whether or not its relevant for their data. In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.
    • chiefalchemist 7y ago
      It's like anything else... A solid idea well executed will beat a great idea poorly executed. Sure, we all love to learn new things and/or push the envelope. That's what side projects are for. But when such things come at the expense of "the product" with a real user base than something as gone wrong. "I love dealing with fast-moving things that are broken," said no user ever.
• AlexDragusin 7y ago
  Among various reasons: - Most people overcomplicate things, in general, not just in web dev. - Not using the right tool for the job (I often run into sites displaying static content where they are using a bunch of frameworks and unnecessary code)
• aphextron 7y ago
  Web development is complicated because it is no longer web development. It's application development. And nontrivial applications are, by definition, complicated.
  • hombre_fatal 7y ago
    People forget that "front-end development" is just "client development" which isn't simple nor trivial on any platform.
• chovy 7y ago
  Because people with degrees brought their backend complication to the frontend when they realized they could only get money as a web developer. Now we're all fucked.
• janpot 7y ago
  well, programming is hard. It has always been hard. regardless of the field. classic web development is complicated as well.
  • hootbootscoot 7y ago
    except that front end web dev is hard for political, rather than comp-sci, reasons... hey what's your timezone? no, i don't mean getTimezoneOffset(); https://www.iana.org/time-zones https://www.iana.org/time-zones LOL
  • tamrix 7y ago
    Programming isn't hard or easy. Problems are hard or easy.
• rossdavidh 7y ago
  The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing. There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascript on top of a few dozen included libraries. There was nothing preventing that. Therefore, it happened. Developers don't really feel like pointing out, "you should get rid of me and just pay for someone to do html". Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me." The designers don't feel like pointing out "all we really need is to put this well-formatted text on a page with the company logo on the top and one or two image files, and that will communicate the information just fine, you can get rid of me." The even-higher-ups don't really feel like pointing out "I don't need to hire all these people, you can take this VC money and return it to the original investors". The VC's don't feel like pointing out, "there's not really a use for this much money in the tech world right now, so you can just stick it in a bank account and wait for a real need." So, it doesn't happen, because there was nothing to prevent it.
  • silexia 7y ago
    I love your comment, but I think it does miss out on some important concepts. I used to think when I first started my company that I could just do every part of it far better than anyone else. I would push on my employees pretty hard and often denigrate their efforts. As the company is continued to grow, I now have 180 full-time employees. The reason I have all these people is that they can do enormously more work than I can and most of them are now better at doing their individual job than I am. I think your comment visits are tendency as tech people to view ourselves in the best possible light, and to view other people as not as good. We especially tend to view projects we do as big and very complex and project done by others as not impressive.
    • asdf21 7y ago
      The question is, are you auditing the final work being done by your "teams" and asking whether it could have been done more efficiently / simply?
• tomc1985 7y ago
  Because "innovation"
• m0zg 7y ago
  Because people have no time or incentive to make it simple. In fact, the incentive is to make it as complex as possible so you could charge more (and then charge more still for maintenance), and create a moat that "lesser" developers won't be able to cross.
• foobar_ 7y ago
  Because dumbass java programmers are migrating to js and are bringing their shit to the web.
• mholt 7y ago
  I wrote about this very topic earlier this year: "It's 2019 and I Still Make Websites with my Bare Hands" [1]. There is a lot to be said for simple, time-proven technology. [1]: https://medium.com/@mattholt/its-2019-and-i-still-make-websites-with-my-bare-hands-73d4eec6b7 https://medium.com/@mattholt/its-2019-and-i-still-make-websi...
• shados 7y ago
  Webdev isn't complicated. Its actually pretty simple. Because its simple, you can use the extra time you saved to solve complicated problems. Which then brings it back up. When the platform makes THOSE problems simple, you just move on to solve other more complicated problems. Basically, developers can support complexity <x>. No matter what you do to simplify it, you'll always push toward <x>, just getting more value out in the process. If you don't, your competitors will. Also, even the most complex rollup/webpack/react/redux/styled-component/npm/blah/blah/blah setup has nothing on the kubernetes/kafka/databases/queues/whatever infrastructures of the world. It just turns out that while your little pet project that cuts every corners to get something working has little on software development that requires everything to line up, be fast, reliable, comply with all the laws and regulations, and scale once your company grows and you suddenly have hundreds or thousands of people that need to work on the same stuff. One thing to add: some people actually like setting stuff and optimizing infrastructure, build processes, setup, and pushing it to its limits. So development stacks quickly get optimized for a very common way to staff organizations: have a team that handles all the setup and infra, and a bunch of teams that build on top. So when you try to have 1 person or 1 team do everything, it feels like too much.
• Ididntdothis 7y ago
  I always think it would be a huge success if somebody could deliver the same ease of development that VB and Access had for the desktop. There are some I have seen but they all are not as simple as VB and Access were.
• jonnycoder 7y ago
  Anyone take the reasonable approach lately? IMO, it involves taking the CDN version of a framework such as VueJS and slapping that bad boy as a script tag in your HTML file. No webpack, babel, sass, etc etc. I'm developing a dashboard, nothing fancy but nothing simple. I am also reasonable and think one can build off of all the well established UI components out there such as Vuetify. I now have a lot of free time to spend on the backend API, which is what I happen to enjoy doing. As a fan of end to end or integration testing, I could care less about test driven development on the front-end.
  • non-entity 7y ago
    I tried it recently, my only other experience with SPA's was n Angular 1.x Cordova app. It was very easy to get set up, but I unfortunately scrapped it for unrelated reasons
  • robertoandred 7y ago
    That’s only “reasonable” if you have a simple, cookie-cutter site.
    • jonnycoder 7y ago
      Can you go into more detail? With Vuetify, I add my colors and generate a new theme. Hardly any new css is needed, especially with the grid systems that come with it. The compiled Vuejs gives proper errors in chrome developer tools, so it's been easy thus far.
• quickthrower2 7y ago
  The main reasons web development is complicated: * Javascript has evolved from simple requirements e.g. flashy text to a full blown application environment, but there is relatively little base functionality included (e.g. compared to what you get in Java or C#) so people need to write those libs separately. * The separate libraries above need to be included in your code, and copy/paste is not maintainable so some kind of module system is needed but JS doesn't come with one, so various people rolled their own and they competed for mindshare. 10 different standards. * As above for UI frameworks. JS only has a basic framework included: the DOM. It's pretty good but doesn't scale "naked" to more complex apps, so again the community creates a whole bunch of those. * As above for application frameworks (UX frameworks)? such as routers so that you can press the back button. * Ah the back button - an example of where apps on the web have to care about something that desktop apps don't. There are other examples. Mixing http/https. Mobile responsive. * CSS - I imagine originally designed for "documents" - now has to work well with "web apps". * Javascript again - no static typing, many devs find it too easy to make mistakes, we have Typescript and other compile to JS languages. * Because of the above complexity with have Babel, Browserify, Webpack etc. (one is never enough!) * Then some genius decides to use JS for the back end and we have Node, NPM, and then because Node is so useful it becomes the front-end tool chain provider. So you use NPM to install Webpack, and the newbie has to figure out difference between dev dependencies and ordinary ones etc. * git clone https://github.com/.. https://github.com/... and who knows what stack they've used. Oh they are using Browserify. Never used that. 2 hours reading the docs. * Each framework then finds ways to get more complex organically. React, Redux etc. and all that. * Again every other programmer is using 10^10 different combinations of frameworks and techs. Compare to C# Desktop development where it might be they are using Winforms or WPF - that's your only problem! I could go on. I still copy and paste my favorite templates for getting started with NPM/Webpack/Typescript. Not sure I could demo how to get there from scratch again. All the recommended ones online seem to have beartraps in them and stuff I don't understand. But remember you all you need is a <script></script>! It's easy!
• sylens 7y ago
  For somebody who just wants to pick up a useful programming language/set of languages these days - should I engage with modern web development or avoid it entirely?
• butterisgood 7y ago
  <marquee> is all you need </marquee>
  • buboard 7y ago
    i think we need more native browser UIs like marquee. Look at AMP, it understands that but is impleemnted in JS.
• segmondy 7y ago
  It's only as complicated as you wish to make it out to be. Make it simple by saying no to as much cruft as possible.
• MadWombat 7y ago
  So... let me get this straight. You are making a website. You do need to load some changing data into it, so just a static site will not cut it. But we want to keep things simple. All we really need are a few AJAX calls and some DOM updates. And just like the author mentioned we don't want to write old clunky JS, we want to write beautiful ES6 code. So we install babel for ES6. And we install jQuery to do our AJAX and DOM stuff. Turns out that if we want to make AJAX calls to our API server, we cannot just load the file in the browser, it expects a server. We look briefly at installing nginx or apache and it seems like a lot of trouble. But we do discover webpack dev server. That's perfect. So we install webpack and configure the dev server. Since we are doing it, we might as well make it run babel for us. And while at it, we might as well do the bundling. Especially, since we would like to use a couple of other NPM modules. Nothing major, just convenience things. And since we are using the dev server anyway, we add hot-reload support. And a minifier, so we can have a minified production build. So now we are using HTML, CSS, jQuery, babel, webpack, webpack dev server, webpack hot reload plugin, webpack plugins to load resources and a minifier. But hey, keep it simple, right?
  • root_axis 7y ago
    So using your summary at which step did the engineer make the wrong choice?
    • ModernMech 7y ago
      That's the point. At no time did the engineer building the application make a poor choice. He/she made the logical rational choice to get the job done. It's the same thing for the tools developers. They each made their respective tools to solve a real concrete problem and succeeded. The problem is that everyone seems to be making incremental improvements and engineering choices that locally make sense, but when you zoom out and look at the whole picture things look absurd. We're incrementally improving ourselves to a local maximum that seems to be an uncomfortable place to be. There may be a better path that will lead to a better maximum, but we can't see it from where we are.
    • MadWombat 7y ago
      None. That's the point. Web development is not simple. You don't have to always use the very latest super framework, but even the minimal setup for developing a modern website has quite a few moving pieces. If you remove any component from the list above, your development experience will become harder.
• madrox 7y ago
  I've refocused on web development in a new job after six years of being mobile dev first. To me, the answer is that design and user expectation got more complicated. Look at what was considered a state of the art web page 10 years ago, and you'll find the UX wasn't nearly as nuanced as today. Combine that with polyfills and responsive design requirements and it's just as complicated as a native app, and look how big those things are.
• daotoad 7y ago
  Web development sucks precisely because we use a document markup language, a document styling language, and an interaction scripting language to build applications. It was bad enough when we just used this mess to make user interfaces. If you've ever written or worked on a classical desktop application, you'll know what I mean. Since (at least) the 90s there have been visual UI builders and geometry management tools that allowed you to easily define a responsive user interface and connect widget events with calls to back end code. With the advent of CSS Grid and Flexbox, we finally have two decent geometry management tools--it only took 20 years. Except I can't use them yet, I have to support terrible old browsers (like IE7) that are embedded in customer applications. We've been involved in reinventing a pretty, zero-config version of X-Windows, and we're only about 60% of the way done. How much further would we be if we didn't insist on building it in a hopped up word-processor?
  • mattl 7y ago
    Please don’t call a NeXT a “hopped up word processor”
  • tmm84 7y ago
    I've been feeling this way for years. Web browsers were meant to show mostly static pages, not pages trying to dance around as full blown programs.
• _hardwaregeek 7y ago
  I think there should be a new razor, we can call it the Apple razor because Apple is the most common case. Basically, when tempted to ascribe the decisions of a successful entity to stupidity, consider that you may not be considering all the facts and facets. Yes, web development is complicated. Yes, that complexity is at times completely unwarranted. But, that does not mean that the originators of this complexity were simply being stupid. A company like Facebook has a simple requirement: keep users on the site. If that means building a completely overengineered platform or inventing a totally new front end framework, sure, go for it! As long as it keeps the experience so smooth, so seductive that people scroll for hours, absorbing ads and producing money for Facebook. I wouldn't be surprised if someone did some user testing and the SPA with no jarring refreshes and fluid page changes scored significantly higher on user engagement. If you look at the companies that have really fancy JS libraries, they're generally places that rely on people using their apps continuously. Netflix? They're practically the poster child for internet addiction. Twitter? Yep. Even old school media companies like the New York Times are starting to use fancy web technologies. Clicks and eyeball time is money. Stuff like React and transpiling and webpack are small prices to pay if they keep your front end developers happy and your website nice and shiny for your average user.
  • buboard 7y ago
    Does facebook use react in its main, user-facing site? Does twitter ?
    • _hardwaregeek 7y ago
      Yeah, totally. You can open React Devtools on Facebook and inspect it yourself. Twitter uses React for mobile and judging by their HTML, they might be server side rendering React for their desktop site too, since there's the hallmarks of React (react-root) and CSS in JS.
• randomsearch 7y ago
  Speculative answer: “because it’s a technical solution to a social problem, and therefore can only mask the symptoms and not address the underlying cause of the problem.”
• oeijfgoierjg 7y ago
  I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes. People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master. We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it. As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it. Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
  • hootbootscoot 7y ago
    ... except that broken or ignored browser standards, and Javascript's lack of dealing with Timezone, for example, are not the result of complexity, per se, but of social inability: a committee or industrial consortium being unable to come to an agreement... kicking the can down the road in some cases, building-in complexity for ulterior motives in some cases by some parties, etc... the web is a mess on the front end for political, rather than computer science, reasons (say, you don't want to include the 2mb outdated moment.js? well, even though every browser included this code to fetch and update it's IANA timezone database in it's source, and has compiled against it, you can't access it via a public API from JS though LOL... you can figure out a way to run this code to get your data muahahahahahah.... https://www.iana.org/time-zones https://www.iana.org/time-zones)
• bmniotjoti 7y ago
  I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes. People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master. We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it. As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it. Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
• crimsonalucard 7y ago
  It's complicated because nobody knows how to fix it. There's no formal definition for a "good design" or a "better design", so people keep iterating over the designs not knowing whether the new design is actually better or worse. If there was a way to quantify a good design vs a bad design through an algorithm then people can iterate in ways that properly and categorically makes things better rather than in ways that are opinionated, vague and possibly even in the wrong direction.
• iamleppert 7y ago
  This could be rephrased, "Why is kernel development so complicated?" or "Why is FPGA development so hard?" In any given technical environment that has sufficient time to mature there will be more information to process, more choices, and more surface area. It's just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is. If you want something simple, why not invent it? There's nothing stopping the next person from coming along and coming up with something that gets the same job done a lot easier than what we have now. Of course, the first time you try to implement a tiny portion of a browser primitive like drawing a table you'll quickly see why things are complex.
  • deleted 7y ago
    [deleted]
• buboard 7y ago
  I wonder what drove this needless and pretentious complexity ? The javascript ecosystem feels fragile and hacky, which spell bad prospects for its long term survival. It's more likely that jquery and PHP will survive after 2025 than any of the javascript tools mentioned in the article. Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? The social credits that people added to their CV for making yet another uber-popular javascript thingy that got a lot of github stars? Or was it bored engineers in the major web companies who have nothing to do because their advertising money cow is already being milked, so they decided to build toys to sabotage everyone else?
  • ScottFree 7y ago
    > I wonder what drove this needless and pretentious complexity ? > Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? IMHO? Pretty much. That end result is linked to the desire to democratize programming. That was a common talking point back in the 90s-00's. They wanted normal, non-programming people to be able to make websites by themselves without programmers. They wanted to be more inclusive and make programming more accessible to the masses. They thought one day programming would be taught in schools right next to english and they'd use that skill every day to program their computers themselves. The common phrase used was "programming is the new literacy." They did not succeed. To make the programming tools and languages easier to use, they had to add complicated abstractions. Objects. Exceptions. Garbage Collection. Types had to go. As a result, programming got a lot easier to make simple things, but a whole hell of a lot more complicated to engineer solid, reliable systems. A lot of the comments in this very comments section show a great deal of fear at not using a framework to program even a simple website. That's a great example of the kind of mindset we've cultivated over the past 30 years. We're so worried about how to utilize an ever growing pool of barely computer literate junior developers that we've Harrison Bergeron'd our best and brightest.
• mirimir 7y ago
  > Why is modern web development so complicated? Although lots of cool stuff is possible, I suspect that very often, it's about profiling and tracking users, and not about delivering content. That's certainly my experience as a user. I routinely browse sites that call resources from numerous sites, and want to run multiple scripts. And all they're ostensibly doing is displaying some text and images.
  • bpicolo 7y ago
    Ironically, many actions are drastically easier to track on the server side. Frontend pageview tracking is trivially knocked out by ad block. Backend pageview tracking is impossible to block.
    • mirimir 7y ago
      True. But lots of third-party tracking is harder, right?
      • bpicolo 7y ago
        Wouldn't say that. With something like Segment it's easy to shovel data from the backend to any analytics provider you can think of. The majority of analytics providers have a REST api of some sort.
        • mirimir 7y ago
          Sorry, I wasn't clear. I meant that, without 3rd-party cookies, tracking is harder. And I'm assuming that users who block scripts also block 3rd-party cookies.
• exabrial 7y ago
  Conversely, why are modern web apps so terrible? Take the Google GSuite Admin Console. This is what I called "Turn based administration" [throwback to the old turn based strategy games]. You start by loading the page and the 15mb of random javascript. Now click on something! Wait. ::Javascript stuff:: Incoherent error. Click Help. New documentation webapp loads 15mb of javascript to display some static text.
  • buboard 7y ago
    Hello, i am the popup from the button you clicked 57 clicks ago. i just arrived asynchonously and i m going to destroy your entire form. but don't worry, i will do a slide-hover-twist-and-twerk animation when entering
• wildduck 7y ago
  The modern web development also turned into app development to emulate functions that is on the desktop applications. That is what is bring ing the complicity to the web. Rise of the SPA is great. However, I think unless there is a good reason for having a SPA such as hybrid mobile app development, then there is no point of using SPA. Normal server side web page rendering with latest modern version of jQueryish/Zapeto should be just fine for the non app type of web development.
• apatheticonion 7y ago
  I actually wrote a thingo on this recently. Modern front end has essentially the exact same challenges as a server which provides its API with sockets/websockets/events. A back end server with this configuration would have a handler layer for IO, business logic layer and data layer. DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that. Front end is exactly like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes. The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions. ``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ``` So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing. Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library. Vue just missed the point entirely. React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind. In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer. I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes. https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.tsx https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.t... Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever. Front end is a mess.
• Razengan 7y ago
  As other comments here have said, in different ways: "Modern web development" tries to reinvent too many wheels. I wish more developers/directors would try to approach this from the other direction: Making native OS apps as easily discoverable, installable, accessible, navigable, sharable, restorable, updatable and uninstallable, as websites: • I want to be able to type "photo editor" and see Pixelmator on macOS, Paint.NET on Windows, Photoshop on both, and GIMP on Linux. • When I choose an app it should open as fast as a website, loading incrementally, but remain available even after I'm offline (except for internet-dependent features) like other native apps. • It should always launch the latest version, but should also allow me to "freeze" and locally archive a specific version. • It should adopt the look, feel, and all the special features of the OS and device I'm currently using. • I should be able to capture the UI state as a "link" and share it with other people, for example a specific page in the preferences window, or a particular workspace layout. • It should remember my preferences across machines and OSes. • After I have stopped using it for a while it should not take up any local storage on my machine. We already have high-performant, energy-efficient UI toolkits and graphics and audio engines, we already have task switchers and various accessibility features, and we already have everything else that every web app is constantly trying to reinvent, each in its own half-baked way. It's a constant shuffle of N steps forward, N+m steps back. "Oh look! A cool new technology for native apps! But wait, let's take a very roundabout detour to reimplement this in a crippled imitation so that browsers can host it too."
  • buboard 7y ago
    Sounds like it would be easier to enrich the browser with native-look controls than create another cross-platform ecosystem. (Let alone that none of the platform owners want to share developoers with the other platforms / they have incentive to lock them in)
    • BlueTemplar 7y ago
      Stop using these platforms.
• fishingisfun 7y ago
  i was just thinking about this yesterday. The khan academy website became so complex in its layout. I think the old school web will make a comeback. Things are too complicated these days
• ggregoire 7y ago
  If you think learning react and setting up a webpack build is complicated, I recommend you to stay away from modern backend development.
• gigatexal 7y ago
  I have been saying the same thing for years: webpack, Babel, react, the million or so CSS edge cases per browser, and then that’s just to get started. I found backend development much saner to reason about.
• cutler 7y ago
  In the early 2000s Jakob Nielson popularised website usability through his books and his deceptively simple website useit.com. Big companies were paying him big bucks to have him simplify their websites much to the annoyance of the Java astronauts peddling n-tier jumbo sites. I often wonder what Nielson make of the insidious trend of using React & Angular for minimally dynamic websites.
• chopdcheez212 7y ago
  It’s not complicated, you kids are just spoiled. JavaScript I was paid to write in 1995 had a shelf life of 6 months given Netscape’s release schedule and I had to compete on performance with Delphi 3 native compiled code. If you think web development is too complicated these days, you should just dump it all and write cgi scripts in Perl again. Or if you’re an academic, Smalltalk + Seaside. If there is a problem with modern web development, it is the curse of too much choice. Focus on your end goal, and the choices available will become a blessing, not a curse.
• kareninoverseas 7y ago
  Awesome! I had quite the experience setting up a react app workflow with a friend. If you don't get your versions of tools to all line up or you use a tool which is slightly unconventional, or sometimes if you're developing on not-Mac, things can go very wrong very quickly. Nice to have a post overviewing how to pick and choose (and why you shouldn't do that anyways).
• austincheney 7y ago
  Its complicated because people make it complicated. Instead of following trend bullshit and self-justifying tooling insanity start with the a solid foundation and build on it one tiny layer at a time. This is a learning process. It isn't something a tool can magically do for you. If you think you can nail this in two hours or by dicking around with some tool you are lying to yourself. Don't worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren't some software rockstar and learn to take the primitive dumb stuff very seriously. If you are hoping a tool will magically do it for you then you will continue to suck. The web will continue to be a complicated mystery. You will probably continue to cry about how hard life is and people won't want to be around you. At the most primitive the web is HTTP and HTML. Don't over think this. If you understand those you have the web. You don't even need URI. URI is an added convenience. Next, build less shitty HTML. Any HTML no matter how ugly, inaccessible, presentation-oriented, user-agent centered, and otherwise broken is still a good start so long as it displays content to a web browser. The first goal of HTML is something that just works... somewhat. Improve on this. Learn to write better HTML and better content. Most people don't take HTML seriously, but this is really the most important part of building a good web experience. Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn't hard, and you can do really almost anything with CSS. Even still people FEAR the CSS. Fourth, be a damn programmer and stop being afraid to read code. Learn to write JavaScript. Learn the concept of scope. Learn to really read code. A bunch of tooling and test automation isn't going to read the code for you, though many developers seem to think that is exactly what layers of unnecessary tools are for. Keep this very simple at first. Learn some basic events and then bail out. Don't immediately think you are some kind of architectural wizard, because you will fail. If you think a framework will solve this for you then continue to be mystified and confused. Fifth, learn the DOM. The DOM is the heartbeat, or assembly language, of the client-side application experience of the web. The DOM is what binds HTML to the browser and CSS/JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn't be using. Frameworks won't teach you this. The best way to learn the DOM, how it really works, is to learn XML Schema. I strongly suggest this even if you never use XML or schemas ever again. Build on that. Baby steps. It takes some effort but it isn't complicated.
• innocentoldguy 7y ago
  Why is modern web development so complicated? Because of fucking JavaScript and shitty front-end frameworks. The end.
• proc0 7y ago
  The bar just keeps moving higher. Right now making a website that looked good a decade a go is very easy, but the cutting edge is about responsive, highly interactive applications. Additionally they are constructed by teams of people, increasing the level of complexity because of the need to share code while staying dependency-free. Client applications have become increasingly complex for anything that isn't a trivial website that mostly displays information. Complexity management on the client side I think is its own paradigm that is often not given enough credit and then people get surprised why their UI grows increasingly fragile while taking days to implement seemingly simple features. Ironically some of the tools in the article will probably grow old which is part of the difficulty here. People learn the libraries, then it seems a new, better library comes along and makes things even better. Everything comes together once you learn it's about managing the algorithms, data, as well as rendering to the screen.
• xhruso00 7y ago
  It took me some time that the author is female named Victoria Kirst with 6 years at Google and 1 year teaching at Stanford CS193X http://web.stanford.edu/class/cs193x/ http://web.stanford.edu/class/cs193x/
• winrid 7y ago
  (shameless plug) Just for kicks I wrote the client side of https://watch.ly/ https://watch.ly/ without any frameworks (but used less/ejs/express). Also winricklabs.com It's a nice breather after writing AngularJS for six years... I'm sure with the next complicated UI I'll use some big framework (Spring+Leaflet or Angular...) However, I think the goal should be to reduce complexity and have your business/product be focused as possible. Watch.ly is literally just live hit counters. The live part gets challenging at some scale. But the product is focused.
• iamsb 7y ago
  Most of the hiring is geared towards what do you know instead of how do you solve problems. I recently went to work a two big company, which is considered highly agile and progressive. I was tasked to build a pricing engine to customize prices for a static inventory of products. Number of products were about 30 and did not change month to month. The architecture suggested we use close to 18 different technologies, including caching systems, message bus, reactive programming. All to give 10 possible prices for 30 products. So essentially 300 values and a system to change the rules which determined the prices based on 3/4 parameters. I built the entire system in 2 days which was ready to be tested, but was told to scrap the work as it did not follow the internal development guidelines. Not to mention I was reprimanded for not including team and calling a complex problem trivial as it increased signaling risk internally. Apparently they are still building that system with 5 engineers, 2 analysts, 1 devops person, and 1 team lead. I left the company 2 years ago. And interestingly each and every person on the team got a promotion, multiple performance bonuses in last 2 years.
• prince005 7y ago
  This is like a neanderthal saying that fire is hard to build so let's eat the food raw. The time is now old man. The new frameworks are surely confusing (not complicated) to learn at first but that is because they expect you to learn a system by which the chances of you delivering a bad product gets mitigated as the lowest level components follow an accepted standard. You are learning a system, a new tool to aid in your work rather than starting from scratch every time. And if you say you don't start from scratch and have a system/set of components to reuse then, voila, you are just doing the same thing frameworks do, but in your own sweet way.
• edem 7y ago
  Because people would use bloated libraries instead of using the built-in stuff like `document` and `window`.
• tempslkjs 7y ago
  I think a lot of programmers forget the purpose of programming is for an end result. Instead, they focus on ever more complexity to feel superior to their peers. "Look what I can do" attitude. This reminds me of the Nasa space pen, when Nasa spent a million to develop a space pen and the Russians just used a pencil.
  • asalahli 7y ago
    According to this[1] and many other articles, the NASA space pen story is just a myth. 1. https://www.scientificamerican.com/article/fact-or-fiction-nasa-spen/ https://www.scientificamerican.com/article/fact-or-fiction-n...
• username90 7y ago
  The more developers who work with an ecosystem the more complicated it gets. Therefore the most developer common job (Web Development) gets the most complicated ecosystem.
• mister_hn 7y ago
  Well..no one has to switch to React/Vue/etc. You can still deliver well-behaved websites using plain HTML5 (CSS3 + jQuery), without all the bloat taken thanks to npm/yarn. You can try to use SaSS or LeSS, to make your CSS files look neat and avoiding to DRY, but all the rest is pure bloat. To all the people saying that you want a native-app look, then go for the native way. The web-apps will _NEVER_ be as fast as the native ones, just because, the native ones will be faster and faster as the hardware specs are going up. I personally hate to go through web-development, even if it's a desktop client: stop wrapping around web views.
• hhas01 7y ago
  Why? Because most programmers are lazy, arrogant, self-serving children. Given the choice between learning the business – requiring lots of talking to users to understand what they do and why they do it, and then writing very plain uninteresting code that servers those business users’ needs – or learning whizzy new CV-enhancing technologies and using them to invent excitingly complicated and interesting software problems so they can spend all their time solving those problem instead, which do you think the indolent bums are going to embrace?
• deleted 7y ago
  [deleted]
• pkalinowski 7y ago
  In my free time I try to create some desktop apps. It's my free time, so I decided not to spend time learning Qt or other older solutions for desktop apps and go with the Electron. I'm too stupid for Electron, though. I wasted many hours trying to debug weird errors which I never know if are caused by Electron itself, bundlers, npm modules not compatible with it or anything else like division between main/renderer process. I just can't grasp it. I ended up with separate node.js server which takes care of communicating with OS and standard web app with the simplest bundle setup I have found (because I don't understand webpack config, too): Parceljs. Frontend and backend exchange information using socket.io with copy-paste examples from their website. I couldn't believe it CAN be so simple! Maybe it's not "true" desktop app (it just opens in user browser), but works exactly like I want.
• drej 7y ago
  I like to read these things, because it feels so foreign to me. I started web dev around 2003 (stopped maybe 2010-2011), it involved a empty HTML file, perhaps only the few basic elements copied in, some hand crafted CSS, hand crafted JavaScript, a few ifs for Internet Explorers of the days, it was pretty manual, but one knew all the bits and pieces of the code. Given how much I spent doing things this way, I'm quite reluctant to building JavaScript, let alone CSS (though preprocessing first came to CSS, if my mind serves me right). I find the write-test-update loop to be much tighter for frontend work, so I'm quite fond of the old ways of doing things (and all my side projects look the same way as they did back in the early 2000s), but I understand that modern build tools are getting more and more performant. Not as performant as "Save" though :-)
• neop1x 7y ago
  It's not that complicated. There are only like 20+ popular javascript (or Typescript, CoffeeScript, Dart, ...) frontend frameworks to choose from (Vuejs, React, Angular, ...) and their popularity changes over time. Several so called "native" solutions if you also want fast Mobile apps and HTML is not looking good enough (NativeScript, ReactNative or even Flutter). And there are like 10+ languages to choose for the backend development. And don't forget proper state management client-side to maintain single source of trust (Redux, RxJS, NgRx or Vuex)! Webapps are for teams of people nowadays. Frontend team and backend team. You need like 10 people to make modern SPAs properly, also with all the proper CSP, headers and caching settings. And you have to transpile the code to javascript after every change and 1.5 GB of JS dependencies and tools with web-based editor like VSCode. But all that is worth it because it's so interactive and modern. :)
• rixed 7y ago
  Although the article is about web development for the actual web, there is also a lot of web development that's not for the public web but just because using the browser used to be a simple alternative to developing a native GUI, especially if you valued portability. For my current project I needed a GUI that I initially planned to implement in the browser, but then I started to question this assumption that web development is simpler, and decided to try to refresh my C++ and use Qt instead. So far it's not a disappointment. I wrote a bit recently about that here, if you are interested and can bear poor English: https://rixed.github.io/ramen/blog/2019-07.html https://rixed.github.io/ramen/blog/2019-07.html
• growlist 7y ago
  To someone attempting to return to web dev after a break of a decade or so, my normal response is incredulity at the absolute horrorshow that's arisen. To me it's a complete towering, teetering mess of differing approaches, needlessly heavyweight frameworks, terrible decisions, and inefficiency. This is probably the ultimate cliched comment but I honestly cannot understand how any self-respecting developer can work with this xxxx and look themselves in the mirror.
  • buboard 7y ago
    I know it sounds unbelievable, but plenty of web developers ignore that whole show. It just doesn't seem the "upgrade" is worth it until something better comes along.
• malyk 7y ago
  Because software engineers want “growth”, and for most of them growth means learning/creating new technical things, and learning/creating technical things means more complexity. There are other reasons, but that is a huge one.
• brillout 7y ago
  The problem is the enormous amount of choice we have: - React or Vue? - Redux or stateful components? - GraphQL or REST or RPC? - SSR or SPA? - ... We are missing a framework with sensible defaults for all these questions. And that does a good job at explaining what decisions one should take. I'm trying to build such framework: Reframe (https://github.com/reframejs/reframe https://github.com/reframejs/reframe).
• deleted 7y ago
  [deleted]
• mbrodersen 7y ago
  It isn't. Unless you make it complicated. Developers spend time making things complicated. And then more time complaining that things are complicated. Followed by even more time "solving" what is complicated by making it complicated in different ways. Repeat. Yawn.