I thought this was an entertaining talk, quite surprising to see it come from a web conference.
My day job is working on the web and I share these frustrations (I swear as much as the guy in the video). Watching HMH has helped me avoid a lot of the really terrible stuff in web development but also means that 'voice in my head' he talks about is very loud at times.
Everybody says how open the web is but you have zero choice in the technology you use.
I've been working on svg animations recently and it feels like you're trying to sculpt a marble statue with a rubber spoon. If you ever want to loose a day of your life try rotating an svg around its center in a way that works cross-browser without any libraries.
I've written code that helps exporting svgs from Illustrator. I wonder though that by sharing it I'm just contributing to the problem.
Over the Christmas holidays I might start working on a vector renderer and accompanying format designed for use with webassembly. Interested in hearing if anyone else is working on Handmade web type projects.
Everybody says how open the web is but you have zero choice in the technology you use.
I've been working on svg animations recently and it feels like you're trying to sculpt a marble statue with a rubber spoon. If you ever want to loose a day of your life try rotating an svg around its center in a way that works cross-browser without any libraries.
I've written code that helps exporting svgs from Illustrator. I wonder though that by sharing it I'm just contributing to the problem.
Over the Christmas holidays I might start working on a vector renderer and accompanying format designed for use with webassembly. Interested in hearing if anyone else is working on Handmade web type projects.
Edited by Sockpuppet
on
Reason: typos
Good to see some other web developers on handmade network.
I saw this video a week or so ago. And it has been stuck in my head. I haven't been able to get into the handmade vibe at work but couldn't help thinking about what it would take to improve on the current state of the web. I was actually thinking about how to go about the real VM with a good ISA you can program to from any language. Like he mentions in his talk. And now you, Sockpuppet, mention the WebAssembly option. Didn't know about that one yet, but it sounds promising. Although I don't know if trying to combine this with all the existing Javascript stuff is a right decision. But that is where it seems to be heading. I guess it's hard to say goodbye to all that existing infrastructure, but in my eyes keeping html/css/javascript for UI and only pushing WebAssembly for CPU intensive jobs is a missed opportunity. I does make me think: is restarting the web too hard? What would it take to make something that works better?
Maybe we could brainstorm here to see what it would take to improve the web? Maybe try and see what requirements we would like to meet? And what could be dropped/rebooted. In my mind keeping everything for backwards compatibility might be bad. But on the other end of the spectrum is creating everything from scratch (which is in line with the handmade motto), but this might break a lot of requirements. For example search indexing, which is still important if you would like to use the new techniques for real clients instead of only for personal projects. (Though google is better at indexing full JS sites nowadays, so who knows...)
I was about to start thinking about a new way to do the html/css parts with WebAssembly as the JS part, but was interested in your ideas/requirements. This could lead me to different usage code, since over engineering without looking at the usage code is not what we learn here at handmade network ;) Something in line with the Immediate mode GUI might be good?
I saw this video a week or so ago. And it has been stuck in my head. I haven't been able to get into the handmade vibe at work but couldn't help thinking about what it would take to improve on the current state of the web. I was actually thinking about how to go about the real VM with a good ISA you can program to from any language. Like he mentions in his talk. And now you, Sockpuppet, mention the WebAssembly option. Didn't know about that one yet, but it sounds promising. Although I don't know if trying to combine this with all the existing Javascript stuff is a right decision. But that is where it seems to be heading. I guess it's hard to say goodbye to all that existing infrastructure, but in my eyes keeping html/css/javascript for UI and only pushing WebAssembly for CPU intensive jobs is a missed opportunity. I does make me think: is restarting the web too hard? What would it take to make something that works better?
Maybe we could brainstorm here to see what it would take to improve the web? Maybe try and see what requirements we would like to meet? And what could be dropped/rebooted. In my mind keeping everything for backwards compatibility might be bad. But on the other end of the spectrum is creating everything from scratch (which is in line with the handmade motto), but this might break a lot of requirements. For example search indexing, which is still important if you would like to use the new techniques for real clients instead of only for personal projects. (Though google is better at indexing full JS sites nowadays, so who knows...)
I was about to start thinking about a new way to do the html/css parts with WebAssembly as the JS part, but was interested in your ideas/requirements. This could lead me to different usage code, since over engineering without looking at the usage code is not what we learn here at handmade network ;) Something in line with the Immediate mode GUI might be good?
Mox, I'm into this too. I'm not gonna get all technical, but I'll tell you this:
Whatever "better" option we offer needs to be a lot more fluid. Right now, the web is completely broken into a bunch of different technologies that frankly all struggle to work together. It needs to have 1-3 (preferably 1) SOLID language(s) that handle everything without the need for 484923848 frameworks. It's going to have to start with web browsers first. Web browsers need to go out the door. The web should be natively built into modern machines, the operating system should facilitate the "browser." Without this last portion fixed first, all attempts to "fix the web" will be completely futile. The web itself depends entirely on the programs that we use to access it, and right now they're a joke.
I mean, if you think about the current situation logically, it makes absolutely no sense. "MEAN stack" is utter madness. People have taken the scripting language used inside of web browsers and have tried to, via C++, control the machine when we've had languages like C, and PASCAL, and even C++, Java, and PHP which have done this very thing for 40+ years already. Things that native languages have been doing for decades are being celebrated in the MEAN community because JS has finally done it in 2016. Why??? What's the point? The point is that people don't want to use 500 languages to do the same thing computers have aleady been doing for the past 30 years.
If you step away and look at the big picture for a second, you realize, wait a second... What does the web accomplish that computers haven't been doing for a long time? Nothing really. A browser displays a GUI, performs some computations, delivers data, networks with other computers, etc... Is any of this even remotely new? Nope. Yet, "web services" are acting like it's a big deal that we can re-do basic tasks that we've all been able to do natively since like 1995. For God's sakes, everyone thought it was a big deal when 'push notifications" and parts of a web-page refreshed without having to reload the entire page. When put into the context of the browser, that was amazing... But for the personal computer as a whole, that was a complete, utter joke that had been accomplished decades ago!
The only conceivable reason I see JavaScript is so big now is because the front-end web dev community got lazy and didn't want to learn a new language so they said screw it, we'll use JavaScript for everything. Or the more likely reason, which is everyone is sick of using 25 moving parts for a crappy application. The hourly frameworks are getting so out of hand IMO, although people bag on PHP all the time, even PHP is a lot more stable than MEAN right now... At least its claim to fame is Facebook and WordPress. I've heard Walmart.com was one of MEAN's big accomplishments... Walmart.com is a broken mess.
Whatever "better" option we offer needs to be a lot more fluid. Right now, the web is completely broken into a bunch of different technologies that frankly all struggle to work together. It needs to have 1-3 (preferably 1) SOLID language(s) that handle everything without the need for 484923848 frameworks. It's going to have to start with web browsers first. Web browsers need to go out the door. The web should be natively built into modern machines, the operating system should facilitate the "browser." Without this last portion fixed first, all attempts to "fix the web" will be completely futile. The web itself depends entirely on the programs that we use to access it, and right now they're a joke.
I mean, if you think about the current situation logically, it makes absolutely no sense. "MEAN stack" is utter madness. People have taken the scripting language used inside of web browsers and have tried to, via C++, control the machine when we've had languages like C, and PASCAL, and even C++, Java, and PHP which have done this very thing for 40+ years already. Things that native languages have been doing for decades are being celebrated in the MEAN community because JS has finally done it in 2016. Why??? What's the point? The point is that people don't want to use 500 languages to do the same thing computers have aleady been doing for the past 30 years.
If you step away and look at the big picture for a second, you realize, wait a second... What does the web accomplish that computers haven't been doing for a long time? Nothing really. A browser displays a GUI, performs some computations, delivers data, networks with other computers, etc... Is any of this even remotely new? Nope. Yet, "web services" are acting like it's a big deal that we can re-do basic tasks that we've all been able to do natively since like 1995. For God's sakes, everyone thought it was a big deal when 'push notifications" and parts of a web-page refreshed without having to reload the entire page. When put into the context of the browser, that was amazing... But for the personal computer as a whole, that was a complete, utter joke that had been accomplished decades ago!
The only conceivable reason I see JavaScript is so big now is because the front-end web dev community got lazy and didn't want to learn a new language so they said screw it, we'll use JavaScript for everything. Or the more likely reason, which is everyone is sick of using 25 moving parts for a crappy application. The hourly frameworks are getting so out of hand IMO, although people bag on PHP all the time, even PHP is a lot more stable than MEAN right now... At least its claim to fame is Facebook and WordPress. I've heard Walmart.com was one of MEAN's big accomplishments... Walmart.com is a broken mess.
Edited by Todd
on
I have been thinking about what could be done about how shitty web development is as well and I think a really awesome solution could be made soonish.
The key technologies needed is websockets, which is already here and asm.js or webassembly.
Step 1 would be to get a sane language like Python to work in the browser.
Besides making sane and "unifying" CSS, HTML and Javascript, it would be great to add server code to this as well. Right now you often have to run a lot of the same logic both client side and server side, for example when constraining the user input in an input field. You have to do it client side for consistent user experience and then server side to make sure they didn't maliciously tamper with a raw request. It would therefore be great to write one piece of code and in this code have an option to specify if a certain part should be run only on the server or the client. This would also abstract away the constant variable/data transfer (POST/GET requests), the server/client would simply wait (async) while a variable isn't available yet (like from user input etc.). You would also be able to tie events to variable changes (yes event based programming sucks and is overused in Javascript, but it is the only viable way to handle certain things). If things worked over websockets, constant page "requests" and the user wait and resource overhead of reloading the entire page on every interaction could be avoided.
Other than the above it would be great to have a visual UI editor (websites are very UI heavy after all) and remove all need for HTML and CSS. Programmers would still be able to programmatically access and change the UI, but only through a consistent API that directly modifies the DOM. Backend a new dynamic non shitty positioning and resizing paradigm could be built on top of fixed css positions and z-index.
So to sum up the most important features:
- Combined CSS, HTML and Javascript functionality into one sane language and a UI API
- Combined server/client code
- Constant GET/POST variable transfer abstracted away
- No longer any user wait for aesthetically displeasing, overhead inducing and fundamentally unnecessary web requests
This would require a combined:
- Web server
- Browser complied language + API
- UI editor
So obviously not an easy task.
The key technologies needed is websockets, which is already here and asm.js or webassembly.
Step 1 would be to get a sane language like Python to work in the browser.
Besides making sane and "unifying" CSS, HTML and Javascript, it would be great to add server code to this as well. Right now you often have to run a lot of the same logic both client side and server side, for example when constraining the user input in an input field. You have to do it client side for consistent user experience and then server side to make sure they didn't maliciously tamper with a raw request. It would therefore be great to write one piece of code and in this code have an option to specify if a certain part should be run only on the server or the client. This would also abstract away the constant variable/data transfer (POST/GET requests), the server/client would simply wait (async) while a variable isn't available yet (like from user input etc.). You would also be able to tie events to variable changes (yes event based programming sucks and is overused in Javascript, but it is the only viable way to handle certain things). If things worked over websockets, constant page "requests" and the user wait and resource overhead of reloading the entire page on every interaction could be avoided.
Other than the above it would be great to have a visual UI editor (websites are very UI heavy after all) and remove all need for HTML and CSS. Programmers would still be able to programmatically access and change the UI, but only through a consistent API that directly modifies the DOM. Backend a new dynamic non shitty positioning and resizing paradigm could be built on top of fixed css positions and z-index.
So to sum up the most important features:
- Combined CSS, HTML and Javascript functionality into one sane language and a UI API
- Combined server/client code
- Constant GET/POST variable transfer abstracted away
- No longer any user wait for aesthetically displeasing, overhead inducing and fundamentally unnecessary web requests
This would require a combined:
- Web server
- Browser complied language + API
- UI editor
So obviously not an easy task.
Edited by Stefan
on