9 ms·

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development. The amount of complexity you have to wade through to get anything done is just silly. There's the idea floating around that web developers are less competent than programmers on other platforms. I'm only half serious when I say this, but I sometimes wonder if, to the extent that this is true, it's because web developers have so much incidental complexity to deal with that there's just not much brainspace left over for classical CS or software development concepts.

bitexploder 9y ago
That's cause the web is full of hype. Try Python Flask. A three line Python function and you are going. No magic. Just request and response. It is easy. Bang out a model class and read the SQLAlchemy tutorial. The web and RDBMS with just enough magic. Screw HTML front ends. Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Get your data right. Front ends and modern front end tech stacks are an unholy time suck that offer little for hobby or small apps.
- untog 9y ago
  > Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Huh? That HTML is what your users will spend 90% of their time interacting with. They won't care one bit what RDBMS you're using. Front end development is deeply frustrating but it's also incredibly important.
  - Typhon 9y ago
    Yeah but users don't read the HTML, the browser does, and it doesn't care that you're using ten <br> tags for vertical spacing instead of an elegant CSS styling property. Edit : just want to make it clear that I'm trying to paraphrase here, I don't know if I agree (although I do want to point out that HN is built in this philosophy)
    - untog 9y ago
      I’d argue that in this era of mobile devices, hard-set line breaks like <br/> are a bad idea even in the immediate term. Regrettably, the front end isn't simple any more, and while the tooling doesn't help I think it's simply not an easy problem to fix any more.
      - Typhon 9y ago
        yeah I was just giving an example of quick-and-dirty HTML that I thought was being advocated.
      - 52-6F-62 9y ago
        You're absolutely right, but the comment above seemed to be explicitly making a point about getting acquainted with HTML GUI layouts.
  - dualogy 9y ago
    Maybe what parent meant to suggest is to wait with "proper frontend" and keep ugly quick&dirty minimal HTML until the whole software/app/system/server/set-of-services/whatever is "done", and just works. Because once you distract yourself with making it pretty, it's a rabbit-hole of ever-new, ever-different, ever-more-promising paradigms to switch to and fro. But not sure if that was his idea here..
    - bitexploder 9y ago
      Yes. Write simple but correct HTML. Don't make it look nice. Make the UX good. Don't spend time with crazy JS frameworks. Simple forms. Use properties for screen readers and usability if you must. When you are learning avoid getting sucked into JS and CSS holes.
  - bitexploder 9y ago
    When you are learning spending time on the front end is a terrible time investment. Your first web apps are for yourself usually. This is exactly why the grandparent gets frustrated. Make an ugly app that works first.
- deleted 9y ago
  [deleted]
- open-source-ux 9y ago
  > Write the ugliest HTML you want Writing correct HTML helps people using screen readers because they can navigate a page using the descriptive HTML elements. In fact, writing correct HTML is probably the simplest and easiest thing to do when it comes to creating a web page. It's CSS that's needlessly complicated and unpredictable.
  - bitexploder 9y ago
    If you want to write web apps, save the HTML for last. When you are writing apps for yourself you write just what you need. That is what I am saying. Functional HTML first. It's not hard to write plain looking but very good UX. I think we are agreeing. I meant write stuff that works but is not fancy and avoid the big JS frameworks.
    - open-source-ux 9y ago
      Yes, I agree. Sometimes (maybe often?) plain HTML and CSS with a little bit of Javascript (and server-side logic) works perfectly fine for many "web apps". It can even be faster (and simpler) than downloading all the app logic and a fat Javascript library to the client.
      - sebpmtl 9y ago
        That's why It's a good thing to develop mobile-first, you tend to keep things more minimal.
chickenfries 9y ago
What did you try to do to learn web development? I'm sure there was something you could do to change your approach, if you're really capable of learning how to build complicated, networked GUI applications in Rust and C, you must be able to grok the basics of web architecture. Honestly these comments that we should throw away the web are just as ignorant as people who think we should just throw away all of our C code.
- GeorgeTirebiter 9y ago
  I consider myself pretty good, too, but had to take a community college class to force myself to spend the time to learn website dev. It's an abortion. HTML/DOM/CSS + JavaScript? Back End / Front End? You simply must use a framework to do anything real. In class, we developed without frameworks, to see how the guts work. Like real guts, Web guts are ugly (although perhaps utilitarian) and not especially streamlined for their job; but given they evolved from simpler times, maybe pasting over the cruft with more cruft is our only salvation today. I normally do embedded, and, to me, the Web Browser is just an app. Anybody could write an app that accepts text as input and output formatted text, graphics, pictures. It certainly could be optimized for within-the-app apps. I'm not sure why this hasn't been yet done. JSLinux is a proof-of-concept: https://bellard.org/jslinux/ https://bellard.org/jslinux/
jerf 9y ago
"Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development." If it makes you feel any better, that's because there isn't a coherent mental model. If you've ever heard of the ORM/Relational impedance mismatch, it's got nothing on the set of impedance mismatches between the way servers like to work, the HTTP protocol (and its still very page-based orientation in a world of streams), the browser's DOM model, and how Javascript works, especially if you want to get excellent performance out of it. It is my opinion that this is why you see so much churn in the web world; the continuous iterations on client-side frameworks, server-side frameworks, this Javascript DOM library, that Javascript DOM library, now an integrated framework, now recommending assembling your own from bits and pieces... it's all a reflection of the fact that none of these pieces particularly work all that well together in the way we'd really like them to. There's a ton of possibilities, all of them frankly pretty bad in most ways but good for this one use case, but a different use case for each tech, and that's a recipe for a lot of churn. My recommendation to anyone getting into this world is A: learn the basics of HTTP B: learn the basics of HTML C: clock some time with Javascript's basic DOM interface and maybe jQuery and then D: relax about the whole thing, unless you really think you're going to build an app that scales up to the tens of thousands of simultaneous users. The truth is that when it comes down to it there are still plenty of applications you can successfully build and deploy using completely 2005 technologies... and the dirty secret truth is that you may well beat someone to market who is over-invested in staying Up To Date and constantly throwing away all their skills. (You will not beat to market someone who is judiciously staying up to date, and carefully picking and choosing what modern tech to learn and deploy. But you still probably won't be that far behind them, either. And that is not the person who is actually freaking everyone out about the web; it's the guy vigorously selling Vue.js or whatever modern thing as the hot new thing and that all previous JS libraries are now trash that should be used by nobody, when six months ago they were saying the same thing about something else.)
- addicted 9y ago
  A lot of the churn is because the web is so young as an application platform. It’s been less than 20years since GMail which was probably the first thing that even approximated an application on the web. Chrome was released in 2008 less than 10years ago, and it was the first time the web had a runtime engine which was perform at enough to even build an app.
krapp 9y ago
The thing is, though, the web is reasonable - for its intended purpose, which is displaying and interlinking documents. And despite the complaints, faults and shortcomings, it's even remarkably not as bad as it could be at being an application platform. Throwing that out because it's less than optimal at a use case it was never intended to serve would be monumentally short-sighted. Just build something else and leave the web be.
- andrepd 9y ago
  I think what he meant was "throw out the web as a platform for applications", not as a platform for document distributions.
  - tannhaeuser 9y ago
    If so I'm in full agreement. It's truly mind-blowing how much energy has been wasted on trying to shoehorn the web into an app delivery platform over the last decade. To what end? To make the browser a general purpose platform? We have that already, it's called an "operating system". Edit: that said, I disagree with many points and the general negativity in TFA
    - aperiodic 9y ago
      It's a great example of worse is better in action: a technically inferior platform winning out because it's better at one or two things that enable virality, which is the only thing that matters when all the money is looking for high growth. In this case, it's that webapps require zero effort and time from the user to get started with, and allow developers to get the closest to the "write once, run anywhere" dream than anything else (if you're doing a decent responsive design, you can even get a good experience on both desktops and phones with much less effort and no gatekeeping), so the development effort is a lot lower. These two attributes make it really hard for a native app to compete on growth terms with a webapp, since it has a higher hurdle for users, higher initial development costs to target the same amount of users, and higher iteration costs to ship (and get users to install) a new version. It doesn't matter that it's hilariously inefficient; as long as it's just below the threshold where the user tears their hair out, they're not going to jump ship.
bertan 9y ago
I think total need for developers in the world increased so rapidly that we couldn't find people with enough experience and teaching abilities to educate new developers properly. If what Robert C. Martin claims is true, number of developers in the world doubles every 5 years. So, I really think there is a competency issue here. However, I don't believe that it is restricted to the web; it is true for every platform. It is just that learning web technologies seems to be a better choice if you are new to programming as one can use those skills for almost every platform. (yeah you can use almost every language to develop for multiple platforms, but come on even Microsoft is using web tech for vscode)
mch82 9y ago
Any chance most of the software you're writing is headless? My experience has been the opposite. I first learned C in college, and loved making command line interfaces but never understood how to make GUI applications. When I was introduced to browser hosted front-ends, laying out interfaces for GUI apps seemed a lot simpler and made a lot more sense. Python was the first language where I was able to figure out how to write a GUI for an application running fully contained on a device. It might just be me, but it doesn't seem like a lot of programming language training paths emphasize the human user interface (command line, GUI, or otherwise). The web platform definitely does.
- 3chelon 9y ago
  So weird. I also learned C in college, but Python I love and use exclusively from the command line; I'd choose to write GUI code in almost anything else. But your central argument is right, that UI stuff is ignored in non-web languages at the expense of "core" concepts, and that in turn probably does lead to insecurity. The reality is, it's historically been hard enough to find decent coders without worrying about myriad security concerns too.
madeofpalk 9y ago
> Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. For what its worth, any time I go to sit down and learn iOS development I find it completely overwhelming. Just because you're a fancy smart assembly developer doesn't mean you'll immediately be able to master everything you encounter.
sanbor 9y ago
Probably you spent several years at low level programming and you're fluid and productive in that world. In the other hand, I spent my last 10 years dealing with websites and I feel fluent and productive with the web, while I feel frustrated and overwhelmed by low level programming. The web is 20 years of quirks. Low level stuff is 40 years of quirks. If you want send me a message and maybe I can help you with learning web and you can help me with low level stuff :)
- wruza 9y ago
  For me (not your parent commenter) the problem is not that I can't understand things or need help to grasp something new. I have 2 decades of desktop, low-level, server, business programming in bunch of languages and frameworks behind; didn't touch games and 3d though. The problem is that every time I start to read yet another html/css/js tutorial or advanced guide, I get almost physically sick of it. It is like learning [al]chemistry before analytical method appeared. You're presented to the fragmented facts, none of them covering the entire picture, none of them having any design thoughts. For first few times I thought that it is just a bad tutorial, but with time I realized that it's the nature of web. You can't do a right guess there. You can't metaprogram it, because there is no common basis between all the "technologies". You can add new unnecessary flavor though. Millions of failed frameworks represent the supporting evidence for that. It is so detached from programmers reality that even gives "powerful" names to reinvented things: services, routing, reactivity to name a few. Which are simply modules, callbacks and two-point bindings, the insignificant nomenclature under programmer's feet. Most web devs don't even know what real reactivity is and that is was a regular thing to have circular, heavy-threaded formula references as evaluation model in '84 supercalс working on 96Kb RAM. Do you know why it isn't widely used in today's programming? Because you normally have only one place to set your data and only one way to propagate it. You DO NOT need reactivity in a sane design. You have to be aware of your data flow and be able to analyze it. Native programming overwhelms you because it is saturated with disciplines you was never convinced to follow (or allowed to break for local benefit), not because it is twice as old. Just pick few classic programming books to introduce. Web is long done, you'll never see it being any better than now, or yesterday, or a year ago. The article may be ranty, but it is right that web still reinvents the '90s having 100x processing power at hands. It simply goes nowhere. I don't hope, I know it will be dead some day, because that bubble becomes too heavy to not pop itself.
always_good 9y ago
I don't really understand. You say that the web needs to be completely thrown out, yet you decided that your foray into web development should be to build a thick Javascript web application? Not some simple Flask endpoint? Because I assume you could figure out a basic request/response server, and your issue is that you dove into something like Webpack + React + Flux + Qux + Fux + Foo.
- mikebenfield 9y ago
  > Not some simple Flask endpoint? I don't even know what a "Flask endpoint" is. Actually I barely know what Webpack and React are either.
  - bocklund 9y ago
    Flask is a Python framework for web servers. It's like 5 minutes to a HelloWorld webpage
    - Spivak 9y ago
      The time to create a "hello world" page isn't really the best selling point when it can be done in ~15 seconds depending on your internet speed. yum install -y httpd && echo 'Hello, World.' >/var/www/html/index.html && systemctl start httpd Or assuming that you want something in python echo 'Hello, World.' > index.html && python -m http.server
jacquesm 9y ago
That's meant that way. What better way to get rid of annoying independent programmers like you (and me) than by setting things up in such a way that you need a large company to make any headway at all? That's just another form of lock-in and a way to deepen the moat for upstarts who are historically the most dangerous types for established players.
da02 9y ago
I felt the same way yesterday about writing a little app to position X windows in preconfiged positions.... in Crystal using C bindings. I would have to learn C, make, xlib, and a while bunch of other things just for a simple, non-buggy executable. I just gave up and decide to keep using Crystal and make external POSIX (ie shelling out) calls to the compiled wmctrl executable.
vbezhenar 9y ago
I don't think that the web is complex, at least not in a sense I'm understanding "complexity" word. Web is a huge pile of semi-specified standards. There are bunch of written standards, like XML, HTML, DOM, JavaScript, CSS (each with multiple versions). There is a lot of tribal knowledge, that you'll get only with experience, like things that doesn't work with IE 6 (luckily IE 6 is not very relevant today). There is some security-related stuff, things that you should remember if you don't want to make a vulnerable website. But it's not a complexity, it's just a lot of things. Now there's a bad tools. JavaScript is a bad language and its ecosystem is mostly terrible. If you want to create react app with hot reload using es6 and other things that modern developer expects to have, you'll end up with tons of configuration glues, some experimental hacks and many tools hacked together. Or you can download "starter" template, where those hacks are already glued for you. Good luck to add or change or fix something there. In contrast I can write very simple maven config and it'll support almost everything I would ever need without any configuration. It's difficult to navigate among those tools, but this difficulty will be solved with better tools and better documentation. I'm eager to wait until I can throw webpack and just write ES7 with imports and browser will understand it. I shouldn't need build tools for web.
- Falkon1313 9y ago
  That is complexity. It's layers upon layers upon layers of dynamic runtime interactions. Try working on maintaining/extending a web application that's been developed over the course of many years, during that course of time using all of those technologies in many different versions, with the many different styles of architecture and best practices that were 'the right way' to do it at the various points in time when those parts of the system were added. You'll find all kinds of complexity in there, even without looking at the server-side. Then you mention the modern ecosystem of javascript tools with all of its glued-together hacks, dependency nightmares, grey boxes of 3rd party code that you can look at but don't have the time to understand fully (all of which use different styles/techniques). That is complexity. The alternative as described by the article is traditional development where you have a language+IDE+GUI design tool that compiles applications into a single file that, if it compiles, just works (except for any bugs). People who haven't developed in Delphi or similar environment have no idea how much less complexity there could be.
wozer 9y ago
It doesn't have to be complicated. A single page app implemented with React, calling some REST Api to retrieve and store its data, is basically all you need.
- twsted 9y ago
  And you don't even need React for that.
JCSato 9y ago
My two cents as somebody who's made the shift from C++ & Java to web dev over the past year or so: The complexity really depends on where you start. Part of what muddies this with web dev is how many resources there are. If you look up "what front end developers need to know in 20XX", you get a dizzying amount of results. Learn React, Redux, SASS/LESS, Angular, Express, Webpack, Docker, etc. There are lists upon lists and tutorials on tutorials. A while back, before Google made it a standard feature, I did a project that took a Google maps route and found gas stations along said route, giving you back a list of stations with prices, etc. You could select a station, and it would update your route automatically. The whole thing was vanilla JS and Node (ok, I used jQuery for AJAX requests). No frameworks, no build tools, just plain old Javascript. As I got deeper into Node, though, I found myself taking advantage of frameworks and packages naturally because they solved a problem I'd previously encountered. React makes things like dynamic lists of gas stations much easier to organize and keep consistent. Preprocessors take a lot of tedium and guesswork out of CSS. All of these things are an important part of being a "Front End Developer" because they make development easier to maintain, structure, and build upon. They don't change the fundamentals of what you're doing. This isn't really any different from being a native developer. A few years back when I was trying to make a super basic C++ GUI application. I kept bouncing between GDI+ to GDI to Direct2D to Direct3D to SDL to OpenGL, etc. I was too focused on trying to find the appropriate tool that would conform to my expectations of how the app "should" be developed, and I gave up. I didn't have a good sense for what problems those things solved, so of course I had no idea why I would use one over the other or which stack was best for my use case. A little while ago I took a stab at graphics programming at a much lower level, spent some time with DirectX and OpenGL, and I would approach my C++ app idea much differently now because of that knowledge. I think anybody who gets into web dev by trying to learn frameworks is going to have a daunting time. Try making your app with vanilla HTML, JS, CSS, and a simple Node server (don't even bother with express, just use Request and localhost). Look at what was tedious or difficult about it, then go find a framework that fixes that thing. All these tools build on each other incrementally like that. Don't start with React, make it all in HTML, then make the incremental transition to Handlebars, then make the transition to React (for example). The vanilla stuff won't make you a front end developer, just like how me writing something in OpenGL doesn't make me a "graphics programmer", but it will give you the foundation required.
fdchn2016 9y ago
You need to learn CSS just the way you would approach a learning another programming language. From scratch - without assumptions and short cut solutions you get from Googling. Understanding stuff like block, inline block and positioning and go from there. Take a month's equivalent out and spending time learning it. Javascript too can be an extremely confusing language for those who come from typed systems. Then comes the DOM. Then there is the communication system - AJAX, websockets etc. Finally there is understanding the browser dev tools. As the tooling has accumulated understanding how to use it and internalize everything will take atleast 2 - 3 days. If you don't take time to learn these 4 systems independently, when they're all mashed up as in a web application, you will struggle .

bitexploder 9y ago

That's cause the web is full of hype. Try Python Flask. A three line Python function and you are going. No magic. Just request and response. It is easy. Bang out a model class and read the SQLAlchemy tutorial. The web and RDBMS with just enough magic. Screw HTML front ends. Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Get your data right. Front ends and modern front end tech stacks are an unholy time suck that offer little for hobby or small apps.

untog 9y ago
> Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Huh? That HTML is what your users will spend 90% of their time interacting with. They won't care one bit what RDBMS you're using. Front end development is deeply frustrating but it's also incredibly important.
- Typhon 9y ago
  Yeah but users don't read the HTML, the browser does, and it doesn't care that you're using ten <br> tags for vertical spacing instead of an elegant CSS styling property. Edit : just want to make it clear that I'm trying to paraphrase here, I don't know if I agree (although I do want to point out that HN is built in this philosophy)
  - untog 9y ago
    I’d argue that in this era of mobile devices, hard-set line breaks like <br/> are a bad idea even in the immediate term. Regrettably, the front end isn't simple any more, and while the tooling doesn't help I think it's simply not an easy problem to fix any more.
    - Typhon 9y ago
      yeah I was just giving an example of quick-and-dirty HTML that I thought was being advocated.
    - 52-6F-62 9y ago
      You're absolutely right, but the comment above seemed to be explicitly making a point about getting acquainted with HTML GUI layouts.
- dualogy 9y ago
  Maybe what parent meant to suggest is to wait with "proper frontend" and keep ugly quick&dirty minimal HTML until the whole software/app/system/server/set-of-services/whatever is "done", and just works. Because once you distract yourself with making it pretty, it's a rabbit-hole of ever-new, ever-different, ever-more-promising paradigms to switch to and fro. But not sure if that was his idea here..
  - bitexploder 9y ago
    Yes. Write simple but correct HTML. Don't make it look nice. Make the UX good. Don't spend time with crazy JS frameworks. Simple forms. Use properties for screen readers and usability if you must. When you are learning avoid getting sucked into JS and CSS holes.
- bitexploder 9y ago
  When you are learning spending time on the front end is a terrible time investment. Your first web apps are for yourself usually. This is exactly why the grandparent gets frustrated. Make an ugly app that works first.
deleted 9y ago
[deleted]
open-source-ux 9y ago
> Write the ugliest HTML you want Writing correct HTML helps people using screen readers because they can navigate a page using the descriptive HTML elements. In fact, writing correct HTML is probably the simplest and easiest thing to do when it comes to creating a web page. It's CSS that's needlessly complicated and unpredictable.
- bitexploder 9y ago
  If you want to write web apps, save the HTML for last. When you are writing apps for yourself you write just what you need. That is what I am saying. Functional HTML first. It's not hard to write plain looking but very good UX. I think we are agreeing. I meant write stuff that works but is not fancy and avoid the big JS frameworks.
  - open-source-ux 9y ago
    Yes, I agree. Sometimes (maybe often?) plain HTML and CSS with a little bit of Javascript (and server-side logic) works perfectly fine for many "web apps". It can even be faster (and simpler) than downloading all the app logic and a fat Javascript library to the client.
    - sebpmtl 9y ago
      That's why It's a good thing to develop mobile-first, you tend to keep things more minimal.

chickenfries 9y ago

What did you try to do to learn web development? I'm sure there was something you could do to change your approach, if you're really capable of learning how to build complicated, networked GUI applications in Rust and C, you must be able to grok the basics of web architecture. Honestly these comments that we should throw away the web are just as ignorant as people who think we should just throw away all of our C code.

GeorgeTirebiter 9y ago
I consider myself pretty good, too, but had to take a community college class to force myself to spend the time to learn website dev. It's an abortion. HTML/DOM/CSS + JavaScript? Back End / Front End? You simply must use a framework to do anything real. In class, we developed without frameworks, to see how the guts work. Like real guts, Web guts are ugly (although perhaps utilitarian) and not especially streamlined for their job; but given they evolved from simpler times, maybe pasting over the cruft with more cruft is our only salvation today. I normally do embedded, and, to me, the Web Browser is just an app. Anybody could write an app that accepts text as input and output formatted text, graphics, pictures. It certainly could be optimized for within-the-app apps. I'm not sure why this hasn't been yet done. JSLinux is a proof-of-concept: https://bellard.org/jslinux/ https://bellard.org/jslinux/

jerf 9y ago

"Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development." If it makes you feel any better, that's because there isn't a coherent mental model. If you've ever heard of the ORM/Relational impedance mismatch, it's got nothing on the set of impedance mismatches between the way servers like to work, the HTTP protocol (and its still very page-based orientation in a world of streams), the browser's DOM model, and how Javascript works, especially if you want to get excellent performance out of it. It is my opinion that this is why you see so much churn in the web world; the continuous iterations on client-side frameworks, server-side frameworks, this Javascript DOM library, that Javascript DOM library, now an integrated framework, now recommending assembling your own from bits and pieces... it's all a reflection of the fact that none of these pieces particularly work all that well together in the way we'd really like them to. There's a ton of possibilities, all of them frankly pretty bad in most ways but good for this one use case, but a different use case for each tech, and that's a recipe for a lot of churn. My recommendation to anyone getting into this world is A: learn the basics of HTTP B: learn the basics of HTML C: clock some time with Javascript's basic DOM interface and maybe jQuery and then D: relax about the whole thing, unless you really think you're going to build an app that scales up to the tens of thousands of simultaneous users. The truth is that when it comes down to it there are still plenty of applications you can successfully build and deploy using completely 2005 technologies... and the dirty secret truth is that you may well beat someone to market who is over-invested in staying Up To Date and constantly throwing away all their skills. (You will not beat to market someone who is judiciously staying up to date, and carefully picking and choosing what modern tech to learn and deploy. But you still probably won't be that far behind them, either. And that is not the person who is actually freaking everyone out about the web; it's the guy vigorously selling Vue.js or whatever modern thing as the hot new thing and that all previous JS libraries are now trash that should be used by nobody, when six months ago they were saying the same thing about something else.)

addicted 9y ago
A lot of the churn is because the web is so young as an application platform. It’s been less than 20years since GMail which was probably the first thing that even approximated an application on the web. Chrome was released in 2008 less than 10years ago, and it was the first time the web had a runtime engine which was perform at enough to even build an app.

krapp 9y ago

The thing is, though, the web is reasonable - for its intended purpose, which is displaying and interlinking documents. And despite the complaints, faults and shortcomings, it's even remarkably not as bad as it could be at being an application platform. Throwing that out because it's less than optimal at a use case it was never intended to serve would be monumentally short-sighted. Just build something else and leave the web be.

andrepd 9y ago
I think what he meant was "throw out the web as a platform for applications", not as a platform for document distributions.
- tannhaeuser 9y ago
  If so I'm in full agreement. It's truly mind-blowing how much energy has been wasted on trying to shoehorn the web into an app delivery platform over the last decade. To what end? To make the browser a general purpose platform? We have that already, it's called an "operating system". Edit: that said, I disagree with many points and the general negativity in TFA
  - aperiodic 9y ago
    It's a great example of worse is better in action: a technically inferior platform winning out because it's better at one or two things that enable virality, which is the only thing that matters when all the money is looking for high growth. In this case, it's that webapps require zero effort and time from the user to get started with, and allow developers to get the closest to the "write once, run anywhere" dream than anything else (if you're doing a decent responsive design, you can even get a good experience on both desktops and phones with much less effort and no gatekeeping), so the development effort is a lot lower. These two attributes make it really hard for a native app to compete on growth terms with a webapp, since it has a higher hurdle for users, higher initial development costs to target the same amount of users, and higher iteration costs to ship (and get users to install) a new version. It doesn't matter that it's hilariously inefficient; as long as it's just below the threshold where the user tears their hair out, they're not going to jump ship.

bertan 9y ago

I think total need for developers in the world increased so rapidly that we couldn't find people with enough experience and teaching abilities to educate new developers properly. If what Robert C. Martin claims is true, number of developers in the world doubles every 5 years. So, I really think there is a competency issue here. However, I don't believe that it is restricted to the web; it is true for every platform. It is just that learning web technologies seems to be a better choice if you are new to programming as one can use those skills for almost every platform. (yeah you can use almost every language to develop for multiple platforms, but come on even Microsoft is using web tech for vscode)

mch82 9y ago

Any chance most of the software you're writing is headless? My experience has been the opposite. I first learned C in college, and loved making command line interfaces but never understood how to make GUI applications. When I was introduced to browser hosted front-ends, laying out interfaces for GUI apps seemed a lot simpler and made a lot more sense. Python was the first language where I was able to figure out how to write a GUI for an application running fully contained on a device. It might just be me, but it doesn't seem like a lot of programming language training paths emphasize the human user interface (command line, GUI, or otherwise). The web platform definitely does.

3chelon 9y ago
So weird. I also learned C in college, but Python I love and use exclusively from the command line; I'd choose to write GUI code in almost anything else. But your central argument is right, that UI stuff is ignored in non-web languages at the expense of "core" concepts, and that in turn probably does lead to insecurity. The reality is, it's historically been hard enough to find decent coders without worrying about myriad security concerns too.

madeofpalk 9y ago

> Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. For what its worth, any time I go to sit down and learn iOS development I find it completely overwhelming. Just because you're a fancy smart assembly developer doesn't mean you'll immediately be able to master everything you encounter.

sanbor 9y ago

Probably you spent several years at low level programming and you're fluid and productive in that world. In the other hand, I spent my last 10 years dealing with websites and I feel fluent and productive with the web, while I feel frustrated and overwhelmed by low level programming. The web is 20 years of quirks. Low level stuff is 40 years of quirks. If you want send me a message and maybe I can help you with learning web and you can help me with low level stuff :)

wruza 9y ago
For me (not your parent commenter) the problem is not that I can't understand things or need help to grasp something new. I have 2 decades of desktop, low-level, server, business programming in bunch of languages and frameworks behind; didn't touch games and 3d though. The problem is that every time I start to read yet another html/css/js tutorial or advanced guide, I get almost physically sick of it. It is like learning [al]chemistry before analytical method appeared. You're presented to the fragmented facts, none of them covering the entire picture, none of them having any design thoughts. For first few times I thought that it is just a bad tutorial, but with time I realized that it's the nature of web. You can't do a right guess there. You can't metaprogram it, because there is no common basis between all the "technologies". You can add new unnecessary flavor though. Millions of failed frameworks represent the supporting evidence for that. It is so detached from programmers reality that even gives "powerful" names to reinvented things: services, routing, reactivity to name a few. Which are simply modules, callbacks and two-point bindings, the insignificant nomenclature under programmer's feet. Most web devs don't even know what real reactivity is and that is was a regular thing to have circular, heavy-threaded formula references as evaluation model in '84 supercalс working on 96Kb RAM. Do you know why it isn't widely used in today's programming? Because you normally have only one place to set your data and only one way to propagate it. You DO NOT need reactivity in a sane design. You have to be aware of your data flow and be able to analyze it. Native programming overwhelms you because it is saturated with disciplines you was never convinced to follow (or allowed to break for local benefit), not because it is twice as old. Just pick few classic programming books to introduce. Web is long done, you'll never see it being any better than now, or yesterday, or a year ago. The article may be ranty, but it is right that web still reinvents the '90s having 100x processing power at hands. It simply goes nowhere. I don't hope, I know it will be dead some day, because that bubble becomes too heavy to not pop itself.

always_good 9y ago

I don't really understand. You say that the web needs to be completely thrown out, yet you decided that your foray into web development should be to build a thick Javascript web application? Not some simple Flask endpoint? Because I assume you could figure out a basic request/response server, and your issue is that you dove into something like Webpack + React + Flux + Qux + Fux + Foo.

mikebenfield 9y ago
> Not some simple Flask endpoint? I don't even know what a "Flask endpoint" is. Actually I barely know what Webpack and React are either.
- bocklund 9y ago
  Flask is a Python framework for web servers. It's like 5 minutes to a HelloWorld webpage
  - Spivak 9y ago
    The time to create a "hello world" page isn't really the best selling point when it can be done in ~15 seconds depending on your internet speed. yum install -y httpd && echo 'Hello, World.' >/var/www/html/index.html && systemctl start httpd Or assuming that you want something in python echo 'Hello, World.' > index.html && python -m http.server

jacquesm 9y ago

That's meant that way. What better way to get rid of annoying independent programmers like you (and me) than by setting things up in such a way that you need a large company to make any headway at all? That's just another form of lock-in and a way to deepen the moat for upstarts who are historically the most dangerous types for established players.

da02 9y ago

I felt the same way yesterday about writing a little app to position X windows in preconfiged positions.... in Crystal using C bindings. I would have to learn C, make, xlib, and a while bunch of other things just for a simple, non-buggy executable. I just gave up and decide to keep using Crystal and make external POSIX (ie shelling out) calls to the compiled wmctrl executable.

vbezhenar 9y ago

I don't think that the web is complex, at least not in a sense I'm understanding "complexity" word. Web is a huge pile of semi-specified standards. There are bunch of written standards, like XML, HTML, DOM, JavaScript, CSS (each with multiple versions). There is a lot of tribal knowledge, that you'll get only with experience, like things that doesn't work with IE 6 (luckily IE 6 is not very relevant today). There is some security-related stuff, things that you should remember if you don't want to make a vulnerable website. But it's not a complexity, it's just a lot of things. Now there's a bad tools. JavaScript is a bad language and its ecosystem is mostly terrible. If you want to create react app with hot reload using es6 and other things that modern developer expects to have, you'll end up with tons of configuration glues, some experimental hacks and many tools hacked together. Or you can download "starter" template, where those hacks are already glued for you. Good luck to add or change or fix something there. In contrast I can write very simple maven config and it'll support almost everything I would ever need without any configuration. It's difficult to navigate among those tools, but this difficulty will be solved with better tools and better documentation. I'm eager to wait until I can throw webpack and just write ES7 with imports and browser will understand it. I shouldn't need build tools for web.

Falkon1313 9y ago
That is complexity. It's layers upon layers upon layers of dynamic runtime interactions. Try working on maintaining/extending a web application that's been developed over the course of many years, during that course of time using all of those technologies in many different versions, with the many different styles of architecture and best practices that were 'the right way' to do it at the various points in time when those parts of the system were added. You'll find all kinds of complexity in there, even without looking at the server-side. Then you mention the modern ecosystem of javascript tools with all of its glued-together hacks, dependency nightmares, grey boxes of 3rd party code that you can look at but don't have the time to understand fully (all of which use different styles/techniques). That is complexity. The alternative as described by the article is traditional development where you have a language+IDE+GUI design tool that compiles applications into a single file that, if it compiles, just works (except for any bugs). People who haven't developed in Delphi or similar environment have no idea how much less complexity there could be.

wozer 9y ago

It doesn't have to be complicated. A single page app implemented with React, calling some REST Api to retrieve and store its data, is basically all you need.

twsted 9y ago
And you don't even need React for that.

JCSato 9y ago

My two cents as somebody who's made the shift from C++ & Java to web dev over the past year or so: The complexity really depends on where you start. Part of what muddies this with web dev is how many resources there are. If you look up "what front end developers need to know in 20XX", you get a dizzying amount of results. Learn React, Redux, SASS/LESS, Angular, Express, Webpack, Docker, etc. There are lists upon lists and tutorials on tutorials. A while back, before Google made it a standard feature, I did a project that took a Google maps route and found gas stations along said route, giving you back a list of stations with prices, etc. You could select a station, and it would update your route automatically. The whole thing was vanilla JS and Node (ok, I used jQuery for AJAX requests). No frameworks, no build tools, just plain old Javascript. As I got deeper into Node, though, I found myself taking advantage of frameworks and packages naturally because they solved a problem I'd previously encountered. React makes things like dynamic lists of gas stations much easier to organize and keep consistent. Preprocessors take a lot of tedium and guesswork out of CSS. All of these things are an important part of being a "Front End Developer" because they make development easier to maintain, structure, and build upon. They don't change the fundamentals of what you're doing. This isn't really any different from being a native developer. A few years back when I was trying to make a super basic C++ GUI application. I kept bouncing between GDI+ to GDI to Direct2D to Direct3D to SDL to OpenGL, etc. I was too focused on trying to find the appropriate tool that would conform to my expectations of how the app "should" be developed, and I gave up. I didn't have a good sense for what problems those things solved, so of course I had no idea why I would use one over the other or which stack was best for my use case. A little while ago I took a stab at graphics programming at a much lower level, spent some time with DirectX and OpenGL, and I would approach my C++ app idea much differently now because of that knowledge. I think anybody who gets into web dev by trying to learn frameworks is going to have a daunting time. Try making your app with vanilla HTML, JS, CSS, and a simple Node server (don't even bother with express, just use Request and localhost). Look at what was tedious or difficult about it, then go find a framework that fixes that thing. All these tools build on each other incrementally like that. Don't start with React, make it all in HTML, then make the incremental transition to Handlebars, then make the transition to React (for example). The vanilla stuff won't make you a front end developer, just like how me writing something in OpenGL doesn't make me a "graphics programmer", but it will give you the foundation required.

fdchn2016 9y ago

You need to learn CSS just the way you would approach a learning another programming language. From scratch - without assumptions and short cut solutions you get from Googling. Understanding stuff like block, inline block and positioning and go from there. Take a month's equivalent out and spending time learning it. Javascript too can be an extremely confusing language for those who come from typed systems. Then comes the DOM. Then there is the communication system - AJAX, websockets etc. Finally there is understanding the browser dev tools. As the tooling has accumulated understanding how to use it and internalize everything will take atleast 2 - 3 days. If you don't take time to learn these 4 systems independently, when they're all mashed up as in a web application, you will struggle .