The author complains that developers argue about their tools and methods, insist on their favorite techniques, but produce (more) worse apps. Particularly for the amount of time and effort expended on developing the apps.
The thing is: the debates aren’t naive. They’re exactly trying to workout the details.
When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory …
Well they’re trying to solve the problem of (more) better apps with their limited resources. That’s essentially the problem of development.
Asking people to solve development without discussing the tools and methods is to misunderstand the nature of the discussion.
It’s like telling authors to get on and write better novels and not waste time with their opinions on character and plot.
When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory …
This is a good example of how devs get things wrong. The argument between which database to use because you might hit the row limit has zero benefit to the user. It's devs wanting to avoid future work to migrate from one database to another; a problem most apps will never actually see.
Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on cheap bare metal ARM servers, and therefore your website is simple, usable, never goes down, and costs $20/month to run. I have no idea if this is actually good, but let's agree that there's some idealised system out there that would be a lot better than what we have now, even if it doesn't look like this one.
Let's also say I use React and Redux backed by a CQRS Express app running on MongoDB and Kafka, all hosted on AWS, and (for the sake of the argument) let's say this causes my website to be broken in bizarre ways, down all the time, and costs $2000/month to run. This is definitely an exaggeration and some of these technologies are great, but let's agree that there are some hellishly over-engineered systems out there, even if they don't look like this one.
I think the argument is that what matters here is having an example of a $20/month uncomplicated beautiful system to point to. Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool means everyone will use the broken $2000/month system as an exemplar in your field, because they have nothing better to point to.
Everyone is going to miss the point here and go down rabbit holes about various technical bits and that is exactly the point: developers spend lots of time debating everything
The limited resources really doesn't matter. The tech choices really don't matter. Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. Lean towards picking stuff the team has experience using. Then if the web app gets heavier traffic, horizontally scale the web tier and vertically scale the DB to your companies budget. If that amount of scaling doesn't suffice - do the research as you approach that level of traffic not when you have zero users.
When it comes down to standard web apps there are known patterns and known solutions out there to solve the majority of the problems. Reaching for a new/shiny thing to use is fun, learning new development techniques is fun but its rare either of those is going to cause a fundamental shift in solving problems with web apps. We have been using (abusing?) HTTP/HTML/JS/CSS for 25+ years. For small web apps I bet people could solve things with simple PERL/PHP cgi-bin types of scripts today with current versions of HTML/JS/CSS, albeit more securely than in 1999.
To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house, one uses less nails, one is faster, one is a nail with wood glue that will expand at the joint and provide less squeaky floors (I made that up). None of it really matters, you're being paid to frame a house, not do research - just build the thing.
The problem of which DB to use is one that can be figured out ahead of time with even modest attention to more rigorous engineering practice. But that’s not what webdevs the subject of this article do. They play guess-and-check games like they are 15th century engineers building a bridge, because they have hacker mentalities instead of engineer mentalities.
Not to mention the cult of celebrity and fad following in the industry.
We can tackle so-called "essential" problems forever & make no progress actually making the web better though.
This post impacted me & resonated strongly: it's a great notice to be more alert as to whether we're talking about details or something core & significant. Devs can have these discussions deep in the weeds, but it's kind of a farce & disservice when the petty implementation details flood & overrun the topics of what we're making & how we've enriched the media-form.
>I’m hard-pressed to name more than a handful of web apps that I would say are genuinely good with no major flaw.
>Content websites are a different matter. A static or server-rendered content website with adequate typography and semantic markup is generally going to do its job pretty well.
I feel the exact opposite. Most web-based applications are pretty incredible these days.
It's the "content websites" that are insanely bloated and over engineered (and unnecessarily turned into "apps"). E.g. news sites, new reddit, recipe sites
Airtable, Draw.io, Google Docs, and Photopea are all incredibly well-made web apps that are essentially complete products without any major flaws I can think of. Those were just the first four to come to mind, there are countless countless other wonderfully engineered full featured applications which run totally in your browser. It’s actually a bit of a marvel, when you think about it.
There are great web apps and there are great native apps. I think what the author is asking for here is just “better software” and well, wouldn’t we all love that :)
It’s so bad now that an ad-blocker is rarely sufficient, because even without the ads every other paragraph is broken up by some autoplaying video or some callout to a different article.
In some cases I genuinely struggle to read an article without reader mode or an RSS reader that can scrape the full article.
> Everybody seems to have an opinion on how you do your web dev and how websites and web apps should be structured.
It’s true and it leads to many annoying unproductive arguments, IMO the reason is a fundamental lack of a scientific mindset in evaluating techniques and tooling. We don’t have theories or testable hypotheses, we have opinions.
On one level I like and agree with the author’s idea that results are what really matter. As an engineer trying to achieve outcomes for employers, clients, and customers, this approach has served me well.
As a community of professionals, it would be nice to see more effort to work towards rigorously proven conclusions about what works best and why.
When someone touts a paradigm, technique, or framework as the best, without any real data or theory as to why, I think they should be told to provide evidence or withdraw their argument, and I’d say that goes double when it’s the framework or technique you like or use. IMO, these shouldn’t be fights about tech, they should be ones about quality of discourse.
It's shocking to me how little data there seems to be to support what many consider to be "best practice". About the only real data point I see thrown around is that bugs per LOC being fairly constant. Thus, you get people saying long, two-page functions are bad and should be broken up. But never have I seen someone backup such an exhortation with data. Let alone more nebulous rules like "objects should be open for extension and closed for modification," or anything out SOLID, really.
Sorta. It isn't a lack of a scientific mindset. I argue it is a premature quantification of data such that you can objectively look at it in a scientific way.
We are taught that you can compare things objectively in most school level science classes. This leads folks to thinking their perspective is valid scientifically. Especially if they can put numbers to it. After all, isn't that native empiricism?
I'm in complete agreement with you. At this point, I also endorse threats of flogging for someone who tries to introduce a new framework to a project after the actual work has started.
And actual flogging for the management team if they accept that framework.
This is a wonderful comment! There is missing descriptions of things, the quality, the metrics to use when describing such things and we, the users of those said tools end up spending a lot of time going through bad documentation and learning things by practice. For a trade that pushes the digital frontier to everything it touches, the learning is surprisingly analog.
And still a lot of devs I have met haven’t read About Face : Essentials of Interaction Design. It’s a must read in my book to structure around a project. You don’t have to copy paste it’s ideas, but using its core features makes a project a whole lot smoother for both end user and devs.
I think the bad “web” has a lot more to do with the business side of things than whatever development tools you use. If the website is free to use, it’s either a passion or community project or it sells you. Sometimes that works out sort of well in places like HN, and other times it works out less well like on the infinite amount of shitty news papers. But those news papers can be shitty in all technologies even in the physically printed form.
I do think we need a better tool for finding the passion projects. Because search engines have basically become the “portals” they replaced by curating search results into being about herding us toward sales, but I’m sure we’ll see a shift sooner or later. It’s sort of already happening with more and more people returning to things like news letters instead of reading blogs.
> I do think we need a better tool for finding the passion projects
I like the idea! I wonder though how that would look like. How do you imagine such a tool? Would it be something like a "directory" from back in the 90s where people submit their link under a specific category?
> They keep encountering highly flawed websites or web apps and are assuming that regular web devs can do something about it.
This is the reality that has been grinding me down of late. Nor do I find it limited to only web stuff. I see it in embedded and other market areas.
I was excited over the last few decades to see the field of programmers swell. I have always loved the craft of good software development. I was so excited to see so many others also get into it and naively believed that many more people participating would lead to a larger pool of ideas to draw from and everyone would get on board in some sort of utopian democratic industry wide kumbaya. During the rise of open source, I even felt it was really happening.
If the dev pool of 2022 was like the dev pool of (for example) 1994, just larger, you would have been right. But the software goldrush came and attracted many more who were just in it for the money or just weren't as thoughtful. Scale matters, upscaling people is hard.
Just an observation: the native apps that are better are built on massive, proprietary frameworks developed by platform owners. In some ways, most of the web frameworks are trying to be the One True Web Platform Framework that similarly makes it possible for developers to make better web apps the way that say, AppKit or UIKit makes that possible on Apple's platforms.
So I'm left wondering, did the frameworks fail or did the web developer community fail?
Until or unless something equivalent to those platform frameworks becomes part of the browser, the situation won’t change significantly. The fact is that the current interface between web app and browser, that is, HTML, CSS, and JavaScript (and WASM), is highly inadequate for productivity applications.
The new breed of try-hard build-big "final"-framework would-be's plays against what the web is, trades incrementalism stengths for probably-not-all-that totalization. trying to decide & pick the one true platform, giving up the more malleable low level platform is the problem, is what the closed-world expectations have ruined the web's great prospects with.
I hate web apps with a passion. Has anyone ever used the iOS YouTube app? This thing is hailed as a marvelous examples of web apps working "like native." Bollocks. It's an absolute mess. If one of the wealthiest companies in the world can't build a decent web app, there is no hope for anyone else.
Web apps get the user 80% of what they want with 50% of the cost, so the business case is clear. That's why these apps are proliferating. They are not proliferating because they're good, as good, or better. They're just not.
This article could be about 20% as long if you cut out the rambling. You say modern SPAs are terrible but don't provide any examples of what you mean by that. You go on a completely irrelevant rant about Icelandic culture in the middle. But it's a post complaining about how modern web dev sucks, so HN will upvote it anyway!
We don't need more talking about what apps are good and what are bad. We need more doing and building (coincidentally what the people actually working in these ecosystems and trying to improve them are engaged in)
I'm a little confused on the article. I remember developing web apps where I could just start a LAMP on my machine but times have changed and we should accept that everything is getting complicated.
He should try mobile development, it's much more worse in my opinion. I'm a mobile dev fyi.
Agree.
At this point I'm a little bewildered at what iOS and Android has brought to mobile development that wasn't already in j2me, at least in a preliminary way.
At the start of iOS it was "look, pretty icons" and "no more permission popups". But, most platforms had icons anyway, and all the apps now get the annoying popups for the same set of permissions (except for networking) that was the bug bear of j2me (at the time). iOS and Android got rid of all the permission boxes for a better UX.
So, we're left with the expectation of a seamless web. But it never occurs because of endless permission issues, of which the platforms try to reduce by providing a one-size-fits-all cloud solution (iCloud and Google), both of which allow relentless advertising & gamification of our personal information. It's so bad that governments all over are racing toward digital "identities".
I'll take the simplicity of j2me any day thankyou. The development environment was GBs smaller and faster and the problem set is pretty much the same. At least with j2me there was the idea of responsibility to data usage (I generally only get 3G, even now) as opposed to 40MB apps that download 100's more. All the apps I developed during that time were offline first and synced when available.
The real complexity I see is in the consumption of video and hi res images as well as the interaction with other apps (eg share menu). Unless I'm seriously mistaken, everything else was in j2me (even opengl). All the other complexity is in the tools we have these days & endless rhetoric on which ungainly monster is better than the next.
Honestly, I find it more than a little ironic that the author is arguing against single-page web apps and then praises native apps as “doing it right”.
Native apps are built and run in a way FAR closer to how single page web apps work in that the browser becomes the runtime environment and the server becomes mostly just an API.
And you are not likely to ever see the kind of fluid results from a traditional full page render web app that you do in mobile.
And mobile at this point has more edge cases to develop for than modern browsers.
But the difference is, as I see it, there’s way less bickering on mobile over “the right way” because most developers use the native stack and instead of complaining about everything they think is hard, they roll up their sleeves and build a good product.
Maybe if we all stopped whining about single page apps being hard and started worrying about making a great product, then we too could match the quality of a nice native app built by devs like yourself.
I love web dev because the community is willing to address problems; engineering follows product in a tight feedback loop. Developer experience becomes a target to optimize for, and not just the overall ROI. In almost every other CS/software field save for machine learning, reinventing the wheel is a privilege reserved for large corporations. If you ever worked in the embedded space (or talked to engineers who did) or even a non-IT industry, it is obvious that many fundamental protocols and technologies never changed since the days "their grandpappy did it". Web may move fast but the UX is constantly improving and the value delivered is increasing every day; there is a very good reason why people from almost every other industry is trying to get into software engineering.
Even if you don't like the current JS stack, there is nothing stopping you from pulling a Figma and building everything from scratch in WebAssembly, after all, game developers (before Unity) do it all the time. Show me a burnt-out web developer and I will show you ten hardware/mechanical/electronic engineers who would give their arms and legs for the ease of tooling and the large salary of web devs. You are being paid 6-7 figures to debug a bunch of UI code in a high level scripting language, and your biggest complaint is that the churn is too bad?
I think the article needs to kick off with examples of less better web apps, otherwise I am a bit confused a out what is wrong and what he wants us to fix instead of bikeshedding frameworks.
Why are tech choices having such an impact on the experience to begin with? Aside from small apps, the web developer is just the guy making the magic happen, there should be an actual product owner somewhere who is making decisions on experience. It's up to the devs to make the experience happen, but poor design is a different problem than what framework you wrote the code in.
One thing I've noticed is that almost all new web frameworks I come across nowadays seems to be catered towards search engine optimization (i.e.: getting 99/100 on Google PageSpeed Insights).
I build https://kinopio.club a spatial thinking tool that's also (I hope) a good website. I'm only one person without the resources to build separate ios/android apps so the website needs to work everywhere and be fast and responsive
> The problem is that doing a Single-Page-App ‘properly’ is even more expensive than doing a mediocre Single-Page-App, which in turn is considerably more expensive than an old-style multi-page web service.
Is that true?
Having some experience with both styles, I don’t see a difference in time (after the learning curve for doing something new).
Totally agree we should be talking about great web and native experiences rather than the tech that sits under them. Whenever I see people arguing about frameworks I think of the midwit meme where the opposite ends just use what they know.
Web dev community should just acknowledge the simple fact that typesetting engine from 80s (HTML) and legacy hacks built around it (css and js) is not a good foundation for making modern apps.
It's like trying to build apps with a spreadsheet cells (it's actually possible, but we don't do it, thankfully) by throwing a lot of abstractions and frameworks on top of it that would hide the ugliness of the foundation layer.
Once this acknowledged, thing can start moving fast. A lot of good stuff has been developed and discovered in the web dev community, but the foundation of it is total and complete crap.
Also I believe we are in the good moment of time to build a better web, as there's virtually one major player in browser engines market and it's easier to experiement with adding support for new foundation layers (think wasm or dart vm).
But so far, no matter how much hacks web community can come up with, web apps will be predominantly associated with horrible experience, performance and quality.
I'm not entirely disagreeing with you, but there are many great web apps, or not? Google Maps, Docs, Sheets and Slides - they all kind of work without being super horrible?
It's not like most desktop apps are these great beacons of perfection either, most desktop apps are just as bad as most web apps. Just think of all the ridiculous enterprise applications that people had work with in the past. And the same applies to mobile apps from the respective app stores.
Also since a lot of the applications that you HAVE to use on a daily basis have moved to the web, you might have this feeling that desktop applications are great because the only exposure you have are applications that you choose to install yourself. But if all these apps were desktop applications you might have a different opinion.
Doesn't want to talk frameworks, but has this as a problem....
"The problem is that doing a Single-Page-App ‘properly’ is even more expensive than doing a mediocre Single-Page-App, which in turn is considerably more expensive than an old-style multi-page web service. If a lack of resources is the limiting factor for the project, any suggestion that involves more work or more resources makes the problem worse."
The point about the frameworks is that having single page, and multi page apps done properly isn't more expensive than even static stuff.
It looks like they have created their own problems here.
I usually like Baldur's writing but this is all over the place.
> What we end up with is an industry plagued with cost and time overruns. Projects go way over budget and get delivered much too late, if ever.
I was there pre-Angular and pre-React and cost and time overruns were a thing. They always were and always will be. Unsatisfying software is a broad and complex problem and no matter your views, you will find confirmation. Agile coaches will see it in waterfall, Baldur sees it in SPAs, and somebody else will see it in tracking and metrics.
[+] [-] omarhaneef|3 years ago|reply
The thing is: the debates aren’t naive. They’re exactly trying to workout the details.
When someone says, hey forget postgresql and just use SQLite, and someone else says good luck if you hit n rows, and someone says it can easily handle n+m rows with x memory …
Well they’re trying to solve the problem of (more) better apps with their limited resources. That’s essentially the problem of development.
Asking people to solve development without discussing the tools and methods is to misunderstand the nature of the discussion.
It’s like telling authors to get on and write better novels and not waste time with their opinions on character and plot.
[+] [-] onion2k|3 years ago|reply
This is a good example of how devs get things wrong. The argument between which database to use because you might hit the row limit has zero benefit to the user. It's devs wanting to avoid future work to migrate from one database to another; a problem most apps will never actually see.
There's even an aphorism about this exact thing in dev: YAGNI https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it
Solve the problem you have, not thr problem you want.
[+] [-] croes|3 years ago|reply
Better tools don't make better apps just like word processors don't make better books. The best web dev tools are worthless if the UX is bad.
[+] [-] strken|3 years ago|reply
Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on cheap bare metal ARM servers, and therefore your website is simple, usable, never goes down, and costs $20/month to run. I have no idea if this is actually good, but let's agree that there's some idealised system out there that would be a lot better than what we have now, even if it doesn't look like this one.
Let's also say I use React and Redux backed by a CQRS Express app running on MongoDB and Kafka, all hosted on AWS, and (for the sake of the argument) let's say this causes my website to be broken in bizarre ways, down all the time, and costs $2000/month to run. This is definitely an exaggeration and some of these technologies are great, but let's agree that there are some hellishly over-engineered systems out there, even if they don't look like this one.
I think the argument is that what matters here is having an example of a $20/month uncomplicated beautiful system to point to. Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool means everyone will use the broken $2000/month system as an exemplar in your field, because they have nothing better to point to.
[+] [-] matt_s|3 years ago|reply
The limited resources really doesn't matter. The tech choices really don't matter. Pick a prominent MVC based web framework, a RDBMS, some front-end libraries and go build the thing. Lean towards picking stuff the team has experience using. Then if the web app gets heavier traffic, horizontally scale the web tier and vertically scale the DB to your companies budget. If that amount of scaling doesn't suffice - do the research as you approach that level of traffic not when you have zero users.
When it comes down to standard web apps there are known patterns and known solutions out there to solve the majority of the problems. Reaching for a new/shiny thing to use is fun, learning new development techniques is fun but its rare either of those is going to cause a fundamental shift in solving problems with web apps. We have been using (abusing?) HTTP/HTML/JS/CSS for 25+ years. For small web apps I bet people could solve things with simple PERL/PHP cgi-bin types of scripts today with current versions of HTML/JS/CSS, albeit more securely than in 1999.
To use a building a house analogy, sometimes its like all the carpenters are standing around for days talking about what tool is better to frame the house, one uses less nails, one is faster, one is a nail with wood glue that will expand at the joint and provide less squeaky floors (I made that up). None of it really matters, you're being paid to frame a house, not do research - just build the thing.
[+] [-] sidlls|3 years ago|reply
Not to mention the cult of celebrity and fad following in the industry.
[+] [-] rektide|3 years ago|reply
This post impacted me & resonated strongly: it's a great notice to be more alert as to whether we're talking about details or something core & significant. Devs can have these discussions deep in the weeds, but it's kind of a farce & disservice when the petty implementation details flood & overrun the topics of what we're making & how we've enriched the media-form.
[+] [-] cyanydeez|3 years ago|reply
[+] [-] mb7733|3 years ago|reply
>Content websites are a different matter. A static or server-rendered content website with adequate typography and semantic markup is generally going to do its job pretty well.
I feel the exact opposite. Most web-based applications are pretty incredible these days.
It's the "content websites" that are insanely bloated and over engineered (and unnecessarily turned into "apps"). E.g. news sites, new reddit, recipe sites
[+] [-] kitsune_|3 years ago|reply
And as you rightly point out, visit a recipe site, especially on mobile, in comparison.
[+] [-] honkdaddy|3 years ago|reply
There are great web apps and there are great native apps. I think what the author is asking for here is just “better software” and well, wouldn’t we all love that :)
[+] [-] deergomoo|3 years ago|reply
In some cases I genuinely struggle to read an article without reader mode or an RSS reader that can scrape the full article.
[+] [-] aranchelk|3 years ago|reply
It’s true and it leads to many annoying unproductive arguments, IMO the reason is a fundamental lack of a scientific mindset in evaluating techniques and tooling. We don’t have theories or testable hypotheses, we have opinions.
On one level I like and agree with the author’s idea that results are what really matter. As an engineer trying to achieve outcomes for employers, clients, and customers, this approach has served me well.
As a community of professionals, it would be nice to see more effort to work towards rigorously proven conclusions about what works best and why.
When someone touts a paradigm, technique, or framework as the best, without any real data or theory as to why, I think they should be told to provide evidence or withdraw their argument, and I’d say that goes double when it’s the framework or technique you like or use. IMO, these shouldn’t be fights about tech, they should be ones about quality of discourse.
[+] [-] patrick451|3 years ago|reply
[+] [-] taeric|3 years ago|reply
We are taught that you can compare things objectively in most school level science classes. This leads folks to thinking their perspective is valid scientifically. Especially if they can put numbers to it. After all, isn't that native empiricism?
[+] [-] belenos46|3 years ago|reply
And actual flogging for the management team if they accept that framework.
[+] [-] abc_lisper|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] prox|3 years ago|reply
[+] [-] EnKopVand|3 years ago|reply
I do think we need a better tool for finding the passion projects. Because search engines have basically become the “portals” they replaced by curating search results into being about herding us toward sales, but I’m sure we’ll see a shift sooner or later. It’s sort of already happening with more and more people returning to things like news letters instead of reading blogs.
[+] [-] tuxie_|3 years ago|reply
I like the idea! I wonder though how that would look like. How do you imagine such a tool? Would it be something like a "directory" from back in the 90s where people submit their link under a specific category?
[+] [-] travisgriggs|3 years ago|reply
This is the reality that has been grinding me down of late. Nor do I find it limited to only web stuff. I see it in embedded and other market areas.
I was excited over the last few decades to see the field of programmers swell. I have always loved the craft of good software development. I was so excited to see so many others also get into it and naively believed that many more people participating would lead to a larger pool of ideas to draw from and everyone would get on board in some sort of utopian democratic industry wide kumbaya. During the rise of open source, I even felt it was really happening.
I now believe I was wrong.
[+] [-] _carbyau_|3 years ago|reply
sigh We have hardware doing billions of instructions per second, capable of transporting at least 500Mb/s within my computer, 120+Hz screens and yet:
- Windows 10 desktop -> opening Start menu = 5 seconds wait.
A trite example but once you look it is everywhere. This stuff grinds my gears every damn day.
[+] [-] jdougan|3 years ago|reply
[+] [-] jasonpbecker|3 years ago|reply
So I'm left wondering, did the frameworks fail or did the web developer community fail?
[+] [-] layer8|3 years ago|reply
[+] [-] rektide|3 years ago|reply
[+] [-] Gareth321|3 years ago|reply
Web apps get the user 80% of what they want with 50% of the cost, so the business case is clear. That's why these apps are proliferating. They are not proliferating because they're good, as good, or better. They're just not.
[+] [-] dom_inic|3 years ago|reply
We don't need more talking about what apps are good and what are bad. We need more doing and building (coincidentally what the people actually working in these ecosystems and trying to improve them are engaged in)
[+] [-] lawgimenez|3 years ago|reply
He should try mobile development, it's much more worse in my opinion. I'm a mobile dev fyi.
[+] [-] cmroanirgo|3 years ago|reply
At the start of iOS it was "look, pretty icons" and "no more permission popups". But, most platforms had icons anyway, and all the apps now get the annoying popups for the same set of permissions (except for networking) that was the bug bear of j2me (at the time). iOS and Android got rid of all the permission boxes for a better UX.
So, we're left with the expectation of a seamless web. But it never occurs because of endless permission issues, of which the platforms try to reduce by providing a one-size-fits-all cloud solution (iCloud and Google), both of which allow relentless advertising & gamification of our personal information. It's so bad that governments all over are racing toward digital "identities".
I'll take the simplicity of j2me any day thankyou. The development environment was GBs smaller and faster and the problem set is pretty much the same. At least with j2me there was the idea of responsibility to data usage (I generally only get 3G, even now) as opposed to 40MB apps that download 100's more. All the apps I developed during that time were offline first and synced when available.
The real complexity I see is in the consumption of video and hi res images as well as the interaction with other apps (eg share menu). Unless I'm seriously mistaken, everything else was in j2me (even opengl). All the other complexity is in the tools we have these days & endless rhetoric on which ungainly monster is better than the next.
[+] [-] kiawe_fire|3 years ago|reply
Native apps are built and run in a way FAR closer to how single page web apps work in that the browser becomes the runtime environment and the server becomes mostly just an API.
And you are not likely to ever see the kind of fluid results from a traditional full page render web app that you do in mobile.
And mobile at this point has more edge cases to develop for than modern browsers.
But the difference is, as I see it, there’s way less bickering on mobile over “the right way” because most developers use the native stack and instead of complaining about everything they think is hard, they roll up their sleeves and build a good product.
Maybe if we all stopped whining about single page apps being hard and started worrying about making a great product, then we too could match the quality of a nice native app built by devs like yourself.
[+] [-] melony|3 years ago|reply
Even if you don't like the current JS stack, there is nothing stopping you from pulling a Figma and building everything from scratch in WebAssembly, after all, game developers (before Unity) do it all the time. Show me a burnt-out web developer and I will show you ten hardware/mechanical/electronic engineers who would give their arms and legs for the ease of tooling and the large salary of web devs. You are being paid 6-7 figures to debug a bunch of UI code in a high level scripting language, and your biggest complaint is that the churn is too bad?
[+] [-] quickthrower2|3 years ago|reply
[+] [-] rootusrootus|3 years ago|reply
[+] [-] exodust|3 years ago|reply
Product Owner: "Let's remove the Save button and instead simply save every time the user changes the value".
Developer: "No".
[+] [-] 0xb0565e487|3 years ago|reply
[+] [-] hoten|3 years ago|reply
[+] [-] pketh|3 years ago|reply
I build https://kinopio.club a spatial thinking tool that's also (I hope) a good website. I'm only one person without the resources to build separate ios/android apps so the website needs to work everywhere and be fast and responsive
[+] [-] typeofhuman|3 years ago|reply
[+] [-] aaaaaaaaaaab|3 years ago|reply
Sorry, but in its current state your website is a good example of why webapps are inferior to native ones.
[+] [-] jmull|3 years ago|reply
Is that true?
Having some experience with both styles, I don’t see a difference in time (after the learning curve for doing something new).
[+] [-] conartist|3 years ago|reply
[+] [-] divan|3 years ago|reply
It's like trying to build apps with a spreadsheet cells (it's actually possible, but we don't do it, thankfully) by throwing a lot of abstractions and frameworks on top of it that would hide the ugliness of the foundation layer.
Once this acknowledged, thing can start moving fast. A lot of good stuff has been developed and discovered in the web dev community, but the foundation of it is total and complete crap.
Also I believe we are in the good moment of time to build a better web, as there's virtually one major player in browser engines market and it's easier to experiement with adding support for new foundation layers (think wasm or dart vm).
But so far, no matter how much hacks web community can come up with, web apps will be predominantly associated with horrible experience, performance and quality.
[+] [-] kitsune_|3 years ago|reply
It's not like most desktop apps are these great beacons of perfection either, most desktop apps are just as bad as most web apps. Just think of all the ridiculous enterprise applications that people had work with in the past. And the same applies to mobile apps from the respective app stores.
Also since a lot of the applications that you HAVE to use on a daily basis have moved to the web, you might have this feeling that desktop applications are great because the only exposure you have are applications that you choose to install yourself. But if all these apps were desktop applications you might have a different opinion.
[+] [-] gen_greyface|3 years ago|reply
this is a webapp
[+] [-] jasfi|3 years ago|reply
[+] [-] pier25|3 years ago|reply
Non native English speaker here...
What does "blind to rank in" mean?
[+] [-] myrryr|3 years ago|reply
"The problem is that doing a Single-Page-App ‘properly’ is even more expensive than doing a mediocre Single-Page-App, which in turn is considerably more expensive than an old-style multi-page web service. If a lack of resources is the limiting factor for the project, any suggestion that involves more work or more resources makes the problem worse."
The point about the frameworks is that having single page, and multi page apps done properly isn't more expensive than even static stuff.
It looks like they have created their own problems here.
[+] [-] gherkinnn|3 years ago|reply
> What we end up with is an industry plagued with cost and time overruns. Projects go way over budget and get delivered much too late, if ever.
I was there pre-Angular and pre-React and cost and time overruns were a thing. They always were and always will be. Unsatisfying software is a broad and complex problem and no matter your views, you will find confirmation. Agile coaches will see it in waterfall, Baldur sees it in SPAs, and somebody else will see it in tracking and metrics.