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.
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
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.
It worked OK when we just wanted to run software written by a handful of trusted parties... Microsoft, Adobe, id Software. But as soon as there were 1000s of companies writing software that we wanted to try, running binaries ceased to be a good idea. I don't really trust any binary software on my machine that isn't written by Apple. But I will open basically anything in a web browser because I don't have to trust it.
Even now, with all the sandboxing, Microsoft and Apple still have to manually review software in their stores. And truthfully, app stores are basically a naive Web of Trust system. It's not safe at all. Applications constantly open up holes and then say "oops! Security bug!" and what... you're owned now? But Apple doesn't believe it was a maliciously placed hole, so it's all good? Hell of a security model!
The only real "fix" to this situation would be to make software vendors actually liable for the correct functionality of their product. Imagine no more warranty disclaimers or other bullshit in the licenses for "final" products (compiled binaries, executable JS in websites...). All other engineering professions are legally held to their respective standards. It's time we start raising that bar for software as well.
I'd like to see some software company execs soil their pants because they know that their products are lousy crap.
That's incredibly funny. I guess sooner or later you'll learn why it's a losing strategy.
The web is probably the largest malware infection vector nowadays.
You could download
- a page on it's own
- a page an all pages recursively for up to 3 levels
- optionally filtered by domain or path inside domain
- optionally including javascript (IIRC)
Sadly this is now broken in the new extension model and fixing it doesn't seem to be a priority.
Firefox is still my favourite browser by far but my enthusiasm isn't as strong as it used to be.
On the bright side even if it doesn't seem to be a priority work seems to progress on bringing the new extension APIs to a point where several of the old extensions can be recreated.
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.)
Mapping objects to tables is a solved problem. The only noteworthy challenge is subtyping but it has easy solutions. I'm surprised how well it works even if you have an old crusty database with an archaic table structure. Compared to serialising objects to JSON or other formats that have no concept of identity it's downright trivial. However mapping objects to tables is the primary thing an ORM really does. Usually it implements lazyness for correctness so that your code while inefficient still works as intended.
What an ORM however does not do is write queries for you. Databases are remote devices, you can't just treat remote objects as if they were local (like CORBA did) if you care about performance.
Remember: You still have to write your queries but usually the ORM still helps you writing queries by providing a query builder or has it's own query language. The point of the ORM is that you don't have to manually marshall rows into objects, it's not a tool to avoid queries. It's right there in the name: Object Relational Mapping. It does not say AutomaticQueryGenerator or something related to queries.
Sure, but that's just the standard solution that hides the mismatch. The mismatch is still there. Which is why when performance becomes an issue, there's a whole bag of tricks for tuning the ORM or just sidestepping it and writing a sane query. It's also part of why the SQL database went from the only thing people could conceive of using to one tool among many for data persistence.
As 1970s paradigms go, SQL has had a good run. But the main problem it solves, easily finding and changing your data somewhere on a small number of spinning metal disks, is just not the central problem of computing that it was for a few decades.
At the time this change was known as AJAX, and GMail is listed as a pioneer: https://en.wikipedia.org/wiki/Ajax_(programming)
Squirrelmail, by contrast, rendered a new page for most user actions. Especially the viewing of messages.
As I recall there was a fight about getting it in and the creators called it XMLHttpRequest because XML was the hotness at the time and that got it past the project managers and PHBs.
-Webmail was already established as a "thing" when Gmail came out, even in Universities.
-Gmail wasn't particularly special from a UI perspective and was comparable to other offerings at the time.
-There was plenty of other web apps already that weren't Google products. In fact, I, personally, was writing one at the time GMail came in out.
Pre-AJAX, web-based services were just a series of forms, and the interactivity patterns harkened back to "smart terminal" [1] form-based use for mainframes in the 1970s. I believe the user you were responding to uses "application" to mean something approximating the desktop application experience of the 80s or the current mobile app experience.
So the distinction they're drawing is about the kind of interactivity. Squirrelmail, et al, were a series of forms and pages. GMail didn't do a new page or frame load every time you looked at a new message. UI rendering and interactivity became client-only activities, with the server providing an API.
[1] now known as block-oriented terminal: https://en.wikipedia.org/wiki/Block-oriented_terminal
GMail was different because it offered an outlandish 1GB of mail space, when everywhere else you got 1-10MB mailboxes. Since it was launched on April 1st, most people did not believe it at first. And (at the time) huge space allowed users to keep and search all old email, instead of deleting old emails being a weekly chore.
Google Earth (the native application) is really old and abandoned by now, but its still better than the new "web" version that only works in Chrome.
Now of course we are using more JSON and XMLHttpRequest is being replaced by Fetch API.
AJAX means Asynchronous Javascript and XML.
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.
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.
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.
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.
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.
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)
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.
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.
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/
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 .
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.
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.
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.
I don't even know what a "Flask endpoint" is. Actually I barely know what Webpack and React are either.
yum install -y httpd && echo 'Hello, World.' >/var/www/html/index.html && systemctl start httpd
echo 'Hello, World.' > index.html && python -m http.serverSo, 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)
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.
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.