Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
> The browsers native language is HTML. HTML is a markup language and if you feed HTML to the browser it will very quickly render the page with what you give it. But no. Let's not do that. Let's instead feed the browser with JSON and then have the build in JavaScript engine translate that into a pre-formatted output which then gets translated into HTML before it's served to the user.
I agree with you. I agree with the author. I put my own idea into practice:
https://htmx.org
I agree it is partly idiotic complaining though there is some truth to it.
Firstly IQ has declined. There is a widespread lie that everyone can be developer if they only try hard enough. Hence you get more noisy signals deciding over technological progress.
Secondly, people use complexity to show off. This comes and goes as very high complexity makes the simple stuff look smart again (see for example the Java framework diversification back when Java was atrocious, but later pure Java became fashionable again once the language had improved ).
Thirdly, one can build performant and impressive stuff from the layers and layers of complexity such as modern JS frameworks. See for example the latest Telegram web client.[1] So ultimately it is more about the IQ and skill of the programmer and less about the particular Turing-complete language/framework used, because whichever route you take, ultimately you have to face complexity and all the different events, states and exceptions.
[1] https://github.com/TelegramOrg/Telegram-web-z
This is a question I've struggled with ever since I started working in the field.
In terms of definition, software development ticks all the boxes - depending on who you ask.
Yet every way you look at it, something just doesn't feel right. Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom.
By "freedom" I strictly mean lack of limitations. While the laws of physics dictate what can and can't be done in traditional engineering disciplines, the same cannot be said about software.
A good design can be quantified, tested, and improved based on hard data (and eventual failure). A good program, however, is super hard to qualify. What even is "good maintainability" in terms of software? Is it a bunch of metrics like cyclomatic complexity, Halstead volume, and lines of code haphazardly cobbled together to form an arbitrary index value?
With traditional engineering you have material properties like tensile strength that you can match against requirements and safety margins. What's the equivalent of tensile strength of a software product and can we measure it?
For decades people in scientific computing have relied on Fortran programs that defy any modern notion of maintainability. The subroutines and "drivers" are limited to 6-character names and functions with >25 arguments are not uncommon.
Yet they still work, are still used and stood the test of time despite archaic properties [0], which require users to memorise large tables of codes for data types and routine names.
I also feel that despite these limitations, libraries like LAPACK are more readable and maintainable than modern C++ monstrosities like this [1].
[0] http://www.netlib.org/lapack/lug/node24.html
[1] https://github.com/nlohmann/json
Well, then again the original idea is taking off with https://solidproject.org/ with millions of pods by Tim Berner-Lee's Inrupt to go online this Spring.
Crazy idea that I'm sure isn't an original thought: instead of adapting the languages to deal with abstracting the idiosyncrasies of each OS, change the OSes to expose a universal API to make everything else lighter.
I guess that's also kinda Docker or QEMU or V8, but also https://github.com/solo-io/unik if you think about it differently.
In other words: hey, Lisp Machines were an excellent idea back then, but they still are. Maybe someday we'll have a V8 co-processor. More fun reading: https://lobste.rs/s/2poahh/what_i_could_not_undiscover_about
Especially if the library is even slower than smaller alternatives like [1].
But that's just my personal opinion, I understand that other people have different priorities and are fine with including 785kb of C++ template headers s long as public interface suits their needs and taste.
This is just an example for the kind of freedom software allows for, because it doesn't cost you anything and there is no objectively "better" in this case.
[1] https://github.com/kazuho/picojson
> I don't understand how can you diss Electron when you see something like VS Code or Atom.
Because you also see things like https://github.com/microsoft/vscode/issues/22900
I have been in professional web development since 2004 and I mostly agree with the author that there are massive amounts of groupthink going on. "Modern" web development has standardized in tool stacks which are insanely complicated, far beyond anything that is warranted in most cases. We have forgotten how to make simple things in simple ways.
At a minimum you need node, npm, webpack, babel, an spa framework, a frontend router, a css transpiler, a css framework, a test runner, a testing functions library, and a bunch of smaller things, and that's just what is "needed" to build a static website with a bit of interaction. We're not even talking about the dockerized insanity that happens as soon as you want to slide an API under that beast.
I understand why every piece is there, I was there when they arrived on the scene, I understand what problem they solve. What I don't understand is why as a group web developers have decided this is the only way to solve the problem of web development. What we don't have are simpler web stacks. Why do we need npm or babel at all to make a simple web frontend? Modern browsers are good enough that with the right tooling we don't need build pipelines or package managers. Similar arguments can be made for the server-side parts.
Anyway, here's my own two cents to a simpler web dev stack: a version of create react app that is entirely self-contained and has no build steps. https://github.com/jsebrech/create-react-app-zero
If it were the backend, I would not expect the load times to improve when loading Slack into a browser tab where its resources are constrained.
Separately, if it were strictly a Slack problem and not Electron, you wouldn't expect to see these kinds of issues crop up across the spectrum of Electron apps. Scroll through this thread and you can see a variety of people running into these problems in all kinds of different electron-based apps:
https://github.com/electron/electron/issues/12988