I didn't read the whole article. I couldn't. I couldn't get past the complete mis-analysis of what the web was in 2012. I was there. I was working as a developer, writing HTML5 code, no one was using tables, let alone flash. The initial arguments of this article are completely off base. Coffeescript was never sexy. It never took hold (despite some big dev names pushing it, sorry Jeremy).
Writing HTML back then is very similar to writing it now, only now you wrap it in a return statement and it lives in a jsx file.
No code has never been a silver bullet. It's main use has always been to solve "known" problems with reproducible components. If you had something you wanted to do outside of those components, you were SOL.
In 1999, we used tables. In 2009 we use divs. In 2019 we use divs and custom elements. In 2022 its all about those web components!
So make sure if you are going to go back in history, that you are factual and not making stuff up. Thanks.
> Writing HTML back then is very similar to writing it now, only now you wrap it in a return statement and it lives in a jsx file.
N.b. that is only really the case for React/React-flavoured frameworks. Other frameworks - notably Angular - still keep HTML and CSS in their own dedicated files (n.b. in Angular you can include the HTML in the component too, but obviously this is only really something you'd want to do for simple and small components for the same reasons that JSX is a problem).
I feel like we're headed down the same old road we had before where people were conflating jQuery with JavaScript. React is not the only way, even if it is popular now. jQuery was in the same position React is now, but today is largely forgotten apart from a few people still using it - I would urge people to remember that and try to keep an open mind and broad-horizons especially in the world of JavaScript Frameworks.
I know little enough about the topic that I took your statement at face value. I appreciate the commenter pointing out that you only spoke about the react world. Your sarcasm did not come across as such.
> Writing HTML back then is very similar to writing it now
Not at all. The author may have gotten some minor details off, but all of that was present on some level in various quantities. I worked on enterprise software back then and it was a matter of editing HTML in ASPX to manually update your JS libraries. It was also a matter of manually linking your HTML tags to thousands of lines of CSS in typically a single file. It was a gigantic pain in the ass to do on a large code base with hundreds of pages and it meant acting like a human compiler/package manager, carefully grepping through to make sure you didn't miss something when you upgraded JQuery to version 2 or that your CSS class rule didn't accidentally cascade changes to some non-related context and throw your div 16px off-center. It was mind-numbingly dull and extremely error-prone.
It was back then that I realized that despite the fact that some of our web code was written in server-side C#, it by no means could keep up with the need to make dynamic fluid interfaces on the client-side. The lines of code in JS had grown higher than the lines of C# over many years. And yet the tooling was still treating JS as if it were an animated cursor plug-in. It did not have first-class tooling just yet, and JS was missing some critical features (like native modules) that would make it better to work with. This is at least part of why JS was hated so much back then and there's still quite a bit of hate that lingers from that era. It was very frustrating to work with.
It got dramatically better over the next few years, but there was a lot of churn between Bower, yarn, npm, webpack, etc. Even Node.js I believe split off into io.js back then until it re-merged. AngularJS was originally adopted because it solved a lot of these problems for devs with a kitchen sink solution, but it did so in a proprietary, non-scalable way. The JS ecosystem eventually surpassed Angular's capabilities and now we're able to freely move between React, Angular, Vue, Solid, etc while still using the same tooling.
Centering divs was still surprisingly difficult in 2012. Flash was already on life support, for sure, by then, but Flash websites were still out in the wild. Everyone was waiting on HTML5, but it took a couple of years for IE to get retired, for Edge to get released and for Safari to catch up to much of the spec. IE was still a significant market share then. CoffeeScript was at its peak in popularity probably in 2012. The author got a lot very correct in this article. The gist of what they're saying, though, absolutely true.
Around 2012 there were all kinds of static prebuilding frameworks rising again, and by 2014ish pandoc was very popular already.
Personally I switched around 2015 to writing most of my web pages in markdown (well, or commonmark) because I got fed up of repeating myself too often in HTML.
VIM isn't a great IDE for HTML and all its syntax highlighting quirks either, which contributed to the markdown migration.
The beauty of markdown is that it's so lightweight, you can use it for dynamic lazy loading as well. There's almost zero overhead for layouting information for the text if you do it right.
Yeah, prebuilding frameworks like Jekyll in 2013 changed the game for some. However, as much as I love markdown, the issue in my post was with the OP's assessment of what web development was like in 2012 which was off base.
Most enterprises at the time weren't using markdown outside of engineering documentation. The rise of JIRA during this time period helped a bit as they had their own flavor of markdown-like syntactic sugar. We started to explore other ways of generating pages. Ruby on Rails started gaining serious traction ($1B+ VC backed startups using it). Things like haml existed to make writing html "fun again" (my words). Which gave rise to other processing languages to spit out HTML from lessons learned.
It was around this time that microservices started to be a thing to replace those old enterprise SOA architectures (hello jboss). The application server began to die in favor of self-hosted apps. Docker was new. Spring Framework was relatively new. Bootstrap was just released. There weren't any standard css frameworks that provided as much as Bootstrap did at the time.
<script type="template"> was a thing. Backbone.js was used often. Underscore.js as well (Jeremy, again, sorry about Coffeescript, they can't all be winners).
Now we have web components and I'm so happy we do. It's refreshing to be able to do the things we wanted to do back then but couldn't without some other framework.
I've been around a long time. I started doing web development in 1998 right out of high school. I've written all kinds of web apps, platforms, services, etc.
Vim with Emmet and the right tweaks is very good if your job is churning out HTML. I've had a few projects that would have been endless slogs with nearly any other setup get completed at lightspeed.
This setup's strength is its own downfall though. If you don't have the arcane keystrokes and useful patterns burned into your muscle memory you would be better off with almost anything else.
Hopefully if this project gets off the ground they will remember that many of us write HTML as a small component of our jobs rather than it's sole focus.
CF, PHP, cgi scripts in Perl, that sounds like 2002 to me!
You brought me back with Zope though, man, totally forgot about that. J2EE had a huge head start over .Net which was just coming out of microsoft to replace VB6/OCX development. I remember when C# came out how awesome it made me feel. C++ like syntax but without having to worry about memory (naively). It was great.
It did not solve the VB ASP problem, only allowed you to write your page backend in C#. Asp, Asp.cs
It sucked for about 7 years until Asp.Net MVC came out.
Tooling went from notepad/vim to Dreamweaver, to Visual Studio/Eclipse and back again.
Having been part of a MSFT Partner that was involved in the .NET launch for Portugal, I am quite sure that WebForms allowed to use VB.NET.
We were going to adopt J2EE and at last minute our CTO took Microsoft's offer to migrate our product to .NET instead, and be part of the 3rd party products to be shown at .NET launch.
The key developers that were part of this project went on to found OutSystems.
WebForms was great in terms of tooling, that is why Blazor is being positioned as where the still existing WebForms projects should transition to.
We only build internal tools and we don't (can't?) hire people who would need accessibility accommodations to begin with. Not making a value judgement on that stance, just telling it as it is.
There's absolutely nothing wrong with tables when properly used for data.
The problem being described is that, in the early 00's, there was no easy way to make column layouts with CSS due to IE6 and CSS's own lack of good column handling rules, other than float: left and (later) display: inline-block. This led to most people in web development to produce their page layouts by stacking tables within tables within tables because the end result would visually work properly in every browser. This was, however, an awful way to produce semantic content not to mention the inherit accessibility issues.
Thankfully, by 2006, nearly everyone had already been exposed to the likes of CSS Zen Garden and learned how to workaround with CSS issues to make layout with block elements instead of tables within tables.
Yup, no grid, no flex, the only way to ensure your chopped up photoshop design would work was with tables.
Now we don’t use images for everything, we use CSS/iconography/typography/styles. Back then though we didn’t have a whole lot of options in CSS so we used images EVERYWHERE! Drop shadow, that’s a transparent png image. Gradients, jpgs. Animations, gifs. Want to play a video? Real player or flash. It was crude, it was hard, and it was a compatibly nightmare.
I was explaining how we used to add drop shadows on web pages to one of the younger members of our team a month or two ago and they found it hilarious. An image sliced up into several bits, a table (often embedded in another table) and various other hacks to make everything line up nicely versus a single line of CSS now.
It was rough early-on. You could do complex layouts with hacks but they worked inconsistently on each browser, CSS itself was inconsistent across browsers, vendor prefixes all over the place. Remember the 'holy grail' layout of three columns, header and footer? Trivial in CSS Grid of course, but practically impossible without tables before.
It's insane to think now that including your good reasons to avoid them one was also that apparently they slowed down the browser doing the layout. Never experienced it but I'm certain some important figures explained it.
Now everything is so slow with all that latest js fad that it sounds like a meme. Things being clunky and slow are accepted.
>There's absolutely nothing wrong with tables when properly used for data.
No, the most annoying thing with front end is new front end developer trying to convert data grip that is obviously meant for tables to divs. Seems like young people trying to be cool to not use tables. Use freaking tables when it is looks like grid, div for other stuff.
If you're writing JSX the way you write html, that sounds painful too. Html is low-level. Jsx let's you make a high level language for your markup, composing prebuilt things together. You can actually engineer your markup
It wasn’t meant to be taken so seriously. Yeah I agree, it allows you to build up a higher level tag library of components to use for your layout.
I said that because it seemed like every new product was using react. In my corner of the world, it was all encompassing for front-end engineers. Still kinda is.
2012 was not very far away from the end of table layouts. After all tables were ditched as a layout tool only because they were hardly responsive and a number of people were starting to browse the web on their phones.
The most popular HTML/CSS framwork (Bootstrap) is from the end of 2011. I'm still maintaining an inherited project that I was sure it is using Bootstrap (because, what else?) until I really looked into it (we've not been making changes the the UI for ages) and horror! it's some custom non responsive div based grid layout. I checked the date of the first commits, beginning of 2011. Tough luck.
Yeah I called out bootstrap somewhere else in this thread having launched in 2011. It really changed the game as far as standardization of css styles. Yes there were others then too but nothing that had a market impact like bootstrap did.
Writing HTML back then is very similar to writing it now, only now you wrap it in a return statement and it lives in a jsx file.
No code has never been a silver bullet. It's main use has always been to solve "known" problems with reproducible components. If you had something you wanted to do outside of those components, you were SOL.
In 1999, we used tables. In 2009 we use divs. In 2019 we use divs and custom elements. In 2022 its all about those web components!
So make sure if you are going to go back in history, that you are factual and not making stuff up. Thanks.